Почему мониторинг сервера Битрикс — первый эшелон защиты
Сайт может быть идеально написан, но если сервер недоступен — клиент видит ERR_CONNECTION_REFUSED. За 10+ лет работы с Битрикс мы десятки раз сталкивались с ситуацией, когда VPS падал из-за утечки памяти в MySQL или переполнения диска /upload/. Мониторинг доступности сервера — это слой ниже, чем мониторинг сайта. Здесь проверяется не HTTP-ответ приложения, а работа самой машины: сеть, диск, память, процессы. Для Битрикс это особенно актуально: платформа требовательна к ресурсам, а типичный VPS на shared-хостинге работает на пределе. В одном проекте утечка памяти MySQL потребляла 12 ГБ из 16 ГБ RAM, swap вырос до 2 ГБ, и TTFB взлетел до 7 секунд. Система мониторинга сработала за 2 минуты — простой предотвращён.
Какие метрики мониторить в первую очередь?
Мониторинг сервера — не одна проверка, а несколько уровней, каждый ловит свой класс проблем.
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 — через специализированные проверки, например SELECT 1.
Системные метрики. 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, нужно оптимизировать или добавлять.
Почему мониторинг swap критичен для Битрикс?
MySQL и PHP-FPM при нехватке RAM уходят в swap, что вызывает падение производительности в 10-30 раз. Для типового каталога на 50 тысяч товаров это означает TTFB > 5 секунд. Алерт на любое использование swap позволяет обнаружить проблему до того, как начнутся жалобы пользователей. В нашей практике это предотвращало простои стоимостью до 50 000 рублей в час.
Как настроить алерты для Битрикс?
Для серверного мониторинга скорость реакции критичнее, чем для прикладного. Сервер недоступен — все сайты на нём лежат. Цепочка оповещения: Telegram (мгновенно) → SMS (через 5 минут без подтверждения) → звонок (через 15 минут). Для команд — интеграция с PagerDuty или OpsGenie с расписанием дежурств. Это сокращает среднее время обнаружения инцидента с 30 минут до 1 минуты.
Процессы: что должно работать. Для типовой конфигурации Битрикс (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 минут. Для одиночного сервера Zabbix настраивается в два раза быстрее Prometheus.
Prometheus + Grafana — альтернативный стек. Node_exporter собирает метрики, Prometheus хранит, Grafana визуализирует. Alertmanager отправляет уведомления. Гибче Zabbix в части визуализации, но требует больше времени на настройку. Для кластеризованной инфраструктуры — однозначно Prometheus.
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). Базовый мониторинг, но без внешних уведомлений. Как отмечается в документации BitrixVM, мониторинг на уровне ОС — первый эшелон защиты.
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 часов — предупреждение. Потеря данных без свежего бэкапа — катастрофа, которую мониторинг обязан предотвращать.
Что входит в настройку мониторинга под ключ
Мы предоставляем полный цикл работ:
- Аудит текущей конфигурации сервера и выявление узких мест.
- Разработка схемы мониторинга: метрики, триггеры, каналы оповещения.
- Установка и настройка агентов (Zabbix/Prometheus) и интеграция с Telegram/PagerDuty.
- Создание дашбордов в Grafana (опционально).
- Документация с инструкциями для вашей команды.
- Обучение сотрудников работе с системой.
- Гарантия работоспособности 30 дней после внедрения.
Мы занимаемся администрированием Битрикс более 10 лет, выполнили свыше 50 проектов. Наши инженеры сертифицированы и имеют опыт с высоконагруженными системами. Свяжитесь с нами для оценки вашего проекта — мы гарантируем, что ваша инфраструктура будет под контролем 24/7. Получите консультацию, мы рассчитаем стоимость и сроки индивидуально.
Как проходит настройка за 5 шагов
- Аудит текущей конфигурации — проверяем инфраструктуру: версии ПО, нагрузку, узкие места. Фиксируем текущие пороги.
- Разработка схемы мониторинга — определяем метрики, триггеры, каналы оповещения под вашу архитектуру.
- Установка и настройка агентов — Zabbix agent / Prometheus node_exporter, конфигурация сбора метрик.
- Создание дашбордов и алертов — в Grafana (опционально) или Zabbix, интеграция с Telegram/SMS/PagerDuty.
- Тестирование и документация — проверяем срабатывание алертов, пишем инструкцию для вашей команды.
Закажите настройку мониторинга сервера 1С-Битрикс — мы превратим хаос метрик в понятную картину.