Что смотреть в момент пика: пять графиков вместо тридцати

MAATRIX

Нагрузка растёт, в чате уже пишут «сайт тормозит», а вы открываете Grafana — и там тридцать панелей, расставленных по шести дашбордам, каждая со своей легендой и своим масштабом по оси Y. В спокойном состоянии этот набор — ваш друг: он показывает картину целиком. В момент пика он превращается в противника, потому что глаза бегают между графиками быстрее, чем мозг успевает сложить из них решение. Правильный ответ на «что смотреть, когда всё горит» — не «больше графиков», а ровно пять: с них начинается диагностика, и только если они не дали ответа, есть смысл лезть глубже.

Почему тридцать метрик хуже, чем пять

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

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

У экрана с тридцатью панелями есть ещё одна проблема, которая не связана с вниманием напрямую — время загрузки и рендеринга. Дашборд с полусотней запросов к Prometheus или к базе метрик под нагрузкой сам может тормозить: пока сервер и так под давлением пиковой нагрузки, тяжёлый дашборд с длинными временными окнами и высококардинальными разбивками по лейблам добавляет нагрузку на систему мониторинга в самый неподходящий момент. Экран из пяти графиков с коротким окном (последние 15-30 минут) считается быстрее и надёжнее работает именно тогда, когда вам это нужнее всего.

Важная оговорка: пять графиков — не значит «выбросить остальные двадцать пять». Они остаются доступны на других вкладках или дашбордах для второго уровня диагностики — когда первый экран показал, что что-то не так, но не сказал, что именно. Пять графиков — это то, что должно быть открыто на экране заранее, до того, как начался пик, а не результат многочасовой ревизии всей системы мониторинга.

Какие пять графиков выбрать и почему именно эти

Список ниже — не догма, а отправная точка, которую стоит адаптировать под архитектуру конкретного проекта. Но принцип отбора один: каждый график должен отвечать на отдельный вопрос из цепочки «жив ли сервис → успевает ли отвечать → куда упирается», а не дублировать соседний под другим углом.

1. Загрузка CPU по каждому узлу (не агрегированно). Первый вопрос в любом инциденте — не перегружен ли процессор. Важно смотреть не среднее по кластеру, а по каждой ноде отдельно: агрегированные 60% могут скрывать один инстанс на 100% и три простаивающих, если балансировщик неровно распределяет нагрузку.

# Быстрый снимок на самом сервере
top -bn1 | head -20
mpstat -P ALL 1 1

2. Время ответа — перцентили, а не среднее. Среднее время ответа лжёт при пике: если 95% запросов отвечают за 50 мс, а 5% — за 8 секунд, среднее покажет спокойные 400 мс и ничего не расскажет о том, что часть пользователей уже видит белый экран. Нужны p95 и p99 — именно они первыми уходят вверх, когда система начинает захлёбываться, за минуты до того, как это станет видно по среднему. В Prometheus это типично строится через histogram_quantile:

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

3. Доля ошибок 5xx в реальном времени. Это самый прямой сигнал «пользователю сейчас плохо» — недвусмысленный, в отличие от загрузки CPU, которая может быть высокой и в норме. Смотреть стоит именно долю (процент от общего числа запросов), а не абсолютное число: на пике абсолютное число ошибок растёт вместе с абсолютным числом запросов, и без соотнесения с общим трафиком легко испугаться цифры, которая на самом деле в пределах нормы.

sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

4. Длина очереди — соединений к базе или задач в очереди воркеров. Это график, который обычно первым показывает узкое место конкретно вашей архитектуры. У кого-то это число активных подключений к PostgreSQL против max_connections, у кого-то — глубина очереди Sidekiq или Celery, у кого-то — backlog на балансировщике. Именно очередь растёт раньше, чем появляются 5xx: пока запросы просто ждут своей очереди, ошибок ещё нет, но время ответа уже ползёт вверх, — поэтому график очереди даёт на минуту-две больше форы, чем график ошибок.

-- Активные подключения к PostgreSQL против лимита
SELECT count(*), (SELECT setting FROM pg_settings WHERE name = 'max_connections')
FROM pg_stat_activity;

5. Свободное место на диске. На первый взгляд эта метрика кажется чужой среди четырёх «скоростных» показателей — она меняется медленно в обычном режиме. Но именно на пике она может измениться быстро: логи, временные файлы сессий, файлы очередей и кэши растут пропорционально трафику, и сервер, у которого в спокойном режиме было 20% свободного места на неделю вперёд, на пике может исчерпать его за час. Диск, заполнившийся на 100%, кладёт запись в базу и ротацию логов даже при формально «здоровом» CPU и адекватном времени ответа — поэтому его стоит держать в поле зрения, а не проверять постфактум, когда уже поздно.

df -h

Пять этих графиков вместе отвечают на связную последовательность вопросов: справляется ли железо (CPU) → успевает ли отвечать (перцентили) → видят ли это пользователи как ошибку (5xx) → где узкое место в цепочке (очередь) → не убьёт ли всё банальная нехватка места (диск). Если все пять зелёные — вероятно, всё в порядке, и не нужно лезть в оставшиеся двадцать пять панелей. Если хотя бы один тревожный — именно он подсказывает, куда смотреть дальше.

Чего в этой пятёрке намеренно нет

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

• Сетевой трафик в мегабитах. Полезная метрика для планирования ёмкости канала, но почти никогда не первый сигнал проблемы: сервис обычно упирается в CPU, память или очередь заметно раньше, чем в пропускную способность сети, если только у вас не специфический профиль нагрузки с большими файлами.
• Использование памяти без контекста. Память сама по себе информативна плохо: занятая память может быть кэшем страниц, который ОС охотно освободит при необходимости, а не признаком утечки. На первом экране полезнее производные метрики — доля памяти, реально недоступной под нагрузкой, или частота срабатывания OOM killer, но не «сколько мегабайт занято» как таковое.
• Детализация по каждому эндпоинту API. На пике важно понять, жив ли сервис в целом. Разбивка по полусотне маршрутов — это уже второй уровень диагностики, к которому вы переходите после того, как общий график ошибок сказал «да, что-то не так».
• Долгосрочные тренды и сравнения с прошлым месяцем. Такие графики отвечают на вопрос «нормально ли то, что происходит, в сравнении с историей», но требуют спокойного анализа, а не взгляда за две секунды. Держать их на первом экране — тратить драгоценное место на то, что не помогает принять решение прямо сейчас.

Каждая из этих метрик по-своему полезна — просто не в первые минуты пика, а на следующем шаге, когда пятёрка уже указала направление и нужно разобраться в деталях.

Как собрать единый экран заранее

Смысл этого экрана — не в том, чтобы существовать где-то в системе мониторинга, а в том, чтобы быть открытым буквально за минуты до пика, если пик плановый (распродажа, релиз, маркетинговая рассылка), или моментально доступным по одной ссылке, если пик внезапный.

В Grafana такой экран удобно собрать как отдельный дашборд, а не как вкладку общего дашборда с тридцатью панелями:

• Пять панелей, расположенных так, чтобы все помещались на экране без прокрутки — сеткой 2×3 или 1×5, в зависимости от соотношения сторон монитора.
• Временное окно по умолчанию — последние 15-30 минут с автообновлением каждые 10-15 секунд, а не «последние 24 часа», которое актуально для анализа трендов, но не для мониторинга здесь-и-сейчас.
• Цветовые пороги настроены заранее, а не подбираются на глаз в момент инцидента: зелёный — норма, жёлтый — «стоит посмотреть», красный — «действовать». Пороги стоит калибровать по собственной истории нагрузки, а не по чужим ориентирам — у вас может быть штатная p99 в 300 мс там, где у соседнего проекта уже тревога.
• Ссылка на этот дашборд закреплена в закладках браузера, в топе канала оповещений в мессенджере и в самом регламенте реагирования — чтобы её не искать в момент, когда искать некогда.

Если сложная система метрик пока не развёрнута, минимальный вариант — терминал с watch и парой команд, обновляющихся раз в несколько секунд:

watch -n 5 'echo "--- CPU/Load ---"; uptime; echo "--- Disk ---"; df -h / /var; echo "--- Connections ---"; ss -s'

Это не заменит полноценный дашборд, но закрывает базовый случай, когда мониторинг ещё не готов, а решение нужно принимать уже сейчас.

Кто смотрит на экран и что делать с тем, что там видно

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

Первое — назначить ответственного за экран заранее, если пик плановый. Не «кто-нибудь заметит», а конкретный человек, у которого это единственная задача на ближайшие 15-30 минут — не отвечать параллельно в поддержке, не деплоить хотфиксы, а следить за экраном и говорить вслух, если один из пяти графиков ушёл в красное. Разделение ролей «кто наблюдает» и «кто чинит» экономит критические минуты: наблюдатель не отвлекается на устранение проблемы и не пропускает следующий тревожный сигнал, пока разбирается с первым.

Второе — заранее прописать, что означает красный цвет на каждом из пяти графиков и что делать в этом случае. Не общее «разобраться», а конкретное первое действие: при переполнении очереди подключений к базе — проверить, не завис ли один долгий запрос, блокирующий пул; при росте p99 без роста CPU — проверить внешние зависимости (платёжный шлюз, API доставки); при красном диске — какие директории чистить в первую очередь и какие логи можно ротировать вручную прямо сейчас. Это не отменяет полноценный регламент на первые 15 минут инцидента, а дополняет его конкретной привязкой «этот график — это действие».

Отличие планового пика от внезапного

Всё сказанное выше работает для любого пика, но подготовка отличается в зависимости от того, знаете ли вы время начала заранее.

При плановом пике — старте распродажи, крупной рекламной кампании, релизе с ожидаемым всплеском регистраций — у экрана есть время быть открытым и стабилизированным до события. Этому посвящён отдельный разбор: распродажа началась в полночь — первые 15 минут решают всё, там подробнее про подготовку к конкретному часу «Ч» и про то, как рвётся система при резком, а не постепенном росте нагрузки. Разница с этим текстом в фокусе: там — сценарий одного конкретного события со своей хронологией, здесь — принцип «пять графиков вместо тридцати», применимый к любому пику, плановому или нет.

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

Частые вопросы