Рубрики
Без рубрики

Мониторинг приложений Spring Boot с помощью Micrometer, Prometheus и Grafana

Мониторинг работоспособности приложения помогает нам управлять им и улучшать оптимизацию и производительность. В этой статье мы будем использовать Micrometer, Prometheus и Grafana для тщательного мониторинга приложения Spring Boot.

Автор оригинала: Dhananjay Singh.

Вступление

Мониторинг работоспособности и показателей приложения помогает нам лучше управлять им, замечать неоптимизированное поведение и приближаться к его производительности. Это особенно верно, когда мы разрабатываем систему со множеством микросервисов, где мониторинг каждой службы может оказаться решающим, когда дело доходит до обслуживания нашей системы.

Основываясь на этой информации, мы можем сделать выводы и решить, какой микросервис необходимо масштабировать, если дальнейшее повышение производительности не может быть достигнуто при текущей настройке.

В этой статье мы рассмотрим, как отслеживать веб-приложения Spring Boot. Для достижения этой цели мы будем использовать три проекта:

  • Микрометр : Отображает показатели из нашего приложения
  • Prometheus : Хранит наши метрические данные
  • Графана : Визуализирует наши данные в виде графиков

Это может показаться многовато, особенно по сравнению с простым использованием проекта Spring Boot Actuator, но все это очень легко реализовать с помощью всего нескольких конфигураций.

Чтобы сделать все еще проще, мы будем использовать Docker для запуска Prometheus и Grafana, поскольку у них обоих есть официальные изображения Docker. Если вы не знакомы с Докером, вы можете ознакомиться с нашей статьей Докер: Введение высокого уровня .

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

В этом случае вам, вероятно, понадобится распределенная система отслеживания, которую мы подробно рассмотрели в разделе Распределенная трассировка с помощью Sleuth .

Привод Пружинного Ботинка

Мы начнем с простой службы REST, использующей Spring Initializr , которая содержит единственную конечную точку /привет и работает на порту по умолчанию 8080 .

Кроме того, это приложение также имеет зависимость spring-boot-starter-actuator , которая обеспечивает готовые к производству конечные точки , которые вы можете использовать для своего приложения. Эти конечные точки подпадают под общий префикс /привод и по умолчанию защищены.

Предоставьте их по отдельности или все сразу, добавив следующие свойства в application.properties :

management.endpoints.web.exposure.include=*

Чтобы проверить, давайте перейдем в вашем браузере по адресу http://localhost:8080/actuator :

Вы можете видеть все конечные точки, которые предоставляет привод, такие как /работоспособность , /показатели , /сопоставления и т.д. Давайте откроем /метрики конечную точку привода, перейдя в вашем браузере в http://localhost:8080/actuator/metrics :

Как вы можете видеть, здесь есть куча информации о нашем приложении, например, информация о потоках, сеансах Tomcat, классах, буфере и т. Д. Давайте углубимся и получим информацию об используемой памяти JVM:

Теперь использование такого привода пружинной загрузки дает много информации о вашем приложении, но оно не очень удобно для пользователя. Он может быть интегрирован с Spring Boot Admin для визуализации, но имеет свои ограничения и менее популярен.

Такие инструменты, как Prometheus, Netflix Atlas и Grafana, чаще всего используются для мониторинга и визуализации и не зависят от языка/структуры.

Каждый из этих инструментов имеет свой собственный набор форматов данных, и преобразование /метрик данных для каждого из них было бы непросто. Чтобы избежать их преобразования самостоятельно, нам нужен поставщик данных, не зависящий от поставщика, такой как Микрометр .

Микрометр

Чтобы решить эту проблему, связанную с тем, чтобы быть поставщиком данных, не зависящим от поставщика, Появился микрометр . Он предоставляет показатели привода внешним системам мониторинга, таким как Prometheus, Netflix Atlas, AWS Cloudwatch и многим другим.

Они совершенно правильно описывают себя как:

Подумайте о SLF4J, но для показателей.

Так же, как и обновление, SLF4J-это фасад ведения журнала для других фреймворков ведения журнала Java. Сам SLF4J не имеет никакой реализации ведения журнала. Идея заключается в том, что вы пишете код с использованием API SLF4J, и реальная реализация его исходит из выбранной вами платформы. Это может быть любой из популярных фреймворков, таких как log4j , logback и т.д.

Аналогично, микрометр автоматически отображает /привод/показатели данные в то, что может понять ваша система мониторинга. Все, что вам нужно сделать, это включить эту зависимость микрометра от конкретного поставщика в свое приложение.

Микрометр является отдельным проектом с открытым исходным кодом и не входит в экосистему Spring, поэтому мы должны явно добавить его в качестве зависимости. Поскольку мы будем использовать Prometheus , давайте добавим его конкретную зависимость в ваш pom.xml :


    io.micrometer
    micrometer-registry-prometheus

Перестройте и запустите приложение, а затем перейдите в свой браузер по адресу http://localhost:8080/actuator :

Это приведет к созданию новой конечной точки – /привод/прометей . Открыв его, вы увидите данные, отформатированные специально для Prometheus :

Прометей

Prometheus-это база данных временных рядов, которая хранит наши метрические данные, периодически извлекая их (с помощью встроенного скребка данных) по протоколу HTTP. Интервалы между извлечениями, конечно, можно настроить, и мы должны указать URL-адрес для извлечения. Он также имеет простой пользовательский интерфейс, в котором мы можем визуализировать/запрашивать все собранные показатели.

Давайте настроим Prometheus, а точнее интервал очистки, цели и т. Д. Для этого мы будем использовать prometheus.yml файл:

global:
  scrape_interval: 10s

scrape_configs:
  - job_name: 'spring_micrometer'
    metrics_path: '/actuator/prometheus'
    scrape_interval: 5s
    static_configs:
      - targets: ['192.168.2.8:8080']

Как вы можете видеть, у нас есть корневой ключ scrape_configs , в котором мы можем определить список заданий и указать URL-адрес, путь к метрикам и интервал. Если вы хотите узнать больше о конфигурациях Prometheus, не стесняйтесь посетить официальную документацию .

Примечание: Поскольку мы используем Docker для запуска Prometheus, он будет работать в сети Docker, которая не поймет localhost/120.0.01 , как и следовало ожидать. Поскольку наше приложение работает на localhost , а для контейнера Docker localhost означает его собственную сеть, мы должны указать вместо него наш системный IP-адрес.

Поэтому вместо использования localhost:8080 , 192.168.2.8:8080 используется там, где 192.168.2.8 это мой IP-адрес ПК на данный момент.

Git Essentials

Ознакомьтесь с этим практическим руководством по изучению Git, содержащим лучшие практики и принятые в отрасли стандарты. Прекратите гуглить команды Git и на самом деле изучите это!

Чтобы проверить IP-адрес вашей системы, вы можете запустить ipconfig или ifconfig в своем терминале, в зависимости от вашей операционной системы.

Теперь мы можем запустить Prometheus с помощью команды Docker:

$ docker run -d -p 9090:9090 -v :/etc/prometheus/prometheus.yml prom/prometheus

<путь к прометею.yml> там, где ваш собственный прометей.yml начинается с корня. Например, это работает на моем локальном компьютере с Windows:

$ docker run -d -p 9090:9090 -v $PWD/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus

Чтобы просмотреть панель мониторинга Prometheus, перейдите в свой браузер по адресу http://localhost:9090 :

Чтобы проверить, действительно ли Prometheus прослушивает приложение Spring, вы можете перейти к конечной точке /цели :

Давайте вернемся на главную страницу, выберем метрику из списка и нажмем Выполнить :

Язык запросов Prometheus – PromQL

Еще одна вещь, которую следует отметить, – у Prometheus есть свой собственный язык запросов, называемый Pml. Он позволяет пользователю выбирать и агрегировать данные временных рядов в режиме реального времени, сохраняя их либо в графическом, либо в табличном формате. В качестве альтернативы вы можете передать его во внешний API через HTTP.

Если вы хотите узнать больше о PromQL, то официальная документация довольно хорошо описывает это.

Графана

В то время как Prometheus предоставляет некоторую грубую визуализацию, Grafana предлагает богатый пользовательский интерфейс, в котором вы можете быстро создавать пользовательские графики и создавать панель мониторинга из множества графиков в кратчайшие сроки. Вы также можете бесплатно импортировать множество панелей мониторинга, созданных сообществом, и приступить к работе.

Grafana может извлекать данные из различных источников данных, таких как Prometheus, Elasticsearch , InfluxDB и т.д. Он также позволяет вам устанавливать оповещения на основе правил, которые затем могут уведомлять вас по Slack, электронной почте, Hipchat и т. Д.

Давайте начнем с запуска Grafana с помощью Docker:

$ docker run -d -p 3000:3000 grafana/grafana

Если вы посетите http://localhost:3000 , вы будете перенаправлены на страницу входа в систему:

Имя пользователя по умолчанию – admin , а пароль по умолчанию – admin . Вы можете изменить их на следующем шаге, что настоятельно рекомендуется:

Поскольку Grafana работает со многими источниками данных, нам нужно определить, на какой из них мы полагаемся. Выберите Prometheus в качестве источника данных:

Теперь добавьте URL-адрес, по которому работает Prometheus, в нашем случае http://localhost:9090 и выберите Доступ , чтобы быть через браузер.

На этом этапе мы можем сохранить и проверить, правильно ли работает источник данных:

Как уже говорилось ранее, у Grafana есть тонна готовых панелей мониторинга . Для проектов Spring Boot/| популярна панель мониторинга JVM :

Введите URL-адрес для панели мониторинга, выберите “Уже созданный источник данных Prometheus” и нажмите Импорт :

Вывод

Мониторинг работоспособности и показателей приложения помогает нам лучше управлять им, замечать неоптимизированное поведение и лучше понимать его производительность. Это особенно верно, когда мы разрабатываем систему со множеством микросервисов, где мониторинг каждой службы может оказаться решающим, когда дело доходит до обслуживания нашей системы.

Основываясь на этой информации, мы можем сделать выводы и решить, какой микросервис необходимо масштабировать, если дальнейшее повышение производительности не может быть достигнуто при текущей настройке.

В этой статье мы использовали микрометр для переформатирования данных показателей, предоставляемых приводом Spring Boot, и представления их в новой конечной точке. Затем эти данные регулярно извлекались и хранились компанией Prometheus, которая представляет собой базу данных временных рядов. В конечном счете, мы использовали Grafana для визуализации этой информации с помощью удобной панели мониторинга.

Как всегда, код для примеров, используемых в этой статье, можно найти на GitHub .