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.