Какие минимальные метрики нужны для мониторинга приложения 24/7

Что проверяют

Отличаете ли вы метрики, по которым будят ночью, от красивых графиков на дашборде. Ждут связного минимума, а не выписки из документации Prometheus. Следом спросят, на что вы поставите алерт и какой возьмёте порог, чтобы дежурный не выгорел за неделю.

Как отвечать

Опирайтесь на два шаблона: RED для сервиса (Rate, Errors, Duration) и USE для ресурсов (Utilization, Saturation, Errors). Минимум на каждый сервис:

• трафик: запросов в секунду с разбивкой по эндпоинту и коду ответа;
• ошибки: доля 5xx и таймаутов, отдельно ошибки зависимостей (база, внешние API, брокер);
• задержка: p50, p95, p99 из гистограммы, а не среднее. Перцентили нельзя усреднять между инстансами, считайте histogram_quantile по сырым бакетам;
• насыщение: CPU и RSS, длина очереди задач, занятые соединения в пуле базы, для asyncio ещё лаг event loop;
• доступность снаружи: blackbox-проба, которая ходит по рабочему сценарию, а не пингует главную страницу;
• бизнес-сигнал: успешные оплаты, регистрации, отправленные письма в минуту. Именно он ловит поломки, при которых все технические графики зелёные;
• логи и трассировки: структурированный JSON с trace_id и OpenTelemetry, чтобы от всплеска на графике дойти до конкретного запроса.

Конкретика по Python: prometheus_client с отдельным эндпоинтом, а под gunicorn и вообще при нескольких воркерах обязателен multiprocess-режим с PROMETHEUS_MULTIPROC_DIR, иначе счётчики скачут в зависимости от того, какой воркер ответил на скрейп. Для Celery смотрите длину очереди и время ожидания задачи, а не только время выполнения.

Алерты стройте на симптомах и бюджете ошибок, с двумя окнами burn rate, а не на пороге «CPU выше 80 процентов».

Где спотыкаются

Алертят на ресурсы. Загруженный CPU не всегда проблема, а деградация p99 при свободном CPU остаётся незамеченной.

Смотрят среднее время ответа. Оно прячет хвост распределения, то есть ровно тех пользователей, которым плохо.

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