Недавно к нам обратился клиент с каталогом на 150 000 товаров. Страницы грузились за 8 секунд, но нагрузочное тестирование ничего не показывало — проблема проявлялась только под реальным трафиком. Оказалось, медленные SQL-запросы накапливались за неделю, и система деградировала постепенно. Мониторинг вовремя показал тренд, и мы оптимизировали запросы за один день. Без постоянного сбора метрик вы узнаете о проблеме от пользователя, а не от системы.
По данным Bitrix Benchmark, 60% проектов имеют неоптимальные SQL-запросы, которые остаются незамеченными до аварийного отказа.
Почему постоянный мониторинг эффективнее разовых замеров?
Разовый тест нагрузки — это фото, а мониторинг — видео высокой чёткости. Разовый замер фиксирует состояние в момент теста, но не показывает тренды. Постоянный мониторинг позволяет увидеть: рост времени SQL-запросов на 200% за месяц, увеличение потребления памяти Redis на 2 ГБ в неделю, или приближение PHP-FPM к saturation. Только с историей можно отличить случайный всплеск от системной деградации. Например, на одном из проектов мы заметили рост ошибок 5xx на 15% за неделю — оказалось, обновление модуля вызывало утечку памяти в Redis. Мониторинг зафиксировал это за 2 дня до первых жалоб.
Проблемы, которые решаем
- Скрытая деградация: рост времени ответа на 300% за две недели из-за неоптимальных запросов. Без мониторинга — только жалобы клиентов.
- PHP-FPM overflow: active processes > 85% max_children — сайт начинает тормозить, а вы не знаете, пора ли расширять пул.
- Redis memory leak: потребление памяти растёт на 2 ГБ в неделю после обновления модуля. Мониторинг фиксирует утечку до того, как Redis начнёт вытеснять ключи.
- MySQL slow queries: 10+ медленных запросов в минуту — индексы и структура запросов требуют ревью.
Как мы настраиваем мониторинг: стек и конфиги
Развёртываем Prometheus с экспортёрами на целевых серверах. Для типового проекта используем:
-
node_exporter— системные метрики (CPU, RAM, диск, сеть) -
mysqld_exporter— метрики MySQL/MariaDB (медленные запросы, InnoDB, connection pool) -
php-fpm_exporter— метрики PHP-FPM из/fpm-status -
redis_exporter— метрики Redis (память, hit rate, connected clients)
Для получения статуса PHP-FPM добавляем в конфиг пула:
pm.status_path = /fpm-status В nginx:
location /fpm-status { allow 127.0.0.1; deny all; fastcgi_pass unix:/run/php/php8.1-fpm.sock; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } Endpoint /fpm-status показывает active/idle/ waiting processes. Если active processes близко к max_children — PHP saturated, нужно увеличивать пул или оптимизировать код.
Далее собираем данные в Grafana: строим дашборды с ключевыми метриками для Битрикс. Пример алерта: если php_fpm_active_processes превышает 85% от max более 5 минут — Telegram-уведомление. Если MySQL slow queries > 10/мин — Email. Если время ответа сайта > 3 секунд — Telegram + звонок.
Какие метрики критичны для Битрикс?
На дашборде Grafana выводим:
-
php_fpm_active_processes / php_fpm_max_active_processes— загрузка PHP-FPM -
mysql_global_status_slow_queries— количество медленных запросов -
redis_memory_used_bytes— использование памяти Redis -
node_load1/node_load5— системная нагрузка - Процент ошибок 5xx — индикатор проблем на уровне приложения
Подробнее о Prometheus и Grafana.
Сравнение инструментов мониторинга
| Инструмент | Тип | Хранение истории | Гибкость алертов | Время развёртывания |
|---|---|---|---|---|
| Встроенный Монитор Битрикс | Внутренний | Нет (только текущий лог) | Базовая (порог времени) | 30 минут |
| Prometheus + Grafana | Внешний | Да (до 30 дней и более) | Полная (условия, каналы) | 3–4 часа |
| UptimeRobot | Доступность | Нет | Уведомления HTTP | 10 минут |
Основные метрики и пороги алертов
| Метрика | Тип | Порог для алерта | Приоритет |
|---|---|---|---|
| Загрузка PHP-FPM (active/max) | Процент | > 85% более 5 мин | Высокий |
| Медленные SQL-запросы | Количество/мин | > 10 | Средний |
| Память Redis | Мбайт | > 80% от maxmemory | Высокий |
| Системная нагрузка (load1) | Число | > 2 * (количество ядер CPU) | Средний |
| Ошибки 5xx | Процент | > 1% за 5 мин | Критический |
Пример дашборда Grafana для Битрикс
Графики: загрузка PHP-FPM (линия), медленные запросы (гистограмма), ошибки 5xx (счётчик). Все метрики агрегируются по часам и дням, что позволяет увидеть тренды. Алерты настроены на Telegram и Email.Процесс работы
- Аналитика: изучаем текущую архитектуру, нагрузку (число запросов, пики), узкие места (что вы уже знаете).
- Проектирование: выбираем экспортёры, разрабатываем схему алертов, определяем пороги.
- Реализация: развёртываем Prometheus, Grafana, настраиваем сбор метрик с экспортёров.
- Тест: проверяем корректность данных, симулируем аварии, настраиваем дашборды.
- Деплой: переносим в продуктив, документируем, проводим обучение команды (1 час вебинара по дашбордам и реакциям на алерты).
Что входит в работу
- Развёртывание стека Prometheus + Grafana на ваших серверах или в облаке.
- Настройка экспортёров (node, mysql, php-fpm, redis, при необходимости nginx).
- Разработка дашбордов с ключевыми метриками для Битрикс.
- Настройка алертов с уведомлениями в Telegram и Email.
- Документация по использованию дашбордов и реагированию на алерты.
- Обучение команды (до 2 часов онлайн).
- Пост-релизная поддержка в течение 2 недель (корректировка порогов, обновление экспортёров).
Сроки — от 3 до 5 рабочих дней для полного внедрения. Стоимость рассчитывается индивидуально после оценки сложности инфраструктуры.
Закажите бесплатную оценку вашего проекта — мы проанализируем текущую архитектуру и покажем, какую выгоду принесёт система мониторинга. Свяжитесь с нами, чтобы настроить мониторинг, который выявит проблемы до того, как их заметят пользователи.