Настройка оповещений о сбоях и мониторинг 1С-Битрикс

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

Что именно мониторить

Минимальный набор точек контроля:

• 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 МБ.

Штатные средства Битрикс

Согласно официальной документации, модуль 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.

Как реализовать endpoint для healthcheck?

Создайте файл /healthcheck.php в корне сайта, который проверяет ключевые подсистемы:

• Подключение к БД через $DB->Query("SELECT 1")
• Доступность memcached/redis через CBitrixCache
• Запись во временную директорию (проверка, что диск не полон)
• Наличие лицензионного ключа (проверка CModule::IncludeModule('main'))

Если все проверки пройдены — отдавайте HTTP 200 с телом OK. Любой сбой — HTTP 503 с описанием ошибки. Внешний мониторинг дёргает этот endpoint раз в минуту и реагирует на не-200 статус. Время выполнения проверки не должно превышать 200 мс, иначе мониторинг может считать endpoint недоступным.

<?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. Поддержка в течение месяца после запуска с корректировкой порогов.

Стоимость рассчитывается индивидуально после анализа ТЗ. Экономия бюджета может достигать десятков тысяч рублей в месяц за счёт автоматизации. Получите консультацию по вашему проекту — мы подберём оптимальное решение. Свяжитесь с нами для аудита мониторинга и получите отчёт с рекомендациями.