Какие инструменты для мониторинга и отладки используются в Go и микросервисах

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

Работали ли вы с сервисом в проде, а не только запускали его локально. Ответ показывает, понимаете ли вы разницу между логами, метриками и трассировкой, и умеете ли искать причину, когда «всё тормозит».

Как отвечать

Разложите по четырём слоям, они закрывают почти любой инцидент:

• логи: стандартные log и log/slog, из внешних zap и zerolog. Главное не библиотека, а структурированность: поля вместо склеенной строки, уровень, идентификатор запроса, чтобы логи разных сервисов сходились в одну историю;
• метрики: prometheus/client_golang, отдача через promhttp, визуализация в Grafana. Считать стоит нагрузку, ошибки и время ответа, плюс специфику Go: горутины, память, паузы сборщика мусора. Алерты вешаются на симптом для пользователя, а не на «загрузку процессора»;
• трассировка: OpenTelemetry, а хранение в Jaeger или Tempo. В микросервисах это единственный способ увидеть, на каком из восьми вызовов ушло время;
• профилирование и отладка: встроенный pprof даёт профиль процессора, памяти, блокировок и горутин прямо с работающего сервиса, go tool trace показывает планировщик, delve нужен для пошаговой отладки, обычно локально. Отдельно упомяните -race: гонки ловятся тестами, а не глазами.

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

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

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

Забывают, что эндпоинт pprof нельзя выставлять в интернет: это отдельный порт под внутренний доступ.

Не упоминают идентификатор запроса, который тянется через все сервисы. Без него трассировка есть, а связать её с обращением клиента нечем.