Есть ли у вас мониторинг и на каком стеке он работает

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

Умеете ли вы узнать о поломке сервиса раньше пользователей и знаете ли, как Go-приложение отдаёт данные о себе. Следом обычно просят назвать ключевые метрики вашего сервиса и рассказать про алерт, который реально помог.

Как отвечать

Разложите наблюдаемость на три сигнала и назовите, что стояло у вас:

• метрики: Prometheus и библиотека client_golang. Сервис сам отдаёт /metrics через promhttp.Handler(), Prometheus его опрашивает. Экспортёры нужны для чужих систем (node_exporter, postgres_exporter), а своё приложение инструментируется напрямую;
• логи: структурированные, в JSON. С Go 1.21 в стандартной библиотеке есть log/slog, раньше брали zap или zerolog. Собираются в Loki или ELK/OpenSearch;
• трейсы: OpenTelemetry SDK, экспорт в Jaeger или Tempo. В микросервисах без трейсов не видно, какой из пяти сервисов съел время запроса.

Дальше конкретика. Для HTTP и gRPC подходит метод RED: частота запросов, доля ошибок, длительность в виде гистограммы (HistogramVec с осмысленными бакетами, а не среднее). Плюс рантайм: реестр по умолчанию в client_golang отдаёт go_goroutines, паузы GC, память процесса. Растущее число горутин это типичный признак утечки.

Визуализация в Grafana, алерты через Alertmanager или Grafana Alerting с доставкой в Telegram или дежурному. Хорошо сказать, что алерт строится на симптомах (выросла доля 5xx, p99 вышел за SLO), а не на каждой возможной причине. Для разбора на лету есть net/http/pprof, его держат на внутреннем порту.

Если мониторинг настраивали не вы, так и скажите и расскажите, какие метрики добавляли в код и какие дашборды смотрели во время инцидентов.

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

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

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

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