Логирование и трассировка запросов в e-commerce

Клиент звонит: «Я оплатил, а заказ не пришёл». Вы открываете админку — заказа нет. Оплата была? Обмен с 1С прошёл? На каком шаге всё сломалось? Если в системе нет нормального логирования, ответ на эти вопросы — часы раскопок и разговоров «а вот у меня всё работает». А если есть — минута поиска по идентификатору заказа, и вы точно видите, где именно оборвалась цепочка.

Логирование и трассировка запросов — это «чёрный ящик» интернет-магазина: то, что в момент инцидента отличает быстрый точный диагноз от беспомощного гадания. В этой статье разберём, как выстроить логирование в e-commerce на 1С-Битрикс: чем логи отличаются от трассировки, зачем нужен correlation id, что критично записывать в обмене с 1С и оплате и как не превратить логи в свалку. Диагностика проблем на стыке систем — часть аудита интеграций и e-commerce.

Почему без логов e-commerce слепнет

Интернет-магазин — это не один сайт, а связка систем: витрина на 1С-Битрикс, учётная система 1С, платёжный шлюз, службы доставки, иногда внешние сервисы. Запрос пользователя проходит через несколько из них, и сбой может случиться на любом стыке. Без логов вы видите только результат — «заказ не пришёл», — но не путь, которым он к этому результату пришёл.

Цена этой слепоты — время и деньги. Каждый неразобранный инцидент — это раздражённый клиент, потерянный заказ и часы разработчика, потраченные на воспроизведение проблемы вместо её решения. Хорошее логирование переворачивает ситуацию: вместо «давайте попробуем повторить и посмотрим» вы говорите «вот лог этого заказа, сбой произошёл на шаге обмена в такой-то момент по такой-то причине». Это разница между реактивным тушением и управляемой эксплуатацией.

Логирование и трассировка: в чём разница

Эти два понятия часто путают, хотя они отвечают на разные вопросы и работают вместе:

Логирование даёт глубину в точке: подробности конкретного события. Трассировка даёт связность: она сшивает разрозненные логи в единую историю одного запроса и показывает, на каком именно этапе цепочка сломалась. В e-commerce, где запрос ходит между сайтом, 1С и платёжкой, нужны оба: без логов трассировка пуста, без трассировки логи разрознены.

Correlation id как сквозная нить

Инструмент, который превращает разрозненные логи в трассировку, — correlation id. Это уникальная метка, присваиваемая запросу в самом начале (например, при оформлении заказа) и передаваемая дальше через все системы: сайт, обмен с 1С, платёжный шлюз, очереди. Все события, порождённые этим запросом, помечаются одним и тем же id.

Что это даёт на практике:

• Сборку истории заказа. По одному id вы собираете все логи, относящиеся к заказу, из всех систем сразу.
• Работу в распределённой среде. Даже если события на разных серверах и в разных сервисах, id связывает их.
• Быстрый диагноз. Клиент называет номер заказа — вы находите всю цепочку и точку сбоя за секунды.
• Связь с клиентом. Id можно показать клиенту в поддержке, чтобы обе стороны говорили об одном и том же запросе.

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

Не все события одинаково важны, и писать всё подряд одним потоком — путь к нечитаемым логам. Стандартная шкала уровней помогает отделить сигнал от шума:

• DEBUG. Подробности для отладки: значения переменных, шаги алгоритма. На бою обычно выключен.
• INFO. Нормальные бизнес-события: заказ создан, обмен прошёл, оплата подтверждена.
• WARNING. Подозрительное, но не фатальное: повторная попытка, медленный ответ, необычные данные.
• ERROR. Ошибка, операция не выполнена: заказ не сохранился, обмен упал, платёж отклонён.
• CRITICAL. Сбой, ломающий бизнес: не работает оплата или обмен целиком.

На боевом магазине обычно пишут от INFO и выше, а DEBUG включают точечно при разборе конкретной проблемы, чтобы не захламлять логи и не тормозить систему. Уровни позволяют быстро отфильтровать «покажи только ошибки» и не тонуть в информационном шуме, когда ищешь причину сбоя.

Что критично логировать в магазине

Логировать всё подряд не нужно и вредно — важно покрыть ключевые бизнес-точки, где чаще всего ломается и откуда идут претензии. Приоритетный список для e-commerce:

1. Жизненный цикл заказа. Создание, изменение статуса, отмена — с составом и суммой.
2. Оплата. Каждый шаг: запрос в платёжку, её ответ, смена статуса, ошибки и таймауты.
3. Обмен с 1С. Выгрузка заказов, загрузка цен и остатков, ошибки сопоставления, результат.
4. Изменения цен и наличия. Когда и откуда поменялись — чтобы разбирать «почему клиент увидел не ту цену».
5. Авторизация и кабинет. Вход, действия с заказами, чувствительные операции.

Эти точки объединяет одно: их сбой напрямую бьёт по деньгам и по доверию клиента. Именно поэтому здесь нужна детальная и надёжная запись с correlation id, а не «авось разберёмся». Остальное можно логировать скромнее.

Обмен с 1С: самая частая точка сбоя

Обмен между сайтом и 1С (через CommerceML и штатные механизмы) — самое частое место, где что-то идёт не так, и одновременно самое непрозрачное без логов. Заказы не выгружаются, цены приходят не те, остатки расходятся, товары не сопоставляются — и всё это молча, если обмен не логируется.

Что важно фиксировать в обмене:

• Старт и результат сессии обмена. Когда началась, что выгружалось/загружалось, чем закончилась.
• Ошибки сопоставления. Товар из 1С не нашёл соответствия на сайте — с идентификаторами.
• Расхождения данных. Цена или остаток пришли неожиданными — сигнал проблемы на стороне учёта.
• Тайминги. Сколько длился обмен — деградация времени говорит о росте данных или проблемах.

Хорошее логирование обмена превращает загадочные «у клиента не та цена» в конкретный лог с id товара и моментом изменения. Это основа надёжной интеграции, которую мы закладываем при переезде e-commerce на новую CMS и разбираем в связке с архитектурой обмена. Технические детали работы с данными на уровне ORM — в статье про D7 ORM в 1С-Битрикс.

Оплата и платёжные системы

Оплата — вторая критичная зона, где сбой сразу превращается в претензию «списали деньги, а заказа нет» или наоборот «заказ есть, оплаты нет». Платёжный поток проходит через внешнюю систему, поэтому без логов вы не видите, что происходило на её стороне.

Логировать нужно весь цикл оплаты:

• Инициацию платежа. Какая сумма, по какому заказу ушла в платёжную систему.
• Ответы и коллбэки. Что вернула платёжка, включая коды ошибок и статусы.
• Смену статуса заказа. Как ответ платёжки повлиял на заказ — оплачен, отклонён, ждёт.
• Расхождения сумм. Если сумма списания не совпала с суммой заказа — немедленный сигнал.

При этом действует жёсткое правило безопасности: в логи нельзя писать полные номера карт, CVV и другие платёжные секреты — только маскированные данные и идентификаторы транзакций. Корректная и безопасная работа с платёжными коллбэками тесно связана с защитой интеграций, о чём мы писали в статье про REST, вебхуки и безопасность в Битрикс.

Структурированные логи и поиск

Лог, в котором события написаны свободным текстом, годится для маленького сайта, но не для e-commerce под нагрузкой. Когда логов гигабайты и они разбросаны по серверам, грепать текст бесполезно. Нужны структурированные логи — записи с чёткими полями, по которым можно искать.

Структурированная запись содержит поля, а не просто строку:

• Время с точностью до миллисекунд.
• Correlation id — та самая сквозная нить.
• Уровень — INFO, ERROR и так далее.
• Компонент — обмен, оплата, заказ, каталог.
• Идентификаторы — id заказа, клиента, товара.
• Сообщение и контекст — что произошло и с какими данными.

По таким полям можно мгновенно отфильтровать «все ошибки обмена за последний час» или «всё по заказу №12345». Это превращает разбор инцидента из археологических раскопок в точечный запрос. Структурированность — необходимое условие для централизованного сбора и анализа логов.

Логи и производительность

Логирование полезно не только для ошибок, но и для скорости. Если фиксировать время выполнения ключевых операций, логи становятся источником данных о том, где магазин «тормозит»:

• Тайминги операций. Генерация страницы, запрос к базе, ответ обмена, вызов платёжки — с длительностью.
• Медленные запросы. Что выходит за порог по времени — прямые кандидаты на оптимизацию.
• Деградация под нагрузкой. Растут ли тайминги в пиковые часы — сигнал о нехватке ресурсов.
• Узкие места по шагам. Трассировка с таймингами показывает, на каком этапе теряются миллисекунды.

Такие данные превращают оптимизацию из гадания в целенаправленную работу: вы видите не «сайт тормозит вообще», а «на шаге загрузки цен из обмена уходит столько-то, и это узкое место». Это фундамент системного ускорения каталога и e-commerce: сначала измерить логами, где медленно, потом целенаправленно чинить.

Безопасность и персональные данные

Логи — это данные, и к ним применимы те же требования безопасности, что и к остальной системе. Беспечное логирование само становится уязвимостью и нарушением закона о персональных данных.

Правила безопасного логирования:

• Никаких секретов. Пароли, CVV, полные номера карт, токены — не логируются никогда.
• Маскирование. Номер карты — только в маскированном виде, чувствительные поля — частично.
• Минимум персональных данных. Логируйте идентификаторы (id заказа, id клиента), а сами ФИО, телефоны и адреса — по минимуму и с учётом требований защиты.
• Ограниченный доступ. К логам имеют доступ только те, кому это нужно; логи защищены как и остальные данные.

Хороший приём — писать в логи ссылки на данные, а не сами данные: id заказа вместо полного состава с адресом. Тогда для диагностики достаточно найти запись по id и, при необходимости, посмотреть детали в защищённой базе, а не хранить персональные данные россыпью в текстовых логах.

Хранение, ротация и сбор логов

Логи, которые бесконтрольно растут, однажды заполнят диск и положат сайт — это классический инцидент. Поэтому эксплуатация логов не менее важна, чем сама запись:

1. Ротация. Логи разбиваются по времени/размеру, старые архивируются, чтобы файлы не росли бесконечно.
2. Сроки хранения по типу. Оперативные логи диагностики — недели; важные бизнес-события (оплаты, заказы) — дольше, с учётом требований учёта.
3. Централизованный сбор. Логи со всех серверов стекаются в отдельную систему — переживают перезапуск и доступны для поиска.
4. Мониторинг и алерты. На критичные ошибки (упал обмен, посыпались платежи) настраиваются оповещения, чтобы узнавать раньше клиента.

Централизованный сбор особенно важен для магазинов на нескольких серверах: без него логи разбросаны и теряются при перезапуске. Инфраструктурная сторона этого вопроса — где и как хранить логи, как настроить сбор — тесно связана с организацией сервера, о чём мы писали в статье про хостинг и инфраструктуру BitrixVM.

Частые ошибки

• Нет correlation id. Логи есть, но связать события одного заказа через системы невозможно.
• Логируют всё подряд. Без уровней логи превращаются в шум, где не найти ошибку.
• Свободный текст вместо структуры. По неструктурированным логам нельзя нормально искать.
• Не логируют обмен и оплату. Самые ломкие точки остаются чёрным ящиком.
• Секреты в логах. Пароли и номера карт попадают в текстовые файлы — уязвимость и нарушение.
• Нет ротации. Логи растут, пока не заполнят диск и не положат сайт.
• Логи только локально. При перезапуске сервера или на нескольких машинах данные теряются.
• Нет алертов. О критичном сбое узнают от клиента, а не из системы.

Чек-лист логирования

1. Correlation id внедрён. Сквозная метка проходит через сайт, обмен 1С и оплату.
2. Уровни используются. INFO и выше на бою, DEBUG точечно; фильтрация по уровню работает.
3. Ключевые точки покрыты. Заказы, оплата, обмен с 1С, цены и наличие логируются детально.
4. Логи структурированы. Поля вместо свободного текста, поиск по id и компоненту возможен.
5. Тайминги пишутся. Длительность ключевых операций фиксируется для анализа скорости.
6. Секреты защищены. Пароли и платёжные данные не логируются, персональные — по минимуму.
7. Ротация и хранение настроены. Логи не переполняют диск, сроки хранения заданы по типу.
8. Централизованный сбор. Логи стекаются в отдельную систему и доступны для поиска.
9. Алерты на критичное. Сбои обмена и оплаты порождают оповещения раньше жалоб клиентов.

Вывод

Логирование и трассировка запросов — это наблюдаемость магазина, то, что в момент инцидента отличает быстрый точный диагноз от беспомощного гадания. В e-commerce, где запрос ходит между сайтом, 1С и платёжной системой, без сквозной нити correlation id и структурированных логов любой сбой на стыке систем превращается в часы раскопок.

Выстройте логирование осознанно: пометьте запросы correlation id, разделите события по уровням, детально покройте самые ломкие точки — заказы, оплату и обмен с 1С, — структурируйте записи, защитите секреты и настройте централизованный сбор с ротацией и алертами. Тогда «я оплатил, а заказа нет» будет разбираться за минуту по идентификатору, а не за день по догадкам, а сами логи станут ещё и источником данных для ускорения магазина на 1С-Битрикс.