Логирование и мониторинг интернет-магазина (Prometheus, Grafana)

О том, что магазин лежит, вы узнаёте от клиента в чате поддержки — а не от системы мониторинга за десять минут до того, как проблема стала заметна. Или оформление заказа тихо замедлилось после релиза, конверсия просела, и вы поняли это только по выручке в конце недели. Пока за магазином на 1С-Битрикс никто не наблюдает системно, вы управляете им вслепую и разбираете инциденты постфактум, теряя заказы и время.

В этой статье разберём, как настроить логирование и мониторинг интернет-магазина на 1С-Битрикс с помощью Prometheus и Grafana: какие метрики снимать с инфраструктуры, приложения и бизнеса, как сделать свой экспортёр для заказов, как задать SLO и осмысленные алерты. Настройку наблюдаемости и оптимизацию мы делаем в рамках услуги по аудиту и оптимизации 1С.

Зачем магазину мониторинг

Мониторинг решает три задачи. Первая — узнавать о проблемах раньше клиентов: алерт о росте ошибок или замедлении приходит команде до того, как посыпятся жалобы. Вторая — быстро находить причину: когда что-то сломалось, метрики и логи показывают, где именно — в базе, в PHP, в обмене с 1С или в инфраструктуре. Третья — видеть тренды: как система ведёт себя под нагрузкой, хватает ли ресурсов, не деградирует ли скорость от релиза к релизу.

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

Логи против метрик

Логи и метрики — разные инструменты, и полноценная наблюдаемость нужна обоих.

Схема работы такая: метрика говорит «выросли ошибки оформления заказа» и поднимает алерт, а логи отвечают, почему именно — какой запрос упал, у какого пользователя, с какой ошибкой. Метрики — для наблюдения и оповещения, логи — для расследования. Эта статья в основном про метрики и стек Prometheus/Grafana, но без разбора логов картина неполна.

Как работают Prometheus и Grafana

Стек устроен просто и модульно. Prometheus — база временных рядов: он по расписанию опрашивает (scrape) эндпоинты-экспортёры, которые отдают метрики в текстовом формате «имя_метрики значение», и хранит эти числа во времени. Grafana подключается к Prometheus как к источнику данных и рисует дашборды, а также умеет отправлять алерты.

Ключевые компоненты вокруг магазина:

• node_exporter. Метрики сервера: CPU, память, диск, сеть.
• Экспортёры сервисов. Для nginx, PHP-FPM, MySQL/MariaDB — отдают их внутренние показатели.
• Свой экспортёр Битрикс. Прикладные и бизнес-метрики магазина.
• Alertmanager. Маршрутизация и группировка оповещений (в связке с Prometheus).

Важное свойство стека — он независим от того, что наблюдает: те же Prometheus и Grafana одинаково работают и для сервера, и для базы, и для бизнес-показателей. Достаточно, чтобы источник отдавал метрики в понятном формате.

Метрики инфраструктуры

Начинают всегда с фундамента — «жив ли и здоров ли сервер». Это самый дешёвый в настройке и самый первый по важности слой.

• Сервер. Загрузка CPU, свободная память, место на диске, ввод-вывод, сеть.
• nginx. Число запросов, распределение кодов ответа (особенно рост 5xx и 4xx), активные соединения.
• PHP-FPM. Активные и простаивающие процессы, длина очереди, время обработки — по ним видно, упирается ли магазин в бэкенд.
• MySQL/MariaDB. Соединения, медленные запросы, использование пулов и кэшей, репликация.

Именно инфраструктурный слой чаще всего первым сигнализирует о беде: очередь PHP-FPM растёт, диск заканчивается, база захлёбывается медленными запросами. Правильно заложенная инфраструктура упрощает и мониторинг — про это наш материал про инфраструктуру и BitrixVM.

Метрики приложения Битрикс

Следующий слой — «работает ли магазин с точки зрения пользователя». Здесь снимают показатели самого приложения, а не только железа.

• Время ответа ключевых страниц. Главная, каталог, карточка товара, корзина, оформление — отдельно, потому что критичность у них разная.
• Hit rate кэша. Насколько эффективно работает кэш Битрикса и композитный сайт; падение hit rate — ранний признак проблем.
• Ошибки приложения. Частота PHP-ошибок и исключений, фатальные ошибки.
• Агенты и очереди. Отрабатывают ли фоновые задачи, не копится ли очередь.

Эти метрики связывают инфраструктуру с бизнесом: замедление оформления при нормальном железе может означать неоптимальные запросы или проблемы с кэшем. Про грамотную работу с базой через объектную модель — наш материал про D7 ORM в Битрикс, а про безопасную выкатку изменений, которые влияют на скорость, — про CI/CD и деплой.

Бизнес-метрики заказов

Самый ценный слой — бизнес-метрики. Они отвечают на главный вопрос: «зарабатывает ли магазин прямо сейчас». Технические метрики могут быть в норме, а заказы при этом не идут — например, сломалась оплата или обмен с 1С.

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

Свой экспортёр для Битрикс

Бизнес-метрики не появятся сами — под них делают собственный экспортёр: эндпоинт или скрипт на стороне Битрикс, который считает показатели и отдаёт их в формате Prometheus. Prometheus опрашивает этот адрес по расписанию.

1. Считайте по данным Sale. Число заказов, ошибки оплаты, статусы — через D7-запросы к модулю «Интернет-магазин».
2. Кэшируйте результат. Не пересчитывайте тяжёлые метрики на каждый scrape — обновляйте кэш раз в минуту.
3. Отдавайте в формате Prometheus. Простой текст «metric_name value» с нужными метками.
4. Закройте эндпоинт. Доступ к метрикам — только для сервера Prometheus, не наружу.
5. Версионируйте. Экспортёр лучше оформить отдельным модулем и катить через CI/CD.

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

Логирование и его сбор

Метрики скажут, что и насколько сломалось, но почему — расскажут логи. Чтобы они помогали, а не мешали, логирование должно быть организованным.

• Структурированный формат. Логи в едином виде (по возможности JSON) проще искать и фильтровать, чем сплошной текст.
• Уровни. Разделение на debug/info/warning/error, чтобы не тонуть в шуме и видеть важное.
• Контекст. Идентификатор заказа, пользователя, запроса — чтобы связать событие с конкретным инцидентом.
• Централизованный сбор. Логи со всех серверов стекаются в одно место (Loki, ELK), а не лежат россыпью по машинам.
• Ротация и хранение. Старые логи чистятся, чтобы не забить диск, но важное хранится достаточно долго.

Связка метрик и логов даёт полную картину: алерт по метрике приводит вас к нужному отрезку времени, а логи за этот отрезок показывают конкретную причину. Без структурированных логов расследование инцидента превращается в раскопки, которые съедают самое дорогое — время простоя.

SLO и осмысленные алерты

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

Разумные SLO для магазина:

• Доступность каталога. Например, 99,9% успешных ответов в месяц.
• Скорость оформления. Оформление заказа отвечает быстрее заданного порога в 99% случаев.
• Успешность оплаты. Доля успешных платежей не ниже целевой.

Алерты строят на симптомах, влияющих на клиента (рост 5xx, замедление оформления, падение заказов), с выдержкой по времени, чтобы не срабатывать на секундные всплески. Каждый алерт должен требовать действия: если на него никто не реагирует, его чинят или удаляют. Хороший набор алертов — это несколько важных сигналов, а не сотня «мигающих лампочек».

Дашборды в Grafana

Дашборд — это не «все метрики на одном экране», а инструмент для ответа на конкретный вопрос. Полезно иметь несколько дашбордов под разные задачи.

• Обзорный. Один экран «всё ли хорошо»: заказы, ошибки, время ответа, здоровье серверов.
• Инфраструктурный. Детально по серверам, nginx, PHP-FPM, базе — для расследования технических проблем.
• Бизнес. Заказы, оплаты, обмен с 1С, воронка оформления — для владельца и маркетинга.
• Инцидентный. Сборка метрик под разбор конкретного типа проблем.

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

Внедрение пошагово

Наблюдаемость выстраивают слоями, от простого к ценному:

1. Разверните стек отдельно. Prometheus и Grafana на отдельном сервере, чтобы пережить падение боевого.
2. Снимите инфраструктуру. node_exporter и экспортёры nginx, PHP-FPM, MySQL.
3. Добавьте метрики приложения. Время ответа ключевых страниц, hit rate кэша, ошибки.
4. Сделайте экспортёр заказов. Бизнес-метрики через модуль Sale с кэшированием.
5. Организуйте логи. Структурированный формат и централизованный сбор.
6. Задайте SLO и алерты. Цели по критичным путям и оповещения на симптомы.
7. Соберите дашборды. Обзорный, инфраструктурный, бизнес и инцидентный.
8. Обкатайте на инцидентах. Проверьте, что алерты ловят реальные проблемы, и уберите шумные.

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

• Мониторинг на том же сервере. Упал магазин — пропал и мониторинг, данные потеряны в момент инцидента.
• Только инфраструктура. Железо в норме, а заказы не идут — бизнес-метрик нет, проблему не видно.
• Метрики без кэша. Тяжёлый экспортёр считает всё на каждый scrape и сам нагружает базу.
• Шумные алерты. Сотня оповещений, на которые перестают реагировать, — важное тонет.
• Алерты без SLO. Пороги «на глаз» вместо целей по качеству сервиса.
• Логи без структуры и контекста. Расследование инцидента превращается в раскопки.
• Открытый эндпоинт метрик. Внутренние показатели доступны наружу — риск утечки.

Чек-лист внедрения

1. Стек вынесен отдельно. Prometheus и Grafana не на боевом сервере магазина.
2. Инфраструктура под наблюдением. Сервер, nginx, PHP-FPM, база отдают метрики.
3. Приложение измеряется. Время ответа ключевых страниц и hit rate кэша.
4. Экспортёр заказов работает. Заказы, оплаты, обмен с 1С — с кэшированием и закрытым доступом.
5. Логи собираются. Структурированные, с контекстом, централизованно.
6. SLO заданы. Цели по каталогу, оформлению и оплате.
7. Алерты осмысленны. На симптомы клиента, с выдержкой, каждый требует действия.
8. Дашборды под задачи. Обзорный, инфраструктурный, бизнес, инцидентный.

Вывод

Логирование и мониторинг превращают эксплуатацию магазина из тушения пожаров в управляемый процесс. Prometheus и Grafana дают стандартный, независимый от объекта стек: собрать метрики, хранить историю, рисовать дашборды и вовремя оповещать. Стройте наблюдаемость слоями — сначала инфраструктура, потом приложение, потом бизнес-метрики заказов, — и каждый слой закроет свой класс проблем.

Главное — довести дело до бизнес-метрик и осмысленных алертов: график «заказов в минуту» и оповещение на его падение часто спасают выручку быстрее любых технических дашбордов. Разнесите мониторинг на отдельный сервер, свяжите метрики с логами для расследований и задайте SLO по критичным путям. Тогда о проблемах вы будете узнавать раньше клиентов и чинить их по данным, а не по догадкам.