Как определить, что сервис возвращает ошибки 500

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

Есть ли у вас картина наблюдаемости сервиса: как вы узнаете о 500 раньше пользователей и как дойдёте от сигнала до строчки кода. Следом обычно спрашивают, чем 500 отличается от 502 и 504 и какой порог для алерта разумен.

Как отвечать

Опишите путь от сигнала к причине по слоям:

• метрики: счётчик запросов с меткой статуса через prometheus_client или готовые обёртки для Django и FastAPI. Алерт строится не на единичной ошибке, а на доле: запросы с кодом 5xx к общему числу за 5 минут выше порога, в идеале привязанного к SLO и бюджету ошибок;
• access-логи: nginx и Gunicorn или Uvicorn пишут статус каждого запроса. Собранные в Loki или ELK, они быстро показывают, какой эндпоинт и с какого момента сыплет ошибками;
• трекинг исключений: Sentry ловит необработанные исключения с трейсбеком и версией релиза, группирует их и показывает, после какого деплоя они появились;
• трейсинг: OpenTelemetry связывает запрос с вызовами базы и соседних сервисов, видно, на каком шаге всё упало;
• внешние проверки: синтетический запрос раз в минуту к ключевому эндпоинту ловит полный отказ, когда метрики самого сервиса молчат.

Отдельно разведите коды. 500 отдаёт само приложение: необработанное исключение в Django при DEBUG = False уходит в логгер django.request, в FastAPI его перехватывает Starlette. А 502 и 504 обычно ставит прокси: воркер Gunicorn упал или убит по таймауту, и в логах приложения этих запросов нет вовсе.

Для разбора нужен request_id, сквозной для всех логов, и logger.exception() вместо logger.error(), чтобы трейсбек попал в запись.

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

Ищут ошибки только в логах приложения. Когда воркер упал целиком, приложение ничего не записало, а ответ пользователю отдал nginx.

Ставят алерт на каждую единичную 500. Через неделю такие уведомления все игнорируют, и настоящий инцидент тонет в шуме.

Глушат исключение и отдают 200 с полем error в теле. Для мониторинга сервис здоров, а пользователи видят сломанную функцию.