Разворачивали ли Grafana и Prometheus с нуля или настраивали

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

Разворачивали ли вы мониторинг руками или пользовались готовым, который настроила платформенная команда. Для Java-разработчика вопрос ещё и про то, что вы считаете достойным измерения в своём сервисе, помимо загрузки процессора.

Как отвечать

Пройдите путь от приложения к дашборду.

• Инструментирование: Spring Boot Actuator и Micrometer, зависимость на реестр Prometheus, метрики отдаются на /actuator/prometheus. Свои метрики регистрируются через MeterRegistry, таймеры включают гистограмму, иначе квантили по нескольким инстансам не посчитать.
• Сбор: Prometheus сам ходит за метриками, цели задаются статически в конфигурации или через обнаружение сервисов, в Kubernetes обычно через оператор и описание цели ресурсом.
• Хранение: локальный диск с ограниченным сроком хранения, для долгой истории отдельное хранилище через remote write.
• Grafana: Prometheus подключается источником данных, дашборды и алерты хранятся в репозитории и раскатываются provisioning-конфигами.
• Что смотреть в JVM: заполнение кучи после сборки мусора, паузы и частота сборок, живые потоки, занятость пула соединений к базе, очередь пула задач, задержки и ошибки по эндпоинтам.
• Алерты: правила на симптомы, видимые пользователю, с выдержкой по времени, чтобы не звенеть на каждом всплеске.

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

Под словом «развернул» подразумевают два запуска контейнеров без томов и конфигурации. После перезапуска история и дашборды пропадают, потому что всё было накликано руками и нигде не сохранено.

Взрывают кардинальность. Идентификатор в теге пути, имя пользователя или текст исключения в метке превращают один ряд в тысячи, и сервер мониторинга начинает падать по памяти.

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