Были ли у вас алерты

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

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

Как отвечать

Опишите свою цепочку от метрики до человека и привяжите её к Go:

• метрики из сервиса: prometheus/client_golang, эндпоинт через promhttp.Handler(), счётчики запросов и ошибок, гистограммы задержек. Рантайм библиотека отдаёт сама: go_goroutines, память, паузы GC;
• что мерить: подход RED (частота запросов, доля ошибок, длительность) для API и отдельно насыщение: пул соединений к базе, длина очередей, растущее число горутин как признак утечки;
• правила: выражения PromQL в Prometheus с условием for: 5m, чтобы короткий всплеск не будил дежурного. Алертить стоит на симптомы, которые чувствует пользователь, и на скорость сгорания бюджета ошибок по SLO;
• доставка: Alertmanager группирует уведомления, подавляет зависимые алерты (inhibition), глушит их на время работ (silence) и отправляет в Telegram, Slack или PagerDuty по уровню severity;
• логи и трейсы: структурированный log/slog и трейсинг через OpenTelemetry, чтобы от алерта дойти до конкретного запроса.

Дальше конкретика из вашего опыта: что сработало, как вы локализовали причину, что поменяли после разбора инцидента. Хороший признак зрелости: вы убирали или переделывали шумные алерты. Цифры приводите свои.

Если дежурств не было, скажите честно и расскажите, какие метрики добавляли в код и как смотрели на них в Grafana. Это тоже опыт, пусть и с другой стороны.

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

Ставят алерт на CPU выше 80% или на каждую ошибку в логе. Такие алерты срабатывают постоянно, и их перестают читать.

Считают перцентили задержки через Summary на нескольких репликах и усредняют их. Квантили саммари не агрегируются, для этого нужна гистограмма и histogram_quantile.

Не могут назвать действие по алерту. Если на уведомление нечего сделать, это шум, а не алерт. К каждому правилу стоит приложить ссылку на runbook.