Настройка логирования процесса автонаполнения 1С-Битрикс

Представьте: вы запустили парсинг каталога из 10 000 товаров, через час смотрите — импортировалось всего 300. Без логов — гадание: то ли источник вернул пустую страницу, то ли XPath сломался, то ли лимит памяти PHP кончился на 50 000-м товаре. С логами — сразу видите, что на 501-м товаре упал memory limit за 128 МБ. Настройка структурированного логирования — не роскошь, а необходимость для любого проекта с автонаполнением. Наш опыт показывает, что правильная конфигурация сокращает время разбора инцидента с часов до минут. На одном проекте мы ускорили поиск ошибок в 6 раз, внедрив единый формат с контекстом и ротацией. Разберём, как организовать логи так, чтобы не тратить время на гадания.

"Без контекста логи — это шум. Мы перестали гадать, когда добавили контекст в каждый вызов." — Иван, ведущий разработчик проекта с 5000+ сущностей.

Уровни логирования

Используйте стандартные уровни PSR-3, даже если не подключаете Monolog. Уровни управляют объёмом записываемой информации:

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

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

Куда писать логи: файл, b_event_log или кастомная таблица?

Выбор хранилища зависит от интенсивности парсинга и требований к аналитике. Сравним варианты:

Файловая система. Пишем в /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. Ротация — через logrotate или собственный агент, удаляющий файлы старше 30 дней. Без ротации логи DEBUG-уровня за неделю легко займут гигабайты.

Таблица b_event_log. Штатный журнал Битрикс. Вызов CEventLog::Add() с параметрами. Плюс — просмотр через админку, фильтрация, доступ для менеджеров без SSH. Минус — таблица не рассчитана на тысячи записей в минуту, при интенсивном парсинге тормозит. Поэтому b_event_log используйте для WARNING и ERROR, а DEBUG пишите в файл.

Кастомная таблица. Создаём таблицу 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?

Создайте класс 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). Это превращает логирование из пассивного инструмента в активную систему мониторинга. На практике мы видели, как такой агент помог предотвратить простой интернет-магазина: ошибка из-за изменения структуры HTML на сайте источника была замечена через 3 минуты, а не через 3 часа.

Что входит в настройку логирования под ключ

Мы предлагаем комплексную настройку логирования для вашего проекта:

• Класс ParserLogger с уровнями DEBUG/INFO/WARNING/ERROR и автоматической записью в файл и b_event_log.
• Файловые логи с ротацией в /local/logs/parser/ (хранение 30 дней).
• Возможность переключения уровня через админку без деплоя.
• Агент мониторинга ошибок с уведомлениями.
• Документация по использованию и инструкция для команды.

Мы работаем с Битриксом более 10 лет, реализовали 50+ проектов с автонаполнением и интеграцией 1С. Гарантируем, что после настройки вы сможете разбирать любую ошибку парсера за минуты. Оценим ваш проект бесплатно — свяжитесь, чтобы обсудить детали. Закажите настройку логирования под ключ и экономьте часы на отладке.

Разработка парсеров для 1С-Битрикс: с чего начать?

XMLReader, а не SimpleXML — выбор инструмента определяет судьбу проекта. SimpleXML загружает весь XML в память, и при файле поставщика на 800 МБ PHP упадёт с fatal error на лимите 512 МБ. XMLReader обрабатывает потоково, node за node, потребляя 20–30 МБ — в 30 раз эффективнее. С этой детали стартует любая разработка парсеров под Битрикс. Мы делаем такие системы уже 10+ лет, и ни один проект не обходится без правильного выбора парсера.

Какие проблемы решает парсинг?

• Первичное наполнение каталога — 15 000 карточек с описаниями, характеристиками, фото. Вручную это три месяца контент-менеджера; парсер — неделя с отладкой.
• Мониторинг цен конкурентов — сбор данных с Ozon, Wildberries, сайтов конкурентов. Конкурент снизил цену на ходовую позицию — узнаёте через два часа, а не через две недели.
• Агрегация поставщиков — пять прайсов в разных форматах (CSV с CP1251, XML в CommerceML, Excel с объединёнными ячейками) превращаются в единый каталог с общей системой свойств инфоблока.
• Обогащение карточек — подтягиваем характеристики, инструкции, 3D-модели с сайтов производителей. Без этого карточка товара — пустышка для SEO.
• Обновление ассортимента — товары, пропавшие из фида поставщика, деактивируются через CIBlockElement::Update($ID, ['ACTIVE' => 'N']). Новые — создаются. Каталог синхронизирован.

Какие инструменты используем в разработке парсеров?

Статические сайты — PHP (Goutte, Symfony DomCrawler) или Python (Scrapy, lxml). Скорость: 50–100 страниц/сек. Хватает для каталогов без JS-рендеринга.

SPA и динамические сайты — Puppeteer или Playwright. Бесконечный скролл, AJAX-фильтры, lazy-load картинок — headless-браузер всё это обработает. Скорость падает до 1–10 страниц/сек, но альтернативы нет: данные существуют только после выполнения JavaScript.

Файлы поставщиков:

• Excel (XLS, XLSX) — PhpSpreadsheet. Осторожно с объединёнными ячейками и формулами — они ломают автоматический маппинг.
• CSV — fgetcsv() с правильной кодировкой. Поставщики любят CP1251, BOM в UTF-8 и точку с запятой вместо запятой. Всё это нужно детектить и обрабатывать.
• XML/YML — XMLReader для больших файлов, SimpleXML для фидов до 50 МБ.
• CommerceML — стандартный формат обмена с 1С. Разбираем import.xml и offers.xml, маппим на структуру инфоблоков.

API — REST-эндпоинты поставщиков, API маркетплейсов (Ozon Seller API, Wildberries API). Работаем в рамках rate limits, обрабатываем пагинацию.

Как устроен пайплайн автонаполнения?

Четыре этапа. Каждый может сломаться по-своему.

1. Сбор. Парсер обходит источники по cron-расписанию. Сырые данные пишем в промежуточную таблицу — не сразу в b_iblock_element. Логируем всё: сколько страниц обошли, сколько элементов распарсили, где получили 403 или timeout. Без логов отладка парсера — гадание на кофейной гуще.

2. Нормализация. Здесь основная работа:

   • Очистка HTML-тегов, лишних пробелов, Unicode-мусора
   • Единицы измерения: «мм» → «мм», «millimeters» → «мм», «миллиметр» → «мм»
   • Маппинг категорий поставщика → разделы инфоблока Битрикс. У одного поставщика «Ноутбуки», у другого «Ноутбуки и планшеты», у третьего «Laptops» — всё в одну секцию
   • Дедупликация по артикулу, EAN/GTIN. Один товар от трёх поставщиков не должен появиться трижды

3. Загрузка в Битрикс. Через CIBlockElement::Add() для новых элементов, CIBlockElement::Update() для существующих. Изображения: скачиваем, ресайзим через CFile::ResizeImageGet(), конвертируем в WebP. Свойства — через CIBlockElement::SetPropertyValuesEx(). SEO-мета через \Bitrix\Iblock\InheritedProperty\ElementValues. ЧПУ генерируем из транслитерации названия.

4. Обновление. Ключевой момент — не затереть ручные правки контент-менеджера. Обновляем только цену, остатки, активность. Описание и фото, доработанные вручную, помечаем флагом UF_MANUAL_EDIT в свойствах элемента и пропускаем при импорте. Товары, пропавшие из фида — деактивируем, но не удаляем.

Почему мониторинг цен конкурентов необходим?

Отдельная подсистема со своей спецификой:

Результат — дашборд: ваш товар vs конкуренты, история цен, тренды. Менеджер видит, где можно поднять цену без потери позиции, а где нужно реагировать.

Модуль импорта CSV/XML: настройка под ваш формат

Для файлов от поставщиков — кастомный модуль с админкой:

• Настраиваемый маппинг: «колонка B в файле → свойство BRAND инфоблока»
• Автодетект кодировки (CP1251, UTF-8, UTF-16) через mb_detect_encoding() с проверкой
• Загрузка изображений по URL с очередью — чтобы не забить канал
• Инкрементальное обновление по хешу строки: изменилась строка — обновляем, нет — пропускаем
• Cron-расписание, отчёт: создано 145, обновлено 892, ошибок 3 (с деталями)

Большие файлы: CSV обрабатываем батчами по 1000 строк через fgetcsv(), XML потоково через XMLReader, фоновое выполнение через очередь агентов Битрикс — никаких PHP-таймаутов.

Правовая сторона — что важно учесть

• robots.txt — уважаем. Crawl-delay — соблюдаем.
• Частота запросов — 1–2 в секунду, не больше. Не нужно DDoS-ить чужой сайт.
• Контент производителей — используем. Уникальные авторские тексты — не копируем.
• Персональные данные — не собираем.

Что входит в разработку парсера под ключ?

Как мы работаем и сроки

1. Прототип — парсер для 1–2 источников за 2–3 дня. Оцениваем качество данных, подводные камни (защита Cloudflare, капча, динамическая подгрузка).
2. Разработка — полный пайплайн: парсер → нормализация → импорт в Битрикс → админка для управления.
3. Тестирование — прогоняем на полном объёме каталога, проверяем edge-кейсы (пустые поля, кривой HTML, битые картинки).
4. Запуск — настраиваем cron, мониторинг ошибок через Telegram-бот.
5. Поддержка — конкурент переделал вёрстку? Обновляем CSS-селекторы в парсере.

Свяжитесь для оценки вашего проекта — мы предложим оптимальное решение под ваш бюджет. Гарантируем стабильную работу парсеров и полную поддержку в течение всего срока использования.