Сайт
/
Блог
/
Гайд по мониторингу на Prometheus

Подробный гайд по мониторингу на Prometheus,
архитектуре и конфигурации

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

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

Зачем нужен Prometheus

Мониторинг производительности системы: Prometheus помогает отслеживать производительность и состояние систем, собирая метрики с различных машин через определенные промежутки времени.
Масштабируемость: инструмент может обрабатывать большие объемы данных и масштабироваться “горизонтально” вверх, что делает его подходящим для сложных и больших сред.
Алертинг: Prometheus содержит конфигурации по оповещениям, которые позволяют определять правила алертинга и нотификации на основе пороговых значений метрик и автоматически уведомлять при возникновении проблем.
Многомерная модель данных: Prometheus использует базу данных типа time-series и хранит все данные в виде метрик, идентифицируемых комбинацией имени метрики и необязательных пар ключ-значение (label). Это обеспечивает гибкий и детальный запрос метрик.
Интеграции с другими системами и инструментами: Prometheus хорошо интегрируется с другими системами и инструментами, включая Grafana для визуализации, что упрощает создание комплексных панелей мониторинга.

Чем и кому полезен Prometheus

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

Инструментом пользуются:

DevOps инженеры: для поддержания работоспособности и производительности инфраструктуры и приложений, а также для настройки систем мониторинга и оповещений.
SRE инженеры: для обеспечения надежности и бесперебойной работы служб, а также для быстрой диагностики и устранения инцидентов.
Разработчики ПО: для мониторинга и улучшения производительности приложений, а также для получения информации о моделях использования и поведении.
Аналитики данных: для анализа данных и показателей производительности, чтобы получить представление о поведении системы и тенденциях производительности.
Другие операционные IT команды: для отслеживания производительности системы, управления ресурсами и эффективного реагирования на инциденты. А также для поддержания высокой доступности сервисов, оптимизации производительности и обеспечения хорошего пользовательского опыта.

Подробнее о продукте можно найти тут.

Архитектура Prometheus

Вот общий обзор архитектуры Prometheus:

Prometheus сервер — главный сервер системы.

Service Discovery — обзор сервисов.

Time-Series Database (TSDB) — база данных временных рядов.

Targets — цели/машины, которые планируем мониторить или из которых собираем данные.

Exports — экспортеры, которые отвечают за сбор данных таргетов и отправку их в Prometheus сервер.

Push Gateway — функция по передачи метрик.

Alert Manager — сервис по оповещениям.

Client Libraries — клиентские библиотеки.

PromQL — язык запросов Prometheus.

Давайте рассмотрим каждый из них детально.

Prometheus сервер

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

Пример конфигурации:

global:
  scrape_interval: 15s 
  evaluation_interval: 15s 
  scrape_timeout: 10s 

rule_files:
  - "rules/*.rules"

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090'] 
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100'] 

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager:9093']

В секции global:

scrape_interval: Указывает, как часто (с каким интервалом) Prometheus будет собирать метрики с указанных целей. В данном примере этот интервал составляет 15 секунд.

evaluation_interval: Определяет, как часто будут оцениваться правила и отправляться уведомления. Интервал также составляет 15 секунд.

scrape_timeout: Задает максимальное время ожидания ответа при сборе метрик. Если ответ не получен в течение этого времени, сбор данных будет прерван. Это время составляет 10 секунд.

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

В секции scrape_configs:

Эта конфигурация обеспечивает базовую настройку Prometheus для сбора метрик и обработки уведомлений.

Time-Series Database (TSDB)

Метрики, которые получает Prometheus, изменяются со временем (ЦП, память, сетевой ввод-вывод и т.д.). Эти данные называются временными рядами. Поэтому Prometheus использует базу временных рядов (TSDB) для хранения всех своих данных.

По умолчанию Prometheus хранит данные на локальном диске. Со временем он уплотняет старые данные, чтобы сэкономить место. Также есть политика хранения для удаления старых данных.

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

Политика хранения на основе времени: Данные будут храниться в течение указанного количества дней. По умолчанию данные хранятся 15 дней.
Политика хранения на основе размера: Вы можете указать максимальный объем данных, который может хранить TSDB. Когда этот лимит будет достигнут, Prometheus освободит место для новых данных.

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

Targets

В данном случае речь про источник, из которого Prometheus собирает метрики. Таргетом могут быть серверы, сервисы, модули Kubernetes, приложения и т. д.

По умолчанию Prometheus ищет метрики по пути /metrics таргета. Путь можно изменить в конфигурации таргетов.

Целевые конфигурации присутствуют в Scrape_configs в файле конфигурации Prometheus. Вот пример конфигурации:

scrape_configs:
  
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter1:9100', 'node-exporter2:9100']
 
  - job_name: 'my_custom_job'
    static_configs:
      - targets: ['my_service_address:port']
    metrics_path: '/custom_metrics'

  - job_name: 'blackbox-exporter'
    static_configs:
      - targets: ['blackbox-exporter1:9115', 'blackbox-exporter2:9115']
    metrics_path: /probe

  - job_name: 'snmp-exporter'
    static_configs:
      - targets: ['snmp-exporter1:9116', 'snmp-exporter2:9116']
    metrics_path: /snmp

Этот конфигурационный файл задает параметры для Prometheus, чтобы он собирал метрики из различных источников:

Node Exporter для системных метрик.
Пользовательский сервис для пользовательских метрик.
Blackbox Exporter для проверки доступности сервисов.
SNMP Exporter для мониторинга сетевых устройств.

Каждое задание определяет свои таргеты и путь к метрикам (metrics_path), чтобы Prometheus мог эффективно собирать данные из различных источников.

Prometheus exporters

Экспортеры подобны агентам, которые запускаются на таргетах. Они преобразует метрики конкретной системы в формат, понятный Prometheus.

Это могут быть системные метрики, такие как ЦП, память, или метрики Java JMX, метрики MySQL и т.д.

По умолчанию эти преобразованные метрики экспортируются по пути /metrics таргетов.

Например, если вы хотите мониторить ЦП и память сервера, необходимо установить Node Exporter на этом сервере, и он экспортирует их в формате метрик Prometheus по пути /metrics.

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

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

Весь список экспортеров по каждой категории можно найти в официальной документации.

В конфиг файле Prometheus все данные об экспортерах указаны в секции scrape_configs.

scrape_configs:
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter1:9100', 'node-exporter2:9100']

  - job_name: 'blackbox-exporter'
    static_configs:
      - targets: ['blackbox-exporter1:9115', 'blackbox-exporter2:9115']
    metrics_path: /probe

  - job_name: 'snmp-exporter'
    static_configs:
      - targets: ['snmp-exporter1:9116', 'snmp-exporter2:9116']
    metrics_path: /snmp

Prometheus Service Discovery

Prometheus использует два метода для извлечения метрик из целей:

Статические конфигурации: если таргеты имеют статический IP-адрес или DNS эндпоинт, мы можем использовать их в качестве таргетов.
Service Discovery: в большинстве систем автоматического масштабирования, например Kubernetes, таргет не статичен. В этом случае таргеты обнаруживаются с помощью Prometheus Service Discovery, и они автоматически добавляются в конфигурацию.

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

scrape_configs:
      - job_name: 'kubernetes-apiservers'
        kubernetes_sd_configs:
        - role: endpoints
        scheme: https
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
        relabel_configs:
        - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
          action: keep
          regex: default;kubernetes;https

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

В Kubernetes также есть обнаружение файловых служб file_sd_configs. Это для статических таргетов, но основное различие между классической статической конфигурацией static_configs и file_sd_configs заключается в том, что мы создаем отдельные файлы JSON или YAML и сохраняем в них нашу целевую информацию. Prometheus читает файлы, чтобы идентифицировать таргеты.

Доступны не только эти два, но и различные методы обнаружения служб, такие как consul_sd_configs, где Prometheus получает информацию о цели от consul, ec2_sd_configs и т. д.

Подробнее о такой конфигурации можно найти тут.

Prometheus Pushgateway

По умолчанию Prometheus использует механизм pull для сбора метрик. Однако есть сценарии, в которых метрики нужно отправлять (push) в Prometheus.

Рассмотрим пример batch job, выполняющегося на Kubernetes CronJob, которое запускается ежедневно на 5 минут по определенным событиям. В этом сценарии Prometheus не сможет правильно собирать метрики сервиса, используя механизм pull.

Поэтому нам самим нужно отправить метрики в Prometheus. Для этого есть решение под названием Pushgateway. Это своего рода промежуточный шлюз.

Pushgateway должен быть запущен как отдельный компонент. Пакетные задания могут отправлять метрики в Pushgateway с использованием HTTP API. Затем Pushgateway экспортирует эти метрики по пути /metrics. После этого Prometheus собирает эти метрики из Pushgateway.

Pushgateway временно сохраняет данные метрик в оперативной памяти. Конфигурация Pushgateway также настраивается в разделе scrape_configs в конфигурационном файле Prometheus.

scrape_configs:
  - job_name: "pushgateway"
        honor_labels: true
        static_configs:
        - targets: [pushgateway.monitoring.svc:9091]

Для отправки метрик в Pushgateway необходимо использовать клиентские библиотеки Prometheus и инструментировать приложение или скрипт, чтобы экспортировать необходимые метрики.

Prometheus Client Libraries

Клиентские библиотеки Prometheus — это программные библиотеки, которые можно использовать для инструментирования кода приложения, чтобы экспортировать метрики в формате, понятном Prometheus.

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

Хороший пример использования — пакетные задания, которым нужно отправлять метрики в Pushgateway. Пакетное задание должно быть инструментировано клиентскими библиотеками.

Вот пример клиентской библиотеки Python, которая экспортирует пользовательские метрики с именем batch_job_records_processed_total.

from prometheus_client import start_http_server, Counter
import time
import random
RECORDS_PROCESSED = Counter('batch_job_records_processed_total', 'Total number of records processed by the batch job')
def process_record():
    time.sleep(random.uniform(0.01, 0.1))
    RECORDS_PROCESSED.inc()
def batch_job():   
    for _ in range(100):
        process_record()
if __name__ == '__main__': 
    start_http_server(8000)
    print("Metrics server started on port 8000")
    batch_job()
    print("Batch job completed")
    while True:
        time.sleep(1)

Также при использовании клиентских библиотек HTTP-сервер prometheus_client предоставляет доступ к метрикам по адресу /metrics. Prometheus имеет клиентские библиотеки для практически каждого языка программирования, и если вам нужно создать собственную клиентскую библиотеку, вы можете это сделать.

Подробнее о правилах создания и просмотра списка клиентских библиотек можно узнать на официальной странице Prometheus.

Prometheus Alert Manager

Alertmanager является ключевой частью системы мониторинга Prometheus. Его основная задача — отправлять оповещения на основе порогов метрик, установленных в конфигурации оповещений Prometheus.

Оповещения срабатывают в Prometheus и отправляются в Alertmanager. Затем Alertmanager направляет оповещения в соответствующие системы (например, по электронной почте, Slack и т. д.), настроенные в его конфигурации.

Кроме того, Alertmanager занимается следующими задачами:

Дедупликация оповещений: процесс подавления дублирующихся оповещений.
Группировка: процесс объединения связанных оповещений вместе.
Заглушка: временное отключение оповещений для обслуживания или ложных срабатываний.
Маршрутизация: направление оповещений получателям на основе их важности.
Ингибирование: процесс приостановки оповещений низкой важности в присутствии оповещений средней или высокой важности.

Пример конфигурации правила оповещения:

groups:
- name: microservices_alerts
  rules:
  - record: http_latency:average_latency_seconds
    expr: sum(http_request_duration_seconds_sum) / sum(http_request_duration_seconds_count)
  - alert: HighLatencyAlert
    expr: http_latency:average_latency_seconds > 0.5
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "High latency detected"
      description: " Here’s an average HTTP latency is high ({{ $value }} seconds)"

Группа правил (groups):

name: Название группы правил оповещений. В данном случае это microservices_alerts.

Правила (rules):

record: http_latency

expr: Выражение для записи новой временной серии (record)
http_latency:average_latency_seconds. В данном примере выражение считает среднюю задержку HTTP запросов на основе суммы суммарных длительностей запросов и суммы количества запросов.

alert: HighLatencyAlert

expr: Выражение для условия срабатывания оповещения. Здесь оповещение HighLatencyAlert срабатывает, если средняя задержка HTTP запросов (http_latency:average_latency_seconds) превышает 0.5 секунд.
for: Период времени, в течение которого условие должно быть истинным (5 минут).
labels: Метки оповещения. В данном случае установлен уровень серьезности critical.
annotations: Аннотации оповещения.
summary: Краткое описание события.
description: Подробное описание события, включая значение переменной ({{ $value }}).

Эта конфигурация определяет два правила для мониторинга и оповещения о высокой задержке HTTP запросов.

Первое правило (record) вычисляет среднюю задержку HTTP запросов.
Второе правило (alert) определяет условие для срабатывания оповещения HighLatencyAlert, если средняя задержка превышает 0.5 секунды в течение 5 минут. Когда это условие выполняется, Prometheus генерирует оповещение, помеченное как критическое, и предоставляет подробное описание проблемы.

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

Пример конфигурации маршрутизации в Alertmanager:

routes:
- match:
    severity: 'critical'
  receiver: 'oncallduty-notifications'

- match:
    severity: 'warning'
  receiver: 'slack-notifications'

Маршруты (routes):

match: Условие совпадения для маршрута оповещений.
severity: Уровень серьезности оповещения. В этом примере указаны два условия:

Если уровень серьезности critical, оповещение будет отправлено на получателя oncallduty-notifications.

Если уровень серьезности warning, оповещение будет отправлено на получателя slack-notifications.

Этот фрагмент конфигурации позволяет Alertmanager маршрутизировать оповещения в зависимости от уровня их серьезности, отправляя их получателям, настроенным в конфигурации.

Alertmanager поддерживают большинство систем сообщений и уведомлений, таких как Discord, Email, MS Teams, Slack и т. д., чтобы доставлять оповещения.

PromQL

PromQL (Prometheus Query Language) — это язык запросов, который используется для извлечения временных рядов метрик из Prometheus.

Запросы на PromQL можно выполнять непосредственно через пользовательский интерфейс Prometheus или с помощью команды curl в командной строке.

Curl:
curl "http://54.186.154.78:30000/api/v1/query?query=$(echo 'up' | jq -s -R -r @uri)" | jq .

Также, когда вы добавляете Prometheus в качестве источника данных в Grafana, вы можете использовать PromQL для создания запросов и создания дашбордов в Grafana.

Заключение

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

Закажите аудит мониторинга

Даже если у вас нет четкой задачи, мы все обсудим и подскажем.

Узнать больше

Подробный гайд по мониторингу на Prometheus,архитектуре и конфигурации