Налаштування інтеграції з системами моніторингу (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)
Бізнесовi (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 уже розгорнуті.