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

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

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

Как отвечать

Опишите цепочку. В Spring Boot метрики даёт Micrometer через Actuator: с зависимостью micrometer-registry-prometheus появляется эндпоинт /actuator/prometheus. Prometheus регулярно его опрашивает и хранит временные ряды, Grafana подключает Prometheus как источник данных и строит панели запросами на PromQL. Логи обычно идут в Loki, трейсы в Tempo, и Grafana связывает их в одном интерфейсе.

Что вывести на дашборд сервиса:

• RED-метрики: частота запросов, доля ошибок, задержка по перцентилям, например histogram_quantile(0.95, sum by (le) (rate(http_server_requests_seconds_bucket[5m]))). Для этого в Micrometer включают гистограммы;
• JVM: heap, паузы GC, число потоков (jvm_memory_used_bytes, jvm_gc_pause_seconds);
• пул соединений: активные и ожидающие соединения HikariCP, они первыми показывают проблемы с базой;
• бизнес-метрики: свои Counter и Timer, например число оформленных заказов.

Алерты настраиваются в Grafana Alerting: правило с запросом и условием, contact point (почта, Telegram, вебхук) и notification policy для маршрутизации. Альтернатива: правила в Prometheus и Alertmanager. Дашборды держите как код, в JSON через provisioning, а не только кликами в интерфейсе.

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

Называют Grafana базой для метрик. Она визуализирует, а хранит Prometheus, InfluxDB или другой источник.

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

Добавляют в метрики теги с высокой кардинальностью: userId, полный URL с идентификаторами. Число временных рядов взрывается, и Prometheus начинает тормозить.