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

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

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

Как отвечать

Разложите по сигналам:

• метрики: Micrometer и Spring Boot Actuator отдают /actuator/prometheus, Prometheus собирает, Grafana рисует, Alertmanager шлёт уведомления. Смотреть на RED (частота запросов, ошибки, длительность) и на JVM: куча, паузы GC, потоки, пул соединений HikariCP;
• логи: Logback или Log4j2 в формате JSON, сбор в ELK, OpenSearch или Loki. В MDC кладётся traceId, чтобы строки одного запроса находились вместе;
• трассировки: OpenTelemetry Java agent через -javaagent инструментирует HTTP, JDBC и Kafka без правок кода, хранилище Jaeger или Tempo. В Spring Boot 3 для этого есть Micrometer Tracing;
• ошибки: Sentry группирует исключения и показывает, с какого релиза они начались;
• диагностика JVM: JDK Flight Recorder (jcmd <pid> JFR.start) с малыми накладными расходами и разбор в JDK Mission Control; дамп потоков jcmd <pid> Thread.print; дамп кучи по -XX:+HeapDumpOnOutOfMemoryError и анализ в Eclipse MAT; async-profiler для флеймграфов; GC-логи через -Xlog:gc*;
• APM: коммерческие платформы собирают всё это в одном интерфейсе, но принципы те же.

Закончите процессом: алерты ставятся на симптомы, которые видит пользователь (p99 задержки, доля ошибок относительно SLO), а причины ищутся по дашбордам и трассировкам.

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

Смотрят на средние значения. Средняя задержка прячет хвост, а проблемы видны на p95 и p99.

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

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