Настройка интеграции с системами мониторинга (Zabbix, Prometheus) 1С-Битрикс
Сайт на Битриксе упал в пятницу вечером, а узнали об этом в понедельник из письма клиента. Классическая ситуация, если нет мониторинга. Штатный модуль «Монитор производительности» (perfmon) показывает метрики в админке, но не умеет отправлять алерты, строить графики за произвольный период и интегрироваться с дежурной командой. Для этого нужны внешние системы — Zabbix или Prometheus.
Что мониторим
Метрики для Битрикс-сайта делятся на три уровня:
Инфраструктурные (сервер):
- CPU, RAM, disk I/O — базовые системные метрики
- Свободное место на диске (Битрикс любит забивать
/upload/и/bitrix/cache/) - Состояние MySQL/PostgreSQL: количество соединений, slow queries, replication lag
Прикладные (Битрикс):
- Время ответа главной страницы и каталога
- Количество ошибок в
/bitrix/modules/main/classes/general/main.php(500-е ответы) - Размер таблицы
b_event_logиb_cache_tag - Статус cron-агентов (
/bitrix/modules/main/tools/cron_events.php) - Длина очереди почтовых событий (
b_eventсо статусом 1)
Бизнесовые (e-commerce):
- Количество заказов за последний час (резкое падение = проблема)
- Ошибки оплаты (записи в логе платёжных систем)
- Количество брошенных корзин
Вариант 1: Zabbix
Zabbix работает через агент на сервере. Для кастомных метрик Битрикса создаём скрипт, который Zabbix-агент вызывает по расписанию.
Скрипт /opt/zabbix-scripts/bitrix_metrics.sh для базовых проверок:
#!/bin/bash
# Проверка HTTP-ответа
curl -s -o /dev/null -w "%{http_code}" https://example.com/
Для метрик из БД — PHP-скрипт, вызываемый через UserParameter в конфигурации Zabbix-агента:
UserParameter=bitrix.orders.count,php /opt/zabbix-scripts/bitrix_order_count.php
UserParameter=bitrix.cache.size,du -sm /home/bitrix/www/bitrix/cache/ | awk '{print $1}'
UserParameter=bitrix.agents.stuck,php /opt/zabbix-scripts/bitrix_stuck_agents.php
PHP-скрипт подключает ядро Битрикса (/bitrix/modules/main/include/prolog_before.php), выполняет запрос и возвращает число в stdout. Zabbix собирает значение, хранит историю, строит графики и отправляет триггеры.
Триггеры (примеры):
- HTTP-ответ ≠ 200 более 2 минут → CRITICAL
- Заказов за последний час = 0 (при обычной нагрузке > 5) → WARNING
- Свободное место < 10% → WARNING, < 5% → CRITICAL
- Зависшие агенты (разница
NEXT_EXECи NOW() > 1 час) → WARNING
Вариант 2: Prometheus + Grafana
Prometheus работает по pull-модели: опрашивает HTTP-эндпоинт, который возвращает метрики в текстовом формате.
Создаём эндпоинт /local/metrics/index.php, который отдаёт метрики в формате Prometheus:
# HELP bitrix_orders_total Total orders count
# TYPE bitrix_orders_total counter
bitrix_orders_total 12345
# HELP bitrix_orders_last_hour Orders in last hour
# TYPE bitrix_orders_last_hour gauge
bitrix_orders_last_hour 17
# HELP bitrix_cache_size_mb Cache directory size in MB
# TYPE bitrix_cache_size_mb gauge
bitrix_cache_size_mb 2048
# HELP bitrix_agents_stuck Number of stuck agents
# TYPE bitrix_agents_stuck gauge
bitrix_agents_stuck 0
Эндпоинт обязательно закрывается от публичного доступа: либо Basic Auth, либо whitelist по IP в nginx, либо отдельный порт. Метрики содержат чувствительную информацию.
В prometheus.yml добавляем job:
- job_name: 'bitrix'
scrape_interval: 30s
static_configs:
- targets: ['example.com:9100']
Визуализация — через Grafana. Дашборд с панелями: HTTP latency (graph), заказы в час (stat), ошибки (alert list), место на диске (gauge).
Что выбрать
Zabbix — если уже развёрнут в компании. Поддерживает push и pull, имеет встроенные шаблоны для Linux, MySQL, nginx. Тяжелее в настройке, но мощнее в плане discovery и корреляции событий.
Prometheus + Grafana — если инфраструктура в Docker/Kubernetes или команда предпочитает cloud-native стек. Легче стартовать, лучше визуализация, проще горизонтальное масштабирование.
Настройка базового мониторинга (5-7 метрик, алерты в Telegram/Slack) занимает один рабочий день при условии, что Zabbix или Prometheus уже развёрнуты.