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.