Где смотреть метрики приложений
Что проверяют
Есть ли у вас опыт эксплуатации сервиса или метрики вы видели только на чужом скриншоте. Интервьюеру важно, чтобы вы понимали цепочку целиком: кто метрики производит, кто собирает, где на них смотрят. Следом спрашивают, что бы вы вывели на дашборд нового сервиса и на что поставили бы алерт.
Как отвечать
Стройте ответ по цепочке, от приложения к экрану:
- в приложении: в Spring Boot это Actuator плюс Micrometer.
/actuator/metricsпоказывает метрики по имени, а с зависимостьюmicrometer-registry-prometheusпоявляется/actuator/prometheus. По HTTP по умолчанию открыт толькоhealth, остальное включается черезmanagement.endpoints.web.exposure.include. Вне Spring берут Micrometer напрямую или OpenTelemetry Java agent, который снимает метрики без правки кода; - сбор и хранение: Prometheus забирает метрики по pull-модели, для долгого хранения часто ставят VictoriaMetrics или Thanos;
- визуализация и алерты: Grafana для дашбордов, Alertmanager или алерты самой Grafana;
- глубоко по JVM: JMX и VisualVM или JDK Mission Control, а для разбора конкретной проблемы запись Java Flight Recorder через
jcmd <pid> JFR.start; - APM: Datadog, Dynatrace, New Relic, если компания за них платит.
Дальше назовите, что именно смотреть. Для HTTP-сервиса подходит схема RED: частота запросов, доля ошибок, длительность. Для ресурсов схема USE: загрузка, насыщение, ошибки. По JVM обязательно куча, паузы GC, число потоков, пул соединений HikariCP. Длительность смотрят перцентилями p95 и p99, а не средним: среднее прячет хвост медленных запросов.
Где спотыкаются
Путают логи и метрики. ELK хранит события, а не числовые ряды: посчитать RPS по логам можно, но дорого и медленно.
Кладут в теги метрик идентификатор пользователя или URL с параметрами. Высокая кардинальность раздувает Prometheus, пока ему не кончится память.
Не могут сказать, что было видно на дашборде во время последнего инцидента. Если своего такого случая нет, честнее сказать, что метрики вы смотрели, а алерты настраивал кто-то другой.