Моніторинг доступності сервера 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% | Будь-яке використання |
| 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 з розписанням дежурства.