Как организовывали мониторинг на проекте

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

Был ли у вас реальный опыт эксплуатации сервиса или только знакомство с названиями Prometheus и Grafana. Следом обычно спрашивают про конкретный инцидент: какой алерт сработал, как нашли причину и что поменяли после.

Как отвечать

Это вопрос про опыт, поэтому стройте ответ на своём проекте, но с технической конкретикой по слоям:

• метрики: prometheus/client_golang, эндпоинт /metrics через promhttp.Handler(). Стандартные коллекторы бесплатно дают go_goroutines, память и паузы GC. Для HTTP и gRPC удобен подход RED: число запросов, ошибки и латентность в гистограмме, а не в среднем, чтобы видеть p95 и p99;
• логи: структурированные, через log/slog из стандартной библиотеки (с Go 1.21) или zap, в JSON с trace_id, дальше Loki или ELK;
• трейсинг: OpenTelemetry SDK для Go, контекст идёт через context.Context и заголовки между сервисами, бэкенд Jaeger или Tempo;
• профилирование: net/http/pprof на отдельном внутреннем порту, в идеале непрерывное профилирование через Pyroscope;
• алерты: правила считает Prometheus, а доставку в Telegram или почту берёт на себя Alertmanager. Алертить стоит на симптомы (доля ошибок, p99 против SLO), а не на загрузку CPU.

Хорошо рассказать один случай. Например: go_goroutines рос без роста трафика, профиль goroutine из pprof показал горутины, висящие на HTTP-запросах без таймаута, после фикса добавили алерт на этот тренд. Пример и цифры должны быть ваши.

Если мониторинг настраивали не вы, скажите это прямо и опишите свою роль как разработчика: какие дашборды смотрели, какие метрики сами добавили в код, как разбирали алерты на дежурстве.

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

Кладут в лейблы метрик user_id или полный URL с параметрами. Кардинальность взрывается, и Prometheus начинает съедать память.

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

Приводят красивые проценты вроде «время простоя снизилось на 30%» и не могут объяснить, как их считали. Лучше скромная цифра, за которую вы отвечаете.