Мониторинг: какие метрики важно отслеживать в пиковые периоды

Пиковая нагрузка — это всегда проверка. Даже если система стабильно работает в обычные дни, во время распродажи ограничения могут проявиться быстро и болезненно.

Хорошая новость в том, что большинство проблем можно обнаружить заранее. Для этого нужны два инструмента: нагрузочное тестирование (чтобы понять пределы системы) и мониторинг (чтобы увидеть приближение этих пределов в реальном времени).

Какие метрики отслеживать в пик

Когда нагрузка пошла, важно понимать, что происходит с системой здесь и сейчас. Мы выделяем четыре группы метрик, которые дают полную картину.

Доступность и ошибки

Это базовые индикаторы здоровья системы. Если сайт недоступен или отдает ошибки 5xx, пользователь просто не может совершить покупку. Рост серверных ошибок — первый сигнал, что что-то пошло не так.

Состояние базы данных

База данных — самое узкое место в большинстве проектов на Битриксе. В пиковые периоды важно отслеживать:

• количество активных соединений;

• наличие блокировок таблиц;

• появление медленных запросов.

Для сбора этих метрик мы используем Prometheus + Grafana, но даже базовый мониторинг от хостинг-провайдера лучше, чем полное его отсутствие.

Ресурсы серверов

Загрузка CPU, использование оперативной памяти, состояние дисковой подсистемы — классическая триада, которая показывает, не уперлась ли система в «железо». Достижение предельных значений — сигнал к вертикальному или горизонтальному масштабированию.

PHP-воркеры

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

Как мониторинг помог вовремя заметить деградацию системы

Во время одной из крупных распродаж нагрузка на интернет-магазин начала расти быстрее прогнозов. В первые часы акции количество одновременных пользователей увеличилось почти вдвое.

На уровне пользовательского интерфейса сайт продолжал работать, но мониторинг показал тревожные сигналы:

• начало расти время ответа базы данных;

• увеличилось количество активных соединений к СУБД;

• в очереди начали накапливаться PHP-воркеры.

Эти показатели говорили о том, что система приближается к пределу по обработке запросов.

Команда заметила изменения на дашборде мониторинга и успела вмешаться до того, как проблему почувствовали пользователи. Были оперативно увеличены ресурсы веб-слоя и перераспределена часть нагрузки на дополнительные серверы.

В результате деградацию удалось остановить, и сайт продолжил стабильно работать даже при дальнейшем росте трафика.

Этот пример хорошо показывает, почему мониторинг критически важен в периоды пиковых нагрузок: метрики позволяют заметить проблему раньше, чем она станет заметна пользователям.

Что делать после распродажи

Пик прошел — это не повод выдохнуть и забыть до следующего раза. Самое ценное наступает после: у вас есть данные о том, как система вела себя под реальной нагрузкой.

Мы рекомендуем проводить формальный разбор в четыре шага:

1. Собрать хронологию. Что происходило с системой в течение пикового периода? Какие алерты срабатывали, какие метрики отклонялись от нормы?

2. Найти точку входа. Когда именно началась деградация? Часто это привязано к конкретному событию — запуску рекламы, выходу нового релиза или началу тяжелого фонового процесса.

3. Определить первопричину. Что стало спусковым крючком? Это может быть код, который не прошел нагрузочное тестирование, тяжелый запрос к базе или зависимость от внешнего сервиса.

4. Скорректировать архитектуру. На основе анализа вносятся изменения — от мелких правок конфигурации до пересмотра архитектуры отдельных узлов.

Коротко: главное из нашей практики

Если резюмировать опыт подготовки к пиковым нагрузкам, выводы выглядят так:

• База данных — первое, на что нужно смотреть. В 90% случаев именно она становится ограничителем.

• Мониторинг — это не опция, а необходимость. Без него вы слепы и узнаете о проблемах только от клиентов.

• Резервирование снижает риски. Мастер-реплика, запасной веб-сервер, второй провайдер — чем больше запасов, тем устойчивее система.

• Кэширование разгружает backend. CDN для статики, кэш страниц для каталога — это не роскошь, а базовая гигиена.

• Инфраструктура требует внимания всегда, а не только перед распродажами. Проблемы накапливаются постепенно, и пик лишь проявляет их.