Представьте: интернет-магазин на Битрикс работает стабильно, но в обеденное время сайт начинает тормозить — страницы грузятся по 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 часов, включая настройку алертов. Вот типовой план:
- Аудит текущего состояния: проверьте
uptime,cat /proc/loadavg, определите топ процессовps aux --sort=-%cpu | head -10. - Установите node_exporter на сервер: скачайте и запустите с правами на чтение метрик CPU, памяти, диска.
- Настройте Prometheus: в конфигурации
prometheus.ymlдобавьте target для node_exporter (например,localhost:9100). - Импортируйте дашборд в Grafana: используйте готовый шаблон Node Exporter Full (ID 1860) или создайте свой с метриками CPU utilisation, load average, I/O wait.
- Настройте Alertmanager: добавьте правило для высокой загрузки CPU, например при
(node_load1 / count(count(node_cpu_seconds_total) by (cpu))) > 2в течение 10 минут. - Протестируйте алерты: смоделируйте нагрузку с помощью
stress --cpu 4и проверьте срабатывание.
Типичные пороги нагрузки:
| Метрика | Критический уровень | Действие |
|---|---|---|
| Load average / число ядер | > 2.0 | Проверить процессы, алерт |
| I/O wait | > 10% | Смотреть disk usage, slow queries |
| CPU utilization mysqld | > 80% | Оптимизировать запросы |
| CPU utilization php-fpm | > 70% | Увеличить max_children или оптимизировать код |
Пример быстрой диагностики
В одном проекте load average держался на уровне 3.5 при 2 ядрах. После анализа выяснилось, что агент обновления поискового индекса запускался каждые 5 минут. Перенос на cron с nice снизил load до 1.2.Чек-лист быстрой диагностики при высокой загрузке 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 — теперь команда узнаёт о проблемах до того, как они повлияют на пользователей.
Этапы работы
| Этап | Длительность | Результат |
|---|---|---|
| Экспресс-аудит | 1 день | Отчёт по текущим метрикам CPU, узким местам |
| Проектирование | 1 день | План оптимизации, выбор инструментов |
| Настройка мониторинга | 1-2 дня | Prometheus + Grafana, алерты |
| Оптимизация | 1-2 дня | php-fpm, агенты, MySQL (по необходимости) |
| Передача и обучение | 1 день | Документация, дашборды, доступы |
Средняя экономия на аренде серверов после внедрения мониторинга составляет 20–40%, что для среднего проекта даёт десятки тысяч рублей ежемесячной экономии. Получите консультацию по настройке мониторинга вашего сервера — мы предложим оптимальное решение под вашу инфраструктуру. Закажите аудит, и мы выявим узкие места вашего сервера Битрикс. Наш опыт — более 10 лет и 500+ проектов по оптимизации и поддержке Битрикс.