Какие метрики важны для HTTP API для отслеживания количества 500 ошибок и времени ответа

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

Понимаете ли вы, как собрать долю 500-х и перцентили задержки в Python-сервисе так, чтобы цифрам можно было верить. Следом обычно спрашивают, как это работает под gunicorn с несколькими воркерами и почему ошибку, которую приложение не успело обработать, метрики могут не увидеть.

Как отвечать

Каркас: метод RED, то есть частота запросов, ошибки и длительность, с разрезом по маршруту.

• счётчик запросов: Counter из prometheus_client с метками method, route, status. Долю 5xx считают в PromQL: rate по status=~"5.." делят на rate всех запросов;
• гистограмма времени ответа: Histogram, из которой берут p50, p95 и p99 через histogram_quantile. Бакеты по умолчанию заканчиваются на 10 секундах, под ваш SLO их лучше задать вручную;
• метка маршрута: шаблон вроде /users/{user_id}, а не сырой путь, иначе каждый id станет отдельным временным рядом;
• насыщение: занятость воркеров, ожидание соединения из пула SQLAlchemy, задержка event loop в асинхронном сервисе. Один блокирующий вызов внутри async def поднимает p99 всем запросам процесса.

Писать всё руками не обязательно: для FastAPI есть prometheus-fastapi-instrumentator, для любого стека подходит автоинструментирование OpenTelemetry. Необработанные исключения с трейсбеком удобно отправлять в Sentry, а метрики оставить для трендов и алертов.

Алертить стоит не на единичные 500-е, а на долю ошибок за окно или на расход бюджета ошибок по SLO.

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

Запускают gunicorn с несколькими воркерами и обычный prometheus_client. Каждый воркер это отдельный процесс со своими счётчиками, и Prometheus при каждом опросе видит случайный из них. Нужен multiprocess-режим с PROMETHEUS_MULTIPROC_DIR или сбор метрик на прокси.

Пишут middleware, который берёт статус из готового ответа. Необработанное исключение проходит через него исключением, до записи метрики дело не доходит, а 500 клиенту отдаёт внешний обработчик ошибок. Статус нужно фиксировать и в блоке except.

Не видят ошибок снаружи приложения: воркер убит по timeout, nginx отдал 502 или 504. Эти коды есть только в метриках прокси или балансировщика.