Что добавить для мониторинга и быстрого реагирования на проблемы сервиса
Что проверяют
Понимаете ли вы, что наблюдаемость это не установленная Grafana, а договорённость о том, что считать поломкой, и короткий путь от сигнала к причине. Вопрос часто задают по мотивам вашего же рассказа о сервисе, и ждут связного набора, а не списка модных инструментов.
Как отвечать
Разложите на слои и назовите, что именно мерите.
- Метрики. Для сервиса это частота запросов, доля ошибок и задержка по перцентилям (медиана и хвост, не среднее). Рядом ресурсы, размеры очередей, отставание консьюмера, состояние пула соединений к базе. В Python метрики отдают через
prometheus_client, отдельно снимают воркеры Celery. - Логи. Структурированные, в JSON, с идентификатором запроса, который проходит сквозь все сервисы. Необработанные исключения отдельным потоком в Sentry, со стеком и контекстом.
- Трейсы. OpenTelemetry, чтобы видеть, в каком вызове ушло время, а не гадать по логам.
Сверху: пробы готовности и живости, синтетическая проверка главного сценария снаружи, алерты на симптомы (пятисотки, рост задержки, растущее отставание), пороги из целевого уровня сервиса. И организационная часть, без которой всё остальное не работает: дежурный, канал, короткая инструкция на каждый алерт, разбор инцидента с правкой процесса.
Где спотыкаются
Перечисляют инструменты вместо величин. Названия систем мониторинга не отвечают на вопрос, при каком условии кого-то разбудят ночью.
Заводят алерты на причины и на каждое колебание. Дежурный за неделю привыкает, что всё мигает, и пропускает настоящую аварию. Правило простое: если по алерту нечего сделать, он должен стать отчётом или исчезнуть.
Смотрят на среднюю задержку. Среднее прячет хвост, и заметная часть пользователей ждёт секунды, пока график спокоен. Второй частый промах рядом: синхронное логирование каждого запроса на диск, которое само становится источником тормозов.