Налаштування логування процесу автонаповнення 1С-Бітрікс

Налаштування логування процесу автозаповнення 1С-Бітрікс

Парсер працює у фоні — через cron або агенти. Коли щось іде не так, єдиний спосіб розібратися — логи. Без структурованого логування відладка парсера перетворюється на гадання: то гей джерело повернуло порожню сторінку, то гей XPath сломався, то гей лімит пам'яті PHP кончився на 50 000-м товарі. Розберемо, як організувати логи, щоб будь-який інцидент розбирався за хвилини.

Рівні логування

Використовуйте стандартні рівні PSR-3, навіть якщо не підключаєте Monolog:

• DEBUG — кожний HTTP-запит до джерела, час ответу, розмір body. Включається тільки при відладці.
• INFO — старт/стоп парсера, кількість оброблених елементів, кількість створених/оновлених записів у інфоблоку.
• WARNING — пропущений елемент (не пройшов валідацію), повільний ответ джерела (>5 сек), повторна спроба запиту.
• ERROR — виключення при парсингу, помилка запису в b_iblock_element, невалідний ответ API.

У продакшені тримайте рівень INFO. Переключення на DEBUG — через налаштування у b_option або файл-флаг /local/parser_debug.flag, без перезапуску та деплоя.

Куди писати логи

Варіант 1: файлова система. Найпростіший. Пишемо у /local/logs/parser/YYYY-MM-DD.log. Формат рядка:

[2024-03-15 14:23:01] INFO | source=competitor_a | action=update | iblock_id=12 | element_id=45678 | duration=0.34s

Кожен рядок — одна подія. Розділювач | зручний для grep та awk. Обов'язкові поля: timestamp, level, source (ідентифікатор джерела парсингу), action (fetch/parse/validate/import).

Ротація — через logrotate або власний агент, що видаляє файли старіше 30 днів. Без ротації логи DEBUG-рівня за неділю легко займуть гігабайти.

Варіант 2: таблиця b_event_log. Штатний журнал Бітрікс. Вивик CEventLog::Add() з параметрами:

CEventLog::Add([
    'SEVERITY' => 'INFO',
    'AUDIT_TYPE_ID' => 'PARSER_IMPORT',
    'MODULE_ID' => 'iblock',
    'ITEM_ID' => $elementId,
    'DESCRIPTION' => json_encode($context, JSON_UNESCAPED_UNICODE),
]);

Плюси — перегляд через адмінку, фільтрація, доступ для менеджерів без SSH. Мінуси — таблиця b_event_log не розрахована на тисячі записів у хвилину, при інтенсивному парсингу тормозить. Використовуйте для WARNING/ERROR, не для DEBUG.

Варіант 3: кастомна таблиця. Створюємо таблицю parser_log з полями id, created_at, level, source, action, element_id, message, context (JSON). Індекс по (created_at, level, source). Це оптимальний варіант для проектів, де парсер — критична підсистема, та потрібні аналітичні запити по логам.

Контекст — головне у логе

Рядок «Помилка парсингу» беспільна. Корисна рядок: «XPath //div[@class="price"]/span повернув 0 вузлів, очікувалось 1, URL: https://source.com/product/123, HTTP 200, body size: 45KB».

Мінімальний контекст для кожного рівня:

Реалізація обёртки

Створіть клас ParserLogger у /local/php_interface/classes/ (або в пространстве імен вашого модуля). Інтерфейс:

ParserLogger::info('import', [
    'source' => 'competitor_a',
    'element_id' => 45678,
    'action' => 'update',
    'fields_changed' => ['PRICE', 'QUANTITY'],
]);

Всередину — запис у файл + у b_event_log для рівнів WARNING та вище. Переключення рівня — через COption::GetOptionString('parser', 'log_level', 'INFO').

Мониторинг на основі логів

Логи самі по собі не допоможуть, якщо їх ніхто не читає. Додайте агент, що запускається кожні 15 хвилин, що рахує кількість ERROR-записів за період. Якщо поріг перевищений — сповіщення (поштова подія або Telegram). Це перетворює логування з пасивного інструменту на активну систему мониторингу.

Підсумок налаштування за один день

1. Клас ParserLogger з рівнями DEBUG/INFO/WARNING/ERROR.
2. Файлові логи з ротацією у /local/logs/parser/.
3. Дублювання WARNING+ у b_event_log.
4. Переключення рівня через адмінку без деплоя.
5. Агент мониторингу помилок у логах.