Сайт работает, 500-ых нет – но заказы с сайта не поступают. Би��нес теряет деньги, а разработчики даже не подозревают что что-то идет не так. Меня зовут Михаил, я из команды Backend разработки D'Terra. Мы прошли через это и поняли: только system-based метрик недостаточно. Нам нужны бизнес метрики в дашбордах, что бы реагировать на такие инциденты. Поэтому я настроили Prometheus под Bitrix так, чтобы на одном дашборде видеть и «железо», и бизнес-часть сайта.
Принципы работы
На Habr достаточно статей на тему того, как настроить связку Grafana + Prometheus. Вы можете воспользоваться одной из этих инструкций. Для части с системными параметрами и метриками используются стандартные экспортеры. Объем предоставляемой статистики достаточен для построения информативных графиков.
С бизнес метриками все уже не так просто, стандартные решения тут не оптимальный путь. Задачи разные, метрики нужно собирать индивидуальные. Поэтому – кастомные экспортеры.
Пример экспортера, который собирает метрики через API Bitrix и отдаёт их в Prometheus.
<?php
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");
use Bitrix\Main\Loader;
use Bitrix\Main\Type\DateTime;
Loader::includeModule('sale');
Loader::includeModule('form');
$metrics = [];
$ordersResult = \Bitrix\Sale\Order::getList([
'select' => ['ID'],
'filter' => ['STATUS_ID' => 'N'],
'count_total' => true,
]);
$ordersCount = $ordersResult->getCount();
$metrics[] = sprintf(
'bitrix_orders_active{environment="prod",site="main"} %d',
$ordersCount
);
$from = new DateTime(date('Y-m-d H:i:s', strtotime('-5 minutes')));
$formsSubmitted = \Bitrix\Form\ResultTable::getCount([
'>=DATE_CREATE' => $from,
]);
$metrics[] = sprintf(
'bitrix_forms_submitted_5min{environment="prod"} %d',
$formsSubmitted
);
header('Content-Type: text/plain; charset=utf-8');
echo implode("\n", $metrics), "\n";
Ключевые блоки мониторинга
Я бы разделил мониторинг на 4 слоя и связали их метками и переходами:
инфраструктура – сервер, сеть, диски
веб-слой – Nginx, коды ответов, ретраи
приложение – PHP-FPM, очередь, «тяжелые» обработчики
бизнес-метрики – шаги воронки, успешные исходы, SLA внешних провайдеров
Базовые метрики на примере банковского сайта
Основное внимание уделяется метрикам, которые определяют доступность системы: время ответа для 95% пользователей, процент ошибок сервисов и серверов на каждом шаге, стабильность работы базы данных.
Если задержка ответа растёт одновременно с ростом ошибок, значит, проблема кроется в серверной логике. Когда ошибок нет, но время отклика увеличивается, начинаем анализировать очереди обработки и внешние сервисы, например проверки данных. А если замедляется только чтение статуса, это прямой индикатор перегрузки базы.
Бизнес-метрики. Где теряются деньги?
Формы – первичная часть потенциальных потерь, формы любой сложности должны попадать в мониторинг. Например есть многоступенчатая форма, в ней нужно: отслеживать статистики по шагам формы (открыта → заполнена → отправлена → подтверждена) и доля успешных исходов на каждом этапе. Если какое-то звено начинает «проседать» при той же посещаемости – мы получаем кастомный alert. Важно: мы не переносим воронку, мы получаем фактические цифры и сравниваем их с эталонными.
Кейсы:
– Отправок стало меньше при том уже уровне открытий — значит барьер на стороне валидации или UX.
– Если отправки стабильны, но этап с внешнеими интеграциями начинает показывать результаты ниже обычного — смотрим интеграции с внешними провайдерами и их SLA.
В момент инцидента нужен ответ: «что сейчас ломается, почему?». Когда бизнес-шаги воронки живут рядом с system-based метриками в одном инструменте, мы сокращаем среднее время восстановления в 3–5 раз (с ~60 до 10–20 минут).
При стандартной схеме взаимодействия: бизнес замечает критическую аномалию на сайте – сообщает о ней команде разработки, собираются гайды как воспроизвести баг, команда разработки проверяет и делает hot-fix проблемы. При схеме где бизнес-метрики находятся в мониторинге схема значительно проще: Alert из графана, проверка, hot-fix проблемы.
Алерты
Качество alert’ов – критичный фактор. Качество, значительно, важнее объема. Если уведомления приходят слишком часто и не ведут к действию, вырабатывается иммунитет – смысл в системе начинает стремится к нулю.
Нужно оценивать «полезность» — долю сигналов, после которых последовало действие: тикет, фикс, изменение конфигурации, масштабирование и тд. Хороший тон после каждого инцидента пересматривать правила.
Уведомление должно нести контекст: понятный текст, ссылка на нужный дашборд, следующий шаг и ответственный.
Примеры алертов:
🔥 Алерт: ноль подтверждённых заявок
Уровень: CRITICAL
Описание: за последние 10 минут система не зафиксировала ни одного подтверждения заявки в рабочее время. Это может свидетельствовать о с��ое в бизнес-логике или критическом отказе бэкенда.
Контекст: сервис Bitrix / prod / метрика бизнес процессов ✅ Алерт: 5xx вернулось к норме
Уровень: RESOLVED
Описание: доля ответов с кодом 5xx опустилась ниже порога. Инцидент закрыт.
Контекст: Bitrix / prodДашборды
Результаты
После внедрения связки Prometheus и Grafana – мониторинг Bitrix стал предельно полным. Метрики: и бизнесовые, и системные — на одном экране. Видно не просто цифры, а всю картину.
Главное — скорость реакции. Система подает сигнал о проблеме ещё до того, как кто-то вообще поймёт, что что-то не так. Проблемы обнаруживаются сразу, контекст понятен, и не нужно гадать, что делать дальше — всё очевидно.
