Мониторинг CPU сервера 1С-Битрикс: настройка алертов

Представьте: интернет-магазин на Битрикс работает стабильно, но в обеденное время сайт начинает тормозить — страницы грузятся по 10–15 секунд, менеджеры жалуются, часть посетителей уходит. Вы запускаете htop: CPU загружен под 100%, но непонятно, что именно его жрёт. Проходит час — нагрузка спадает. На следующий день история повторяется. Без исторических данных причину не найти: её нужно ловить в момент пика. Мы сталкивались с такой ситуацией десятки раз. Правильно настроенный мониторинг фиксирует аномалии и связывает их с событиями — агенты, cron-задачи, деплои. Это позволяет устранять проблему навсегда, а не гасить пожары. Один час простоя интернет-магазина может стоить десятки тысяч рублей, поэтому настройка мониторинга быстро окупается.

В Битрикс-проектах основные потребители CPU — php-fpm, mysqld и агенты (b_agent). PHP-FPM выполняет код, который генерирует страницы и обрабатывает действия пользователей. MySQL отвечает за запросы к базе — неоптимизированные запросы могут надолго загружать ядро. Агенты выполняют фоновые задачи: обновление поискового индекса, выгрузку каталога, обработку заказов. Каждый агент добавляет микросекунды, но при большом количестве или неправильных интервалах они создают постоянную нагрузку. Важно не только смотреть на текущую загрузку, но и уметь анализировать тренды. Для этого мы используем Prometheus + Grafana, а для быстрых проверок — htop и mpstat.

Почему мониторинг CPU критичен для Битрикс-сервера?

Высокая загрузка CPU — это следствие, а не причина. Без мониторинга вы видите только симптом, но не знаете, какой процесс его вызвал. Например, если CPU занят MySQL — проблему нужно искать в базе: медленные запросы, отсутствие индексов, неоптимальные структуры. Если php-fpm — смотреть код и настройки приложения. Агенты Битрикс могут всплесками загружать процессор при каждом запуске. По данным официальной документации Битрикс, неправильно настроенные агенты вызывают до 30% лишней нагрузки на сервер. Мониторинг с алертами позволяет узнавать о таких событиях в реальном времени. Load average — это системная метрика, показывающая среднее количество процессов, ожидающих выполнения. В 70% случаев проблемный сервер имеет load average выше числа ядер.

Как отличить проблему PHP от MySQL?

Для быстрой диагностики используем команды:

htop -d 20 mpstat -P ALL 5 pidstat -p <PID> 5 

Если mysqld потребляет >50% CPU, смотрим slow-запросы:

SHOW FULL PROCESSLIST; SELECT * FROM information_schema.PROCESSLIST WHERE TIME > 5; 

Проблемы PHP часто скрыты в коде: php-fpm status покажет количество активных процессов. Если они постоянно на максимуме — нехватка воркеров. В 40% случаев проблема решается увеличением pm.max_children.

Какие инструменты мониторинга CPU наиболее эффективны для Битрикс?

Для оперативной диагностики лучше всего подходит htop — он показывает процессы и древовидную структуру. mpstat даёт разбивку по ядрам, удобен для обнаружения проблем с I/O wait. Для долгосрочного анализа и построения графиков используем Prometheus + Grafana: они хранят месяцы метрик и позволяют выявить тренды. atop сохраняет историю за последние дни и не требует настройки — полезно для ретроспективы. Мы перепробовали десятки инструментов и остановились на этой связке: она покрывает 95% случаев.

Пошаговая инструкция по настройке мониторинга CPU

Установка Prometheus + Grafana занимает от 2 до 4 часов, включая настройку алертов. Вот типовой план:

1. Аудит текущего состояния: проверьте uptime, cat /proc/loadavg, определите топ процессов ps aux --sort=-%cpu | head -10.
2. Установите node_exporter на сервер: скачайте и запустите с правами на чтение метрик CPU, памяти, диска.
3. Настройте Prometheus: в конфигурации prometheus.yml добавьте target для node_exporter (например, localhost:9100).
4. Импортируйте дашборд в Grafana: используйте готовый шаблон Node Exporter Full (ID 1860) или создайте свой с метриками CPU utilisation, load average, I/O wait.
5. Настройте Alertmanager: добавьте правило для высокой загрузки CPU, например при (node_load1 / count(count(node_cpu_seconds_total) by (cpu))) > 2 в течение 10 минут.
6. Протестируйте алерты: смоделируйте нагрузку с помощью stress --cpu 4 и проверьте срабатывание.

Типичные пороги нагрузки:

Чек-лист быстрой диагностики при высокой загрузке CPU

• Проверьте load average через uptime или cat /proc/loadavg.
• Для быстрой диагностики тормозов определите топ процессов по CPU: ps aux --sort=-%cpu | head -10.
• Если mysqld лидирует, включите slow query log и проанализируйте запросы.
• Если php-fpm — проверьте pm.status_path на наличие очереди.
• Посмотрите агенты: SELECT NAME, LAST_EXEC, NEXT_EXEC FROM b_agent WHERE ACTIVE='Y' ORDER BY LAST_EXEC LIMIT 10;
• Перенесите тяжелые агенты на cron с nice -n 19 и разбейте на пакеты.

Средняя экономия на серверных ресурсах после внедрения мониторинга составляет 20–40% — за счёт выявления неэффективных запросов и агентов. Например, перевод одного тяжёлого агента на правильный cron может снизить пиковую нагрузку вдвое. Один час простоя интернет-магазина может стоить десятки тысяч рублей, поэтому настройка мониторинга быстро окупается.

Что входит в работу по настройке мониторинга

Мы предлагаем услугу под ключ: от аудита до передачи документации. В рамках типового проекта:

• Аудит производительности сервера (CPU, память, диск, настройки PHP и MySQL).
• Установка и настройка Prometheus + node_exporter + Grafana.
• Создание дашборда с ключевыми метриками (CPU, load average, I/O wait, топ процессов).
• Настройка алертов в Telegram/Slack.
• Оптимизация php-fpm (max_children, pm.max_requests) и агентов (перенос на cron, интервалы).
• Передача документации с инструкциями и доступов.
• Поддержка в течение месяца после внедрения.

Сроки работ: от 2 до 5 дней в зависимости от сложности. Стоимость рассчитывается индивидуально — оценим ваш проект за один рабочий день. Свяжитесь с нами, чтобы обсудить детали.

Как мы это делаем: пример из практики

Недавно к нам обратился интернет-магазин с каталогом в 50 000 товаров. Каждую ночь агент обновлял поисковый индекс, загружая CPU на 100% в течение часа. Это вызывало сбои в фоновых задачах. Мы перенесли агент на cron с nice 19 и разбили на пакеты по 1000 товаров. Пиковая нагрузка снизилась с 100% до 30%, а время выполнения сократилось с 60 до 12 минут. Дополнительно настроили алерт при load average > 1.5 — теперь команда узнаёт о проблемах до того, как они повлияют на пользователей.

Этапы работы

Средняя экономия на аренде серверов после внедрения мониторинга составляет 20–40%, что для среднего проекта даёт десятки тысяч рублей ежемесячной экономии. Получите консультацию по настройке мониторинга вашего сервера — мы предложим оптимальное решение под вашу инфраструктуру. Закажите аудит, и мы выявим узкие места вашего сервера Битрикс. Наш опыт — более 10 лет и 500+ проектов по оптимизации и поддержке Битрикс.