Налаштування оповіщень про збої 1С-Бітрікс
Сайт на Бітріксі падає, а ви дізнаєтеся про це від клієнта, який не зміг оформити замовлення. Типічна ситуація: помилка 500 висить три години, поки менеджер випадково не зайде на сайт. Штатний моніторинг Бітрікса через модуль monitoring доступний тільки в редакціях «Бізнес» та вище, та навіть він не покриває всі сценарії. Розберемо, як вистроїти систему оповіщень, яка реагує на збої за секунди, а не години.
Що саме моніторити
Мінімальний набір точок контролю:
-
HTTP-статус головної та критичних сторінок — каталог, кошик, оформлення замовлення. Якщо
/catalog/віддає 200, а/personal/order/make/— 500, загальна healthcheck по головній нічого не покаже. -
Роботоздатність cron — агенти Бітрікса (
/bitrix/modules/main/tools/cron_events.php) повинні виконуватися регулярно. Перевіряється по даті останнього успішного запуску в таблиціb_agent. - Доступність MySQL/MariaDB — перевіряйте не просто конект, а виконання тестового SELECT. Бітрікс при втраті з'єднання з БД показує білий екран без логування.
-
Вільне місце на диску — при заповненні
/tmpабо розділу зupload/сайт починає сипати помилками записи сесій та кеша. -
Розмір error.log — різкий ріст файлу
/var/log/php-fpm/error.logабо/bitrix/modules/main/tools/log.txtсигналізує про проблему раніше, ніж вона стане видна користувачам.
Штатні засоби Бітрікса
Модуль monitoring (якщо доступний) налаштовується в Налаштування → Моніторинг. Вміє перевіряти доступність сайту по HTTP, відстежувати агентів та надсилати email-уведомлення. Обмеження: працює тільки при живому PHP, не перевіряє зовнішні залежності, не інтегрується з месенджерами без доробки.
Більш корисний Журнал подій (b_event_log). Через API CEventLog::Add() можна логувати кастомні події, а через фільтри в адмінці — налаштувати уведомлення на певні severity.
Зовнішній моніторинг — основний канал
Надійна схема будується на зовнішньому сервісі, який опитує сайт звідси. Робочі варіанти:
| Інструмент | Що перевіряє | Канали оповіщення |
|---|---|---|
| UptimeRobot (безплатно) | HTTP-статус, keyword check | Email, Telegram, Slack, webhook |
| Healthchecks.io | Cron-задачі (dead man's switch) | Email, Telegram, PagerDuty |
| Zabbix / Prometheus + Alertmanager | Все: HTTP, диск, CPU, логи | Будь-які через інтеграції |
Для малих проектів хватає UptimeRobot з перевіркою кожні 5 хвилин + Healthchecks.io для cron. Для середніх та крупних — Prometheus з blackbox_exporter для HTTP-проб та node_exporter для серверних метрик.
Реалізація endpoint для healthcheck
Створіть файл /healthcheck.php в корені сайту, який перевіряє ключові підсистеми:
- Підключення до БД через
$DB->Query("SELECT 1") - Доступність memcached/redis через
CBitrixCache - Запис у тимчасову директорію
- Наявність ліцензійного ключа (перевірка
CModule::IncludeModule('main'))
Якщо всі перевірки пройдені — віддавайте HTTP 200 з тілом OK. Будь-який збій — HTTP 503. Зовнішній моніторинг дергає цей endpoint та реагує на не-200 статус.
Оповіщення у Telegram
Для Bitrix24 є штатна інтеграція з вебхуками. Для сайтів на 1С-Бітріксі простіше всього надсилати алерти через Telegram Bot API прямо з обробника помилок. В init.php реєструється кастомний обробник через set_exception_handler(), який при критичних помилках надсилає POST-запит на api.telegram.org/bot{TOKEN}/sendMessage.
Не надсилайте кожну помилку — використовуйте throttling: не частіше одного повідомлення в 5 хвилин на один тип помилки. Інакше при масовому збої Telegram заблокує бота за спам.