Мониторинг доступности сервера 1С-Битрикс
Сайт может быть идеально написан, но если сервер недоступен — клиент видит ERR_CONNECTION_REFUSED. Мониторинг доступности сервера — это слой ниже, чем мониторинг сайта. Здесь проверяется не HTTP-ответ приложения, а работа самой машины: сеть, диск, память, процессы. Для Битрикс это особенно актуально: платформа требовательна к ресурсам, а типичный VPS на shared-хостинге работает на пределе.
Уровни мониторинга
Мониторинг сервера — не одна проверка, а несколько уровней, каждый ловит свой класс проблем.
Ping (ICMP). Самая базовая проверка: сервер отвечает на ping — значит, машина включена и сеть работает. Не отвечает — либо сервер упал, либо сеть недоступна, либо firewall блокирует ICMP (тогда ping бесполезен). Интервал — 30-60 секунд.
Порты. Проверяем TCP-соединение на ключевых портах:
| Порт | Сервис | Что значит недоступность |
|---|---|---|
| 80 | HTTP | Веб-сервер не запущен |
| 443 | HTTPS | Веб-сервер или SSL не работает |
| 3306 | MySQL | База данных недоступна |
| 5432 | PostgreSQL | База данных недоступна |
| 22 | SSH | Нет удалённого доступа |
Порт отвечает, но сервис внутри завис — TCP handshake проходит, а данных нет. Для HTTP это ловится через HTTP-мониторинг (TTFB > порога). Для MySQL — через специализированные проверки.
Системные метрики. CPU, RAM, диск, swap, load average. Собираются агентом на сервере (Zabbix agent, Telegraf, node_exporter для Prometheus). Критические пороги для типового Битрикс-сервера:
| Метрика | Предупреждение | Критично |
|---|---|---|
| CPU usage | > 80% (5 мин) | > 95% (5 мин) |
| RAM usage | > 85% | > 95% |
| Disk usage | > 80% | > 90% |
| Swap usage | > 50% | Любое использование swap |
| Load average | > кол-во ядер | > 2x ядер |
Swap на сервере Битрикс — тревожный сигнал. MySQL и PHP-FPM в swap работают на порядок медленнее. Если swap растёт — не хватает RAM, нужно оптимизировать или добавлять.
Процессы: что должно работать
Для типовой конфигурации Битрикс (Apache/Nginx + PHP-FPM + MySQL) мониторим наличие процессов:
-
nginx —
systemctl is-active nginx. Если упал — 502 Bad Gateway. -
php-fpm —
systemctl is-active php8.1-fpm. Если упал — 502 или 500. -
mysqld —
systemctl is-active mysql. Если упал — белый экран или ошибка соединения с БД. -
cron —
systemctl is-active cron. Если упал — агенты Битрикс не выполняются (при использованииcron_events).
Дополнительно для продакшн-конфигурации:
-
memcached или redis — если используются как кэш-бэкенд (
cache_typeв.settings.php). Падение кэш-сервера не роняет сайт, но резко увеличивает нагрузку на MySQL. - sphinx или elasticsearch — если используется внешний поисковый индекс.
Инструменты
Zabbix — полноценная система мониторинга. Zabbix agent устанавливается на сервер, собирает метрики, отправляет на Zabbix server. Готовые шаблоны для Linux, MySQL, Nginx, PHP-FPM. Настройка триггеров: {host:system.cpu.util.avg(5m)} > 80 — алерт при CPU > 80% за 5 минут.
Prometheus + Grafana — альтернативный стек. Node_exporter собирает метрики, Prometheus хранит, Grafana визуализирует. Alertmanager отправляет уведомления. Гибче Zabbix в части визуализации, но требует больше настройки.
Netdata — агент с веб-интерфейсом, устанавливается за минуту. Показывает метрики в реальном времени с детализацией до секунды. Нет встроенного хранения истории (нужна интеграция с Prometheus/Graphite). Подходит для быстрой диагностики.
Панель управления (ISPmanager, VestaCP). Если сервер управляется через панель — в ней обычно есть базовый мониторинг: графики CPU, RAM, диска. Алертов, как правило, нет.
Специфика Битрикс-серверов
Окружение Битрикс (BitrixVM). Если сервер развёрнут из образа BitrixVM — в нём предустановлен собственный набор скриптов мониторинга: /etc/cron.d/bx_*, проверка состояния через /opt/webdir/bin/bx-monitor. Эти скрипты проверяют MySQL, Nginx, PHP-FPM и отправляют результат в панель BitrixVM (https://server:8443). Базовый мониторинг, но без внешних уведомлений.
MySQL. Для Битрикс критичны: Threads_connected (текущие соединения), Slow_queries (медленные запросы), Innodb_buffer_pool_reads (промахи кэша InnoDB). Мониторим через Zabbix-шаблон MySQL или через mysqladmin extended-status.
Размер /upload/. Директория /upload/ на Битрикс-сайтах растёт неконтролируемо: изображения каталога, файлы обмена с 1С, временные файлы. Мониторим du -sh /home/bitrix/www/upload/ — если приближается к лимиту диска, нужна очистка через штатный инструмент Битрикс Настройки → Очистка файлов или ручная ревизия.
Бэкапы. Мониторинг не только сервера, но и его бэкапов. Проверяем дату последнего бэкапа (файл в директории /backup/ или запись в логе). Если бэкап старше 24 часов — предупреждение. Потеря данных без свежего бэкапа — катастрофа, которую мониторинг обязан предотвращать.
Каналы оповещения и эскалация
Для серверного мониторинга скорость реакции критичнее, чем для прикладного. Сервер недоступен — все сайты на нём лежат. Цепочка: Telegram (мгновенно) → SMS (через 5 минут без подтверждения) → звонок (через 15 минут). Для команд — интеграция с PagerDuty или OpsGenie с расписанием дежурств.