Мониторинг под нагрузкой

Мониторинг под нагрузкой — это возможность увидеть проблему до того, как о ней сообщат клиенты. Для highload-проекта на Битрикс важно наблюдать все слои: железо, БД, PHP, кэш и бизнес-метрики. Разберём, что и как измерять, чтобы держать проект под контролем.

Зачем нужен мониторинг под нагрузкой

Профилирование отвечает на вопрос «почему медленно» на конкретном хите, а мониторинг — «что происходит с проектом прямо сейчас и как менялось со временем». Это разные задачи. Мониторинг даёт:

• раннее обнаружение деградации до жалоб пользователей;
• историю метрик для анализа трендов и планирования ёмкости;
• контекст инцидента — что именно всплеснуло в момент падения;
• подтверждение эффекта оптимизаций на реальном трафике.

Слои метрик: от железа до бизнеса

Наблюдаемость highload-проекта строится по слоям, и каждый важен:

Самая опасная слепая зона — PHP-FPM: когда все воркеры заняты (max_children reached), запросы встают в очередь, и сайт «висит» при формально свободных CPU и БД.

Золотые сигналы и что алертить

Метрик много, но захлебнуться в них легко. Ориентир — четыре золотых сигнала (методология SRE):

1. Latency — время ответа, отдельно для успешных и ошибочных запросов;
2. Traffic — RPS, число заказов;
3. Errors — доля 5xx и ошибок приложения;
4. Saturation — насыщенность ресурсов (воркеры, коннекты, память).

Алертить нужно на симптомы, а не на всё подряд: рост доли 5xx, деградация времени ответа по перцентилю (p95/p99), приближение воркеров PHP-FPM к лимиту, нехватка коннектов MySQL.

Инструменты мониторинга

Типовой стек наблюдаемости для Битрикс складывается из нескольких инструментов:

• Zabbix — классика для метрик сервера и БД, гибкие триггеры и алерты;
• Prometheus + Grafana — метрики через экспортёры (node_exporter, mysqld_exporter, redis_exporter) и наглядные дашборды;
• APM (Pinba, New Relic, Elastic APM) — метрики уровня приложения: время генерации, разбивка по компонентам;
• ELK / Loki — централизованный сбор и поиск по логам.

Для Битрикс особенно полезна Pinba — она собирает статистику производительности прямо из PHP по UDP с минимальным оверхедом и показывает разбивку по скриптам и таймерам. В кластере обязателен централизованный сбор логов: без него разбирать инцидент по десятку нод невозможно.

Штатные средства Битрикс

Помимо внешнего стека, у Битрикс есть свои средства наблюдения:

• Монитор производительности (perfmon) — трассировка хитов, статистика по запросам;
• Проверка системы — Настройки → Инструменты → Проверка системы для контроля конфигурации;
• Панель веб-кластера — статус нод, реплик БД, состояние memcached в модуле cluster;
• Журнал событий (b_event_log) — ошибки ядра и модулей.

Штатные средства хороши для точечной диагностики, но не заменяют внешний мониторинг с историей и алертами. Их роль — детализация внутри приложения, когда внешний график уже показал проблему.

Дашборды и реакция на инциденты

Метрики бесполезны без организации. Соберите дашборды под роли:

К мониторингу привяжите регламент реакции: кто получает алерт, за какое время реагирует, куда эскалирует. Мониторинг без процесса реагирования — просто красивые графики. Для проектов с SLA это часть договора: время обнаружения и время восстановления фиксируются и контролируются.

Итог

Мониторинг highload-проекта на Битрикс — это наблюдаемость по всем слоям от железа до бизнес-метрик, ориентир на четыре золотых сигнала, алерты на симптомы по перцентилям и централизованный сбор логов в кластере. Штатный perfmon детализирует проблему внутри приложения, а внешний стек Zabbix/Grafana/APM хранит историю и предупреждает заранее.

Мы в B2Bsite выстраиваем мониторинг и сопровождение highload-проектов: настраиваем метрики и дашборды, разумные алерты и регламент реакции в рамках SLA. Если нужно видеть состояние проекта в реальном времени и реагировать до жалоб клиентов — поможем построить наблюдаемость и держать её в работе.