Инструментом пользуются:
Подробнее о продукте можно найти тут.
Вот общий обзор архитектуры Prometheus:
Prometheus сервер — главный сервер системы.
Service Discovery — обзор сервисов.
Time-Series Database (TSDB) — база данных временных рядов.
Targets — цели/машины, которые планируем мониторить или из которых собираем данные.
Exports — экспортеры, которые отвечают за сбор данных таргетов и отправку их в Prometheus сервер.
Push Gateway — функция по передачи метрик.
Alert Manager — сервис по оповещениям.
Client Libraries — клиентские библиотеки.
PromQL — язык запросов 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 для сбора метрик и обработки уведомлений.
Метрики, которые получает Prometheus, изменяются со временем (ЦП, память, сетевой ввод-вывод и т.д.). Эти данные называются временными рядами. Поэтому Prometheus использует базу временных рядов (TSDB) для хранения всех своих данных.
По умолчанию Prometheus хранит данные на локальном диске. Со временем он уплотняет старые данные, чтобы сэкономить место. Также есть политика хранения для удаления старых данных.
TSDB имеет встроенные механизмы для управления данными, которые хранятся длительное время. Вы можете выбрать любую из следующих политик хранения данных.
Prometheus также предлагает варианты удаленного хранения данных. Это в основном необходимо для масштабируемости хранения, долгосрочного хранения, резервного копирования и восстановления после сбоев.
В данном случае речь про источник, из которого 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, чтобы он собирал метрики из различных источников:
Каждое задание определяет свои таргеты и путь к метрикам (metrics_path), чтобы Prometheus мог эффективно собирать данные из различных источников.
Экспортеры подобны агентам, которые запускаются на таргетах. Они преобразует метрики конкретной системы в формат, понятный 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 использует два метода для извлечения метрик из целей:
Давайте рассмотрим пример настройки обнаружения сервисов 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 использует механизм 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 — это программные библиотеки, которые можно использовать для инструментирования кода приложения, чтобы экспортировать метрики в формате, понятном 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.
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):
Правила (rules):
record: http_latency
alert: HighLatencyAlert
Эта конфигурация определяет два правила для мониторинга и оповещения о высокой задержке HTTP запросов.
Этот механизм позволяет оперативно реагировать на проблемы производительности, уведомляя администраторов о высокой задержке HTTP запросов и предоставляя необходимую информацию для быстрого решения проблемы.
Пример конфигурации маршрутизации в Alertmanager:
routes:
- match:
severity: 'critical'
receiver: 'oncallduty-notifications'
- match:
severity: 'warning'
receiver: 'slack-notifications'
Маршруты (routes):
Если уровень серьезности critical, оповещение будет отправлено на получателя oncallduty-notifications.
Если уровень серьезности warning, оповещение будет отправлено на получателя slack-notifications.
Этот фрагмент конфигурации позволяет Alertmanager маршрутизировать оповещения в зависимости от уровня их серьезности, отправляя их получателям, настроенным в конфигурации.
Alertmanager поддерживают большинство систем сообщений и уведомлений, таких как Discord, Email, MS Teams, Slack и т. д., чтобы доставлять оповещения.
PromQL (Prometheus Query Language) — это язык запросов, который используется для извлечения временных рядов метрик из Prometheus.
Запросы на PromQL можно выполнять непосредственно через пользовательский интерфейс Prometheus или с помощью команды curl в командной строке.
Также, когда вы добавляете Prometheus в качестве источника данных в Grafana, вы можете использовать PromQL для создания запросов и создания дашбордов в Grafana.
Надеемся, эта статья помогла вам лучше понять архитектуру Prometheus мониторинга: из чего она состоит и какие конфигурации можно применить. Также рекомендуем официальную документацию Prometheus, чтобы начать свой путь мониторинга (первые шаги и установка).
Даже если у вас нет четкой задачи, мы все обсудим и подскажем.
Узнать больше