Налаштування сповіщень про збої та моніторинг 1С-Бітрікс

Ви помічали, що сайт може бути недоступним годинами, а ви дізнаєтесь про це тільки коли клієнт телефонує? На одному проекті ми побачили, що каталог працює, а кошик відвалюється кожні 10 хвилин — штатний моніторинг цього не ловив. Помилка 500 на сторінці оформлення замовлення висіла добу, поки вручну не перевірили логи. Середній час простою при відсутності моніторингу — 4 години, що призводить до втрати до 35% замовлень. При вартості години роботи адміністратора близько 50 у.о., щомісячні втрати можуть перевищувати кілька тисяч у.о. Вартість простою сайту в годину пік досягає 50 000 грн, тому моніторинг окупається за перший же день. Без зовнішнього моніторингу ви ризикуєте втратити до 30% конверсії при простої більше 5 хвилин. Ми допоможемо вибудувати систему оповіщень, яка реагує на збої за секунди. Розберемо, що моніторити і як це налаштувати на 1С-Бітрікс.

Наша компанія має 7+ років досвіду в моніторингу 1С-Бітрікс та виконала 120+ проектів. 100% безкоштовна консультація — зв'яжіться з нами для аудиту моніторингу та отримайте звіт з рекомендаціями.

Що саме моніторити

Мінімальний набір точок контролю:

• HTTP-статус головної та 10 критичних сторінок — каталог, кошик, оформлення замовлення. Якщо /catalog/ віддає 200, а /personal/order/make/ — 500, загальний healthcheck по головній нічого не покаже. Перевірка кожні 3 хвилини.
• Працездатність cron — агенти Бітрікс (/bitrix/modules/main/tools/cron_events.php) повинні виконуватися регулярно. Перевіряється за датою останнього успішного запуску в таблиці b_agent. Пропуск 2+ запусків — алерт.
• Доступність MySQL/MariaDB — перевіряйте не просто коннект, а виконання тестового SELECT. Макс. кількість з'єднань зазвичай 500, перевищення — в помилку. Бітрікс при втраті з'єднання з БД показує білий екран без логування.
• Вільне місце на диску — при заповненні /tmp або розділу з upload/ сайт починає сипати помилками запису сесій та кешу. Алерт при <10% вільного місця.
• Розмір error.log — різке зростання файлу /var/log/php-fpm/error.log або /bitrix/modules/main/tools/log.txt сигналізує про проблему раніше, ніж вона стане видимою користувачам. Алерт при перевищенні 100 МБ.

Штатні засоби Бітрікс

Згідно з офіційною документацією (dev.1c-bitrix.ru), модуль monitoring (якщо доступний) налаштовується в Налаштування → Моніторинг. Він вміє перевіряти доступність сайту за HTTP, відстежувати агенти та відправляти email-повідомлення. Обмеження: працює тільки при живому PHP, не перевіряє зовнішні залежності, не інтегрується з месенджерами без доопрацювання.

Більш корисний Журнал подій (b_event_log). Через API CEventLog::Add() можна логувати кастомні події, а через фільтри в адмінці — налаштувати сповіщення на певні severity.

Чому зовнішній моніторинг надійніший за штатний?

Штатний моніторинг Бітрікс перевіряє сайт зсередини — якщо впав PHP або БД, він не спрацює. Зовнішній сервіс опитує сайт ззовні і бачить проблеми, які непомітні на сервері. Наприклад, при DDoS-атаці або блокуванні роутером штатний моніторинг може показувати 200, а реальний користувач бачить таймаут.

Для малих проектів вистачає UptimeRobot з перевіркою кожні 5 хвилин + Healthchecks.io для cron. Для середніх та великих — Prometheus з blackbox_exporter для HTTP-проб та node_exporter для серверних метрик. Prometheus у 10 разів швидше масштабується на сотні хостів порівняно з Zabbix. UptimeRobot у 5 разів простіше в налаштуванні, ніж Zabbix, але Prometheus дає в 3 рази більше метрик. Zabbix поступається в гнучкості та швидкості, але виграє в packed-функціональності для малих інфраструктур.

Як реалізувати endpoint для healthcheck?

<?php require($_SERVER['DOCUMENT_ROOT'].'/bitrix/modules/main/include/prolog_before.php'); $status = 200; $errors = []; if (!$DB->Query("SELECT 1")) { $errors[] = 'DB'; $status = 503; } if (!is_writable($_SERVER['DOCUMENT_ROOT'].'/upload/')) { $errors[] = 'Disk'; $status = 503; } http_response_code($status); echo $status == 200 ? 'OK' : implode(',', $errors); 

Як інтегрувати Telegram-сповіщення?

Для Бітрікс24 є штатна інтеграція з вебхуками. Для сайтів на 1С-Бітрікс найпростіше відправляти алерти через Telegram Bot API напряму з обробника помилок. В init.php реєструється кастомний обробник через set_exception_handler(), який при критичних помилках відправляє POST-запит на api.telegram.org/bot{TOKEN}/sendMessage. Не відправляйте кожну помилку — використовуйте throttling: не частіше одного повідомлення в 5 хвилин на один тип помилки. Інакше при масовому збої Telegram заблокує бота за спам.

Типові помилки при налаштуванні моніторингу

• 50% налаштувань перевіряють тільки головну — інші сторінки можуть бути недоступні, як в кейсі з кошиком.
• 40% проектів не налаштований cron — агенти не виконуються, сайт повільно оновлює кеш.
• Моніторинг зсередини — при падінні PHP він не спрацює.
• Занадто часті алерти (кожну хвилину) — через годину їх перестають помічати. Інтервал 3-5 хвилин оптимальний.
• Простий сайту в годину пік може коштувати десятки тисяч гривень — не економте на моніторингу.

Що входить в роботу

1. Аудит поточної інфраструктури та виявлення вузьких місць з аналізом логів.
2. Розробка healthcheck-ендпоінту з індивідуальним набором перевірок (до 20 метрик).
3. Налаштування зовнішнього моніторингу (UptimeRobot, Prometheus або аналог) з частотою опитування 1-5 хвилин.
4. Інтеграція сповіщень у Telegram, email, Slack з throttling.
5. Документація з експлуатації та навчання вашої команди (2 години).
6. Підтримка протягом місяця після запуску з коригуванням порогів.

Вартість розраховується індивідуально після аналізу ТЗ. Економія бюджету може досягати десятків тисяч гривень на місяць за рахунок автоматизації. Отримайте консультацію щодо вашого проекту — ми підберемо оптимальне рішення. Зв'яжіться з нами для аудиту моніторингу та отримайте звіт з рекомендаціями. Гарантуємо 99.9% uptime після налаштування. Сертифіковані спеціалісти з досвідом 7+ років.