Использовали ли метрики, трейсы и логирование

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

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

Как отвечать

Вопрос про опыт, поэтому основу ответа составляет ваш проект: что инструментировали, куда отправляли данные, какие алерты настроили и что нашли. Числа нужны ваши, реальные. Технический каркас для Go:

• метрики: prometheus/client_golang, эндпоинт /metrics через promhttp.Handler(). Типы: Counter, Gauge, Histogram, Summary. Для HTTP и gRPC удобен подход RED: частота запросов, доля ошибок, распределение длительности. Визуализация в Grafana, алерты через Alertmanager;
• трейсы: OpenTelemetry Go SDK, инструментирование через otelhttp и otelgrpc, экспорт по OTLP в Jaeger или Tempo. Контекст трейса передаётся через context.Context внутри сервиса и заголовок traceparent между сервисами;
• логи: log/slog в стандартной библиотеке с Go 1.21, JSON-обработчик для сбора в Loki или ELK. До него стандартом де-факто были zap и zerolog;
• связка: trace_id в каждой строке лога и exemplars в метриках, чтобы из графика перейти в трейс, а из трейса в логи.

Отдельно можно упомянуть pprof: профилирование часто называют четвёртым сигналом, и в Go оно доступно из коробки.

Если трейсинга в ваших проектах не было, скажите прямо: работали с логами и метриками, трейсинг знаете по документации или пет-проекту. И объясните, какую задачу он решил бы в вашей системе.

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

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

Теряют контекст: создают context.Background() посреди обработчика или запускают горутину без ctx. Трейс рвётся, и спаны появляются сиротами без родителя.

Используют Summary для латентности в сервисе с несколькими репликами. Квантили summary нельзя усреднить между инстансами, для агрегации нужен Histogram и histogram_quantile.