B3x.by Связаться
15 мая 2026 г. · мониторинг · Bitrix · инфраструктура

Свой мониторинг для Bitrix: зачем мы написали собственный, а не взяли Zabbix

Когда поддерживаешь десятки Bitrix-проектов, готовые мониторинг-системы либо не умеют то что нужно, либо умеют — но за деньги, ради 5% специфики. Рассказываем, почему написали свой инструмент и что в нём такого, чего нет в коробочных решениях.

Контекст

Когда команда поддерживает один проект — мониторинг это вопрос вкуса: Zabbix, Prometheus, Grafana, UptimeRobot, Pingdom — что-то взял, настроил, забыл. Когда проектов становится 40+, и у каждого свой стек, свои тяги нагрузки и свои особенности, мониторинг становится отдельным продуктом.

В какой-то момент мы посчитали, во что обходится содержание зоопарка Zabbix-агентов на клиентских машинах: каждый раз отдельная настройка, отдельный шаблон, отдельные алерты, и при этом 80% метрик — общие для всех Bitrix-проектов, а 20% — это то, что Zabbix не умеет без плагинов или костылей.

Поэтому мы сели и написали свой инструмент. Ниже — что в нём есть такого, чего нет в коробочных решениях, и зачем это нужно именно для Bitrix-стэка.

Что внутри

Это Go-демон + PostgreSQL + Telegram-бот. Деплоится одним бинарником на отдельный VPS, не на клиентскую машину. К клиентам ходит сам по SSH с ключами, которые хранятся зашифрованными в его базе (AES-256-GCM, ключ шифрования живёт в systemd-окружении, не на диске).

Что собирает:

  • Системные метрики каждую минуту через SSH: CPU, load average, RAM (с разбивкой на user/buff/cache), swap, swap-in/swap-out rate, disk per-mountpoint, PSI memory pressure.
  • MySQL-специфика: uptime (ловим внезапные рестарты — типичный симптом OOM-killer), активные подключения, slow queries, версия.
  • Bitrix-специфика: размер bitrix/cache и bitrix/managed_cache (детектим распухающий кэш до того как он начнёт ронять диск), версия PHP, версия BitrixVM.
  • HTTP-проверки: каждые 60 секунд, с фиксированным таймаутом, статус-код и время отклика. Не из одной точки — мы видим только наш канал, поэтому имеем привычку использовать check-host.net для подтверждения «глобально упало» против «у нас локально».
  • WireGuard VPN-туннели для клиентов с приватной сетью: статус интерфейса, возраст последнего handshake.
  • SSL-сертификаты и WHOIS-домены — адаптивно по сроку: за месяц до истечения проверяем раз в день, за неделю — каждый час.

Что в нём такого, чего нет в Zabbix

1. Bitrix-aware из коробки

Zabbix или Prometheus можно научить чему угодно, но это работа. У нас встроенные знания:

  • bitrix_cache_size — отдельная метрика, потому что распухающий cache — это специфика Bitrix, а не «диска кончается».
  • Парсинг vmbitrix_version и bitrix_va_version — потому что мы знаем, что у BitrixVM есть свой версионинг.
  • mysql_uptime как сигнал «MySQL внезапно рестартанул» — потому что в Bitrix-мире это очень часто означает OOM-killer, и мы хотим узнавать об этом из мониторинга, а не от клиента утром.

2. Аномалии и тренды, а не только пороги

Классический мониторинг отвечает на «больше Х процентов?» — это срабатывает либо рано (флапы), либо поздно (когда уже всё). Мы считаем:

  • Тренд за 7 дней: «диск растёт на 1.5% в сутки, через 8 дней кончится».
  • Аномалия baseline-vs-current: «обычно в это время суток RAM 60%, сейчас 85% — что-то не как обычно».

Это позволяет писать заранее «у вас вырастет проблема через неделю», а не «у вас уже сейчас всё лежит».

3. Авто-разведка при эскалации

Когда метрика держится в critical дольше, чем заданный порог (по умолчанию 5 минут), система сама заходит на сервер по SSH и собирает диагностику в зависимости от типа алерта:

  • Память — top-10 по RSS, последние OOM в dmesg, free -h, swap_in/out из /proc/vmstat.
  • CPU — top-10 по CPU, uptime, vmstat 1 3.
  • HTTP — последние 30 строк nginx error.log и httpd error_log, листинг портов, топ воркеров.
  • MySQL — processlist, активные транзакции InnoDB, состояние innodb_buffer_pool.

Результат прицепляется к Telegram-уведомлению до того, как инженер открыл чат. Когда он смотрит — у него уже есть первичный диагноз. Это вырезает 5–10 минут «зайти, посмотреть, понять» из каждого инцидента.

4. Квартирная экономика

Лицензия Zabbix Enterprise или Grafana Cloud для 40+ проектов — это десятки тысяч долларов в год. Свой инструмент работает на одной VPS за $20/мес, обслуживается одним инженером, и стоимость не растёт линейно с числом клиентов.

Что мы НЕ делаем (и почему)

  • Не пушим агентов на клиентские машины. Принцип pull: мы ходим к ним. Один процесс, одно место развёртывания, никаких автоматических обновлений по 40 серверам.
  • Не пишем красивые графики 1-в-1 как Grafana. Используем SVG-спарклайны прямо в HTML-дашборде — этого достаточно чтобы увидеть тренд, а тяжёлая аналитика делается отдельно по запросу.
  • Не дублируем общие SaaS-pingdom-like проверки. Параллельно проверяем через check-host.net (20 точек по миру), чтобы отличать «у нас локально проблема в сети» от «у клиента реально упал сайт».

Что это значит для клиента

Когда вы подключены к нашей поддержке, мониторинг — это не «мы поставили вам Zabbix и забыли». Это наш собственный инструмент, мы его пишем, поддерживаем и улучшаем под собственные сценарии работы:

  • За последние пару месяцев в него добавились авто-разведка при эскалации, аномалии и тренды по RAM/disk, мониторинг WireGuard-туннелей и расширенные MySQL-метрики — потому что нам это нужно было для конкретных инцидентов на клиентских проектах. Каждое наблюдение в работе становится новой возможностью в инструменте.

Если интересно — заглядывайте на сам дашборд мониторинга (доступ только под учётной записью клиента). Или запишитесь на бесплатный аудит — мы прогоним по вашему серверу те же 30 проверок, что делает наш мониторинг ежеминутно, и пришлём отчёт «что чинить в первую очередь».