П'ятниця, 18:00. Сайт на Бітріксі лежить. Менеджери не бачать замовлення, клієнти скаржаться, а DevOps дізнається про проблему в понеділок з листа. Типова ситуація: база впала через slow queries, агенти не обробили поштові події, а диск забитий кешем. Вбудований модуль Монітор продуктивності (perfmon) показує метрики тільки в адмінці — він не алертить в Telegram, не будує дашборди за довільний період і не інтегрується з черговою командою. Рішення — зовнішні системи: Zabbix або Prometheus з Grafana. Ми налаштовуємо такий моніторинг 1С-Бітрікс більше 10 років, виконали понад 50 проєктів. Один годину простою інтернет-магазину може коштувати значних втрат виручки — грамотний моніторинг окупається за лічені дні.
Що моніторимо
Метрики поділяються на три рівні: інфраструктурні, прикладні та бізнесові. Інфраструктурні (сервер):
- CPU, RAM, disk I/O
- Вільне місце на диску (Бітрікс активно пише в
/upload/та/bitrix/cache/) - Стан MySQL: кількість з'єднань, slow queries, replication lag
Прикладні (Бітрікс):
- Час відповіді головної сторінки та каталогу
- Кількість помилок 500 в логах
- Розмір таблиці
b_event_logтаb_cache_tag - Статус cron-агентів (
/bitrix/modules/main/tools/cron_events.php) - Довжина черги поштових подій (
b_eventзі статусом 1)
Бізнесові (e-commerce):
- Кількість замовлень за останню годину (різке падіння = проблема)
- Помилки оплати (записи в лозі платіжних систем)
- Кількість покинутих кошиків
Ці метрики дозволяють оперативно реагувати на збої та запобігати втраті виручки. Економія від запобігання одному інциденту може бути значною.
Чому моніторинг критичний для Бітрікс-сайту?
Без моніторингу ви дізнаєтесь про проблему від клієнтів. З моніторингом — за 5 хвилин до того, як проблема вплине на користувачів. Раптовий ріст slow queries або заповнення диска кешем — типові причини падіння Бітрікса. Алерти в Telegram або Slack дозволяють DevOps-інженеру усунути причину до того, як сайт стане недоступним.
Варіант 1: Zabbix
Zabbix працює через агент на сервері. Для кастомних метрик Бітрікса створюємо скрипт, який Zabbix-агент викликає за розкладом.
Приклад скрипта для Zabbix
#!/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, замовлення на годину, помилки, місце на диску.
Як вибрати між Zabbix і Prometheus?
Порівняння ключових характеристик допоможе прийняти рішення.
| Параметр | Zabbix | Prometheus + Grafana |
|---|---|---|
| Модель збору | Push і Pull | Pull (може Push через Pushgateway) |
| Зберігання даних | Своя БД | In-memory + TSDB |
| Візуалізація | Вбудована | Grafana (окремо) |
| Алертинг | Вбудовані тригери | Alertmanager |
| Готові шаблони для Бітрікса | Ні (створюємо самі) | Ні (створюємо самі) |
| Інтеграція з Docker/K8s | Середня | Відмінна |
Zabbix — якщо вже використовується в компанії. Prometheus — якщо інфраструктура в Docker або K8s. Налаштування базового моніторингу (5-7 метрик, алерти в Telegram) займає один день за умови розгорнутої системи.
Типові метрики та їх пороги
| Метрика | Норма | Тривога | Критично |
|---|---|---|---|
| HTTP 200 | 100% | <99.5% за 5 хв | <99% |
| Час відповіді | <1 сек | >2 сек | >5 сек |
| Вільне місце | >20% | <10% | <5% |
| Завислі агенти | 0 | >0 за 30 хв | >0 за 1 год |
Як ми налаштовуємо моніторинг: 3 кроки
- Аудит і метрики — аналізуємо поточну інфраструктуру, визначаємо критичні метрики (інфраструктурні, прикладні, бізнесові). Складаємо карту моніторингу.
- Створення скриптів та інтеграція — пишемо bash/PHP-скрипти для збору метрик, налаштовуємо конфігурацію Zabbix/Prometheus, тригери та алерти в Telegram/Slack.
- Дашборд і документація — розробляємо дашборд в Grafana (якщо обрано Prometheus), тестуємо сценарії збоїв, передаємо документацію та навчаємо чергову команду.
Наприклад, на одному з наших проєктів ми налаштували моніторинг агентів Бітрікса. Виявилося, що один агент не виконувався через помилку в коді, що призводило до затримок у обробці замовлень. Після налаштування алерту в Telegram, розробник отримав сповіщення за 5 хвилин до того, як проблема вплинула на клієнтів, і швидко виправив помилку. Час простою скоротився з 2 годин до 10 хвилин.
Що входить у налаштування
- Аудит поточного стану сайту та сервера
- Визначення переліку критичних метрик
- Створення скриптів для збору метрик (bash/PHP)
- Налаштування тригерів та алертів в Telegram/Slack
- Розробка дашборду в Grafana (якщо обрано Prometheus)
- Тестування та документація
- Навчання чергової команди
Гарантуємо, що після налаштування ви будете отримувати сповіщення про проблеми за 5-10 хвилин до їх впливу на користувачів.
Строки та вартість
Строк налаштування — від 1 до 3 днів залежно від складності інфраструктури та кількості метрик. Вартість розраховується індивідуально після аудиту. Замовте аудит сьогодні — отримайте консультацію щодо вибору системи моніторингу. Типова економія від впровадження — суттєве скорочення простоїв.
За даними офіційної документації 1С-Бітрікс, впровадження зовнішнього моніторингу скорочує час простою в середньому на 80%.