1. Введение
Одним из важных компонентов современной разработки программного обеспечения является мониторинг. Он позволяет непрерывно следить за состоянием приложений и инфраструктуры, что дает возможность активно обнаруживать проблемы, предотвращать возникновение аварий и оптимизировать работу системы.
Метрики собирает и анализирует Prometheus – гибкая система с открытым исходным кодом, являющаяся одним из самых распространенных инструментов для реализации мониторинга.
Цель данной статьи — рассмотреть процесс разработки сервиса мониторинга на основе Prometheus и оценить его значимость в контексте современной разработки программного обеспечения.
Основная идея заключается в том, чтобы создать отдельный сервис для мониторинга, который будет специализироваться на обработке различных видов метрик. Это решение было принято из-за большого числа приложений в системе, каждое из которых требовала регистрацию метрик.
Для улучшения взаимодействия с сервисом мониторинга, создана библиотека, которая обеспечивает возможность передачи всех необходимых данных для регистрации метрик в системе мониторинга.
2. Задачи мониторинга
Основными задачами сервиса мониторинга являются:
-
непрерывное отслеживание состояния приложений и инфраструктуры;
-
своевременное обнаружение проблем и аномалий;
-
мониторинг ключевых метрик производительности и доступности;
-
анализ трендов и прогнозирование нагрузки;
-
улучшение процесса принятия решений на основе данных.
3. Технологии и инструменты
4. Проблемы, с которыми столкнулись:
Использование нескольких экземпляров сервиса:
-
возникали проблемы с формированием метрик типа Timer, т.к. для регистрации метрики требовалось рассчитать время и заводились такие поля в базе данных, как start и stop. В случае с несколькими экземплярами приложения stop приходил раньше, чем start, тем самым регистрировалась неправильная метрика;
-
возникает проблема при формировании метрики типа Gauge, т.к. события регистрировались на одном из доступных экземпляре сервиса, что мешало их объединению.
Решением стало вынос регистрации метрик в scheduling, который раз в определенное время забирает метрику из базы данных (первоначально получая сообщение через Kafka, дополняя сущность и записывая ее в базу) и регистрирует ее, при этом добавлены ограничения, которые позволяют регистрировать метрику на одном экземпляре сервиса.
5. Разработка и настройка мониторинга
Процесс разработки и настройки мониторинга включает в себя следующие этапы:
-
проектирование системы мониторинга: определение задач, выбор метрик для отслеживания, архитектура системы;
-
настройка Prometheus;
-
установка соответствующих параметров, чтобы обеспечить эффективный сбор данных.
Для отображения графиков в Grafana используется три вида метрик:
-
counter — совокупный показатель, представляющий собой один монотонно увеличивающийся счетчик, значение которого может увеличиваться или сбрасываться на ноль только при перезапуске приложения;
-
gauge — метрика, является числовым значением, которое можно изменять в произвольном порядке, увеличивая или уменьшая его;
-
timer — инструмент, который используется для мониторинга времени выполнения задач и операций в системах.
Для каждой из этих метрик требуется своя сущность с данными.
Пример сущностей:
CounterData:
public class CounterData { private String code; private Long value; private List<LabelsData> additionalLabels; }
GaugeData:
public class GaugeData { private String code; private Long currentParameter; private List<LabelsData> additionalLabels; }
TimerData:
public class TimerData { private String code; private String id; private Long time; }
Сохранение всех сущностей в сервисе мониторинга при использовании микросервисной архитектуры является неоптимальным, поскольку это потребует дублирования сущностей на стороне другого микросервиса для их вызова. Поэтому было принято решение реализовать библиотеку мониторинга, которая предоставляет доступ к методам для взаимодействия с сервисом мониторинга.
Чтобы общаться с сервисом мониторинга, достаточно подключить библиотеку к себе в приложение и вызвать нужный метод для отправки метрики в сервис мониторинга.
В качестве основного интерфейса общения с сервисом мониторинга был выбран Apache Kafka.
Пример использования через метод:
private void sendCounter(String code) { monitoringSender.sendCounterData(code) }
Пример с аннотацией:
@MonitoringTimeEvent( onStart = "start", onStop = "stop", onError = "error" ) private void getReport();
Обработка метрик сервисом мониторинга:
В процессе обработки метрик, отправленных через Kafka в топик сервиса мониторинга с использованием библиотеки, вначале происходит расширение сущности метрики путем обращения в dictionary (сделано для того чтобы передавать дополнительную информацию по метрике в label).
Для того чтобы обеспечить корректную обработку данных в дальнейшем, необходимо записать информацию в базу данных для метрик типа gauge и timer, так как имеется несколько экземпляров сервиса, что может мешать корректной обработки метрики.
Регистрация метрик осуществляется через scheduler в сервисе мониторинга, который периодически извлекает данные и регистрирует их.
Пример scheduler-а по регистрации метрик типа timer:
public class SchedulingTimerProcessingService { @Scheduled(fixedDelay = 10000) public void processTimer() { processingTimer(); } /** * Обработка метрик типа Timer */ private void processingTimer() { // Получение данных из базы и обработка метрики } }
Пример классов с регистрацией метрик:
Counter:
public class CounterFactory { public Counter createMetrics(final CounterEventData data) { return Counter.builder() .tags() .register(); } }
Gauge:
public class GaugeFactory { public Map<Gauge, AtomicLong> createComplexMetrics(final GaugeEventData data, Long currentParameter) { Gauge gauge = Gauge.builder() .tags() .register(); return Map.of(gauge, currentParameter); }) }
Timer:
public class TimerFactory { public Timer createMetrics(final TimerEventData data) { return Timer.builder(data.getEventName()) .tags() .publishPercentileHistogram() .maximumExpectedValue() .publishPercentiles() .register(); } }
Рассмотрим два из возможных процесса реализации обработки метрики:
Процесс №1:
Один из вариантов простого процесса, который можно применить для сервиса с одним экземпляром.
Стандартный процесс, в котором идет получение структуры для регистрации метрики, сама регистрация и обработка метрики, установка значения или его увеличение.
Процесс №2:
Если присутствует работа с несколькими экземплярами сервиса, то может потребоваться использование базы данных, обработка метрики перейдет в scheduler, который раз в определенное время регистрирует метрики.
6. Grafana
Инструмент, который используется для визуализации метрик, собранных с помощью Prometheus, позволяя представлять их в виде графиков.
Рассмотрим процесс: «Интернет-магазин»
У нас есть «интернет-магазин», где мы отслеживаем следующие бизнес-метрики:
-
количество заказов – Counter;
-
количество добавлений в корзину – Counter;
-
количество активных пользователей на сайте в реальном времени – Gauge;
-
время обработки заказа – Timer.
Для отображения графиков потребуется завести новый дашборд.
Общие шаги:
-
добавить новую панель;
-
выбрать источник данных (в нашем случае Prometheus);
-
ввод запроса;
-
настраиваем тип графика (например, линия или столбчатая диаграмма);
-
добавляем подписи для ясности.
Панель 1: Количество заказов
Запрос — sum(orders_total)
Панель 2: Количество добавлений в корзину
Запрос — sum(add_to_cart_total)
Панель 3: Количество активных пользователей на сайте в реальном времени
Запрос — active_users
Панель 4: Время обработки заказа
Запрос — histogram_quantile(0.95, sum(rate(order_processing_seconds_bucket[5m])) by (le) – покажет 95-й процентиль времени обработки заказов за последние 5 минут.
Пример демонстрирует, как можно использовать Grafana для визуализации и анализа бизнес-метрик интернет-магазина.
Примеры графиков, которые не относятся к «интернет-магазину», но демонстрируют визуализацию:
Timer:
Gauge
7. Сопровождение мониторинга
Сопровождение системы мониторинга включает в себя регулярное обновление компонентов, добавление новых метрик при необходимости, а также адаптацию системы к изменяющимся требованиям и условиям эксплуатации.
8. Заключение
Внедрение сервиса мониторинга на базе Prometheus играет ключевую роль в обеспечении стабильной работы приложений и инфраструктуры. Правильно спроектированный и настроенный мониторинг позволяет оперативно реагировать на проблемы, оптимизировать ресурсы и повышать эффективность работы системы в целом.
Благодаря Prometheus, сервисы будут иметь возможность более быстро и эффективно решать проблемы, и следить за состоянием своих систем. Сервисы смогут легко работать с другими инструментами и обрабатывать большие объемы данных. Все эти изменения сделают сервисы эффективнее и надежнее, соответствующими современным требованиям.
9. Список использованных источников
-
официальная документация Prometheus: https://prometheus.io/docs;
-
официальная документация Grafana: https://grafana.com/docs.
ссылка на оригинал статьи https://habr.com/ru/articles/842390/
Добавить комментарий