Моніторинг доступності сервера 1С-Бітрікс: налаштування під ключ

Чому моніторинг сервера Бітрікс — перший ешелон захисту

Сайт може бути ідеально написаний, але якщо сервер недоступний — клієнт бачить 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-з'єднання на ключових портах:

Порт відповідає, але сервіс завис — TCP handshake проходить, а даних немає. Для HTTP це ловиться через HTTP-моніторинг (TTFB > поріг). Для MySQL — через спеціалізовані перевірки, наприклад SELECT 1.

Системні метрики. CPU, RAM, диск, swap, load average. Збираються агентом на сервері (Zabbix agent, Telegraf, node_exporter для Prometheus). Критичні пороги для типового Бітрікс-сервера:

Swap на сервері Бітрікс — тривожний сигнал. MySQL і PHP-FPM у swap працюють на порядок повільніше. Якщо swap зростає — не вистачає RAM, потрібно оптимізувати або додавати.

Чому моніторинг swap критичний для Бітрікс?

MySQL та PHP-FPM при нестачі RAM йдуть у swap, що викликає падіння продуктивності в 10-30 разів. Для типового каталогу на 50 тисяч товарів це означає TTFB > 5 секунд. Алерт на будь-яке використання swap дозволяє виявити проблему до того, як почнуться скарги користувачів. У нашій практиці це запобігало простоям вартістю до $450–650ів на годину.

Як налаштувати алерти для Бітрікс?

Для серверного моніторингу швидкість реакції критичніша, ніж для прикладного. Сервер недоступний — всі сайти на ньому лежать. Ланцюжок оповіщення: 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 кроків

1. Аудит поточної конфігурації — перевіряємо інфраструктуру: версії ПЗ, навантаження, вузькі місця. Фіксуємо поточні пороги.
2. Розробка схеми моніторингу — визначаємо метрики, тригери, канали оповіщення під вашу архітектуру.
3. Встановлення та налаштування агентів — Zabbix agent / Prometheus node_exporter, конфігурація збору метрик.
4. Створення дашбордів та алертів — у Grafana (опціонально) або Zabbix, інтеграція з Telegram/SMS/PagerDuty.
5. Тестування та документація — перевіряємо спрацювання алертів, пишемо інструкцію для вашої команди.

Замовте налаштування моніторингу сервера 1С-Бітрікс — ми перетворимо хаос метрик на зрозумілу картину.