gerdlezhev.ru

Полное руководство по системе мониторинга Prometheus: от установки до масштабирования в продакшен

—

от автора

Виталий Гердлежев
в

Введение: Что такое Prometheus и почему это важно

В современном мире микросервисной архитектуры и облачных вычислений вопрос мониторинга становится критически важным. Представьте ситуацию: ваше приложение работает на множестве серверов, контейнеров и виртуальных машин. Когда одна из них начинает работать медленнее, пользователи замечают это раньше, чем вы. Именно для предотвращения таких ситуаций и существуют системы мониторинга.

Prometheus — это открытая система мониторинга, разработанная первоначально в компании SoundCloud для решения конкретной задачи: отслеживание множества метрик из множества источников в режиме реального времени. Система была создана с учетом требований cloud-native архитектуры и микросервисов и сегодня является стандартом де-факто для мониторинга в Kubernetes окружении.

Архитектура Prometheus: Компоненты и взаимодействие

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

Сервер Prometheus: Мозг системы

Ядром всей системы является сервер Prometheus. Это приложение, написанное на Go, выполняет несколько функций:

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

Вторая функция — хранение данных. Собранные метрики хранятся в локальной базе данных временных рядов (TSDB — Time Series Database), которая оптимизирована специально для работы с метриками. TSDB в Prometheus 2.x — это полностью переписанная система хранения, которая обеспечивает эффективное использование памяти и быстрый доступ к данным.

Третья функция — обработка и запросы. Сервер предоставляет HTTP API для запросов к сохраненным метрикам с использованием собственного языка запросов PromQL. Эти запросы используются как для визуализации в Grafana, так и для вычисления условий срабатывания алертов.

Time Series Database: Неповторимое хранилище

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

При хранении данные сначала поступают в оперативную память (так называемый head block), где они остаются в течение 2-3 часов. После этого данные записываются на диск в виде оптимизированных блоков. Такая архитектура позволяет добиться высокой скорости записи при минимальном использовании памяти.

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

Exporters: Мосты к внешним системам

Не все приложения и системы имеют встроенную поддержку Prometheus. Для интеграции с такими системами используются экспортеры (exporters) — специальные программы, которые:

Собирают метрики из целевой системы (будь то операционная система, база данных или сетевое оборудование), преобразуют их в формат, понимаемый Prometheus, и предоставляют эти метрики через HTTP эндпоинт /metrics.

Примеры экспортеров:

  • Node Exporter для сбора метрик операционной системы (CPU, память, диск, сеть)
  • PostgreSQL Exporter для сбора метрик из баз данных PostgreSQL
  • MySQL Exporter для MySQL и MariaDB
  • Redis Exporter для кэша Redis
  • cAdvisor для метрик контейнеров Docker

Push Gateway: Для недолгоживущих задач

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

Alertmanager: Интеллектуальная обработка алертов

Alertmanager отвечает за получение алертов от Prometheus, группировку однотипных алертов, их дедупликацию и маршрутизацию в различные системы уведомлений (email, Slack, PagerDuty, Telegram и т.д.). Это полноценная система обработки инцидентов, которая предотвращает алертную усталость благодаря умной группировке.

Метрики Prometheus: Типы и особенности

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

Counter (Счетчик)

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

Примеры: http_requests_total (общее количество HTTP запросов), database_queries_total (всего выполнено запросов к БД), errors_total (общее количество ошибок).

При работе с counters следует помнить, что они представляют кумулятивные значения. Для получения информации о скорости изменения используется функция rate() или irate(). Например, rate(http_requests_total[5m]) покажет среднее количество запросов в секунду за последние 5 минут.

Gauge (Калибр, Индикатор)

Gauge — это метрика, которая может изменяться в обе стороны: увеличиваться и уменьшаться. Используется для отслеживания текущих значений, которые естественным образом колеблются.

Примеры: memory_usage_bytes (текущее использование памяти), queue_length (длина очереди), cpu_utilization (загрузка процессора), in_flight_requests (количество активных запросов).

С gauges можно работать как напрямую (просто запрашивать текущее значение), так и использовать агрегирующие функции (avg, max, min) для анализа трендов.

Histogram (Гистограмма)

Histogram используется для отслеживания распределения значений по диапазонам. Особенно полезна для анализа латентности или размеров запросов.

Внутри гистограмма хранит:

  • Отдельный счетчик для каждого бакета (диапазона значений)
  • Общий счетчик всех наблюдаемых значений
  • Сумму всех наблюдаемых значений

При определении гистограммы в приложении вы указываете границы бакетов. Например, для времени отклика можно определить бакеты: 0.01, 0.05, 0.1, 0.5, 1, 5, 10 секунд.

Каждый бакет содержит кумулятивный счет — первый бакет содержит количество значений ≤ 0.01, второй — количество значений ≤ 0.05 (включая первый бакет) и так далее.

Для вычисления процентилей используется функция histogram_quantile(). Например, histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) покажет 95-й процентиль времени ответа.

Важный момент: гистограммы добавляют размерность к метрикам из-за метки «le» (less than or equal), поэтому избегайте использования гистограмм с высокой кардинальностью лейблов.

Summary (Сводка)

Summary похожа на histogram, но вычисляет квантили на стороне приложения, а не Prometheus. Это означает, что Summary хранит предвычисленные значения квантилей (обычно 0.5, 0.9, 0.99).

Основное отличие: Summary использует меньше памяти в Prometheus (не создает много бакетов), но не позволяет агрегировать данные по временным окнам, так как квантили уже предвычислены.

Язык запросов PromQL: От простого к сложному

PromQL (Prometheus Query Language) — это специализированный язык запросов для работы с метриками. Его освоение критически важно для эффективного использования Prometheus.

Базовая селекция метрик

Самый простой запрос — просто имя метрики:

texthttp_requests_total

Этот запрос вернет все временные ряды с именем http_requests_total.

Фильтрация по лейблам

Для точного выбора метрик используются лейблы:

texthttp_requests_total{job="api", method="GET"}

Это выберет метрики только для API сервиса с методом GET.

Существуют различные операторы сравнения:

  • = (точное совпадение)
  • != (не равно)
  • =~ (регулярное выражение)
  • !~ (регулярное выражение, но не совпадает)

Функции и операции

PromQL поддерживает множество функций для обработки данных:

rate() — вычисляет среднюю скорость изменения за временное окно:

textrate(http_requests_total[5m])

increase() — вычисляет общий прирост за период:

textincrease(http_requests_total[1h])

histogram_quantile() — вычисляет процентили:

texthistogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

sum() — суммирует значения:

textsum(memory_usage_bytes)

avg() — вычисляет среднее значение:

textavg(cpu_usage{job="api"})

topk() — выбирает k наибольших значений:

texttopk(5, increase(http_requests_total[1h]))

Диапазоны времени

При работе с функциями можно указать диапазон времени:

  • m (минуты): [5m]
  • h (часы): [1h]
  • d (дни): [7d]
  • w (недели): [4w]

Арифметические операции

PromQL поддерживает стандартные арифметические операции:

text(http_requests_total{method="POST"} - http_requests_total{method="GET"}) / http_requests_total

Конфигурация Prometheus: Практический подход

Вся конфигурация Prometheus содержится в одном файле prometheus.yml (или любом другом указанном в параметре —config.file).

Глобальные настройки

textglobal:
  scrape_interval: 15s        # Интервал скрейпинга по умолчанию
  scrape_timeout: 10s         # Таймаут запроса метрик
  evaluation_interval: 15s    # Интервал вычисления правил алертов
  external_labels:            # Лейблы, добавляемые ко всем метрикам
    cluster: 'production'
    region: 'eu-west'

Конфигурация скрейпинга

Раздел scrape_configs определяет, откуда Prometheus будет собирать метрики:

textscrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
    
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['server1:9100', 'server2:9100', 'server3:9100']
    scrape_interval: 30s
    
  - job_name: 'database'
    static_configs:
      - targets: ['localhost:9187']
    metric_relabel_configs:
      - source_labels: [__name__]
        regex: 'pg_stat_database.*'
        action: keep

Service Discovery для Kubernetes

При работе с Kubernetes можно использовать автоматическое обнаружение сервисов:

textscrape_configs:
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        target_label: __address__

Правила алертов

Правила алертов хранятся в отдельных файлах:

textgroups:
  - name: application_alerts
    interval: 30s
    rules:
      - alert: HighErrorRate
        expr: rate(http_errors_total[5m]) > 0.05
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High error rate detected"
          description: "Error rate is {{ $value }} per second"
      
      - alert: CriticalMemoryUsage
        expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.1
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Critical memory usage on {{ $labels.instance }}"

Recording Rules: Оптимизация производительности

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

Проблема: Дорогие запросы

Представьте, что у вас есть 1000 серверов, и вам нужно построить график среднего использования CPU за последний час. Если делать это через обычный запрос:

textavg(rate(node_cpu_seconds_total{mode="idle"}[5m]))

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

Решение: Recording Rules

Вместо этого можно создать recording rule:

textgroups:
  - name: cpu_rules
    interval: 1m
    rules:
      - record: instance:node_cpu:rate5m
        expr: rate(node_cpu_seconds_total[5m])
      
      - record: job:node_cpu:avg_rate5m
        expr: avg(instance:node_cpu:rate5m) by (job)

Теперь результаты этих выражений будут автоматически вычисляться каждую минуту и сохраняться как метрики instance:node_cpu:rate5m и job:node_cpu:avg_rate5m, которые можно использовать в запросах и алертах.

Рекомендации по использованию

  1. Используйте четкую схему именования: level:metric:operation (например, job:http_requests:rate1m)
  2. Начните с предвычисления базовых метрик (rate, irate для счетчиков)
  3. Избегайте создания recording rules с высокой кардинальностью лейблов
  4. Мониторьте время выполнения rules через метрику prometheus_rule_evaluation_duration_seconds

Alertmanager: Умная маршрутизация и дедупликация

Alertmanager — отдельный компонент системы, который обрабатывает поток алертов от Prometheus.

Основные возможности

Группировка алертов: однотипные алерты группируются в один для предотвращения алертной бури. При срабатывании множества алертов об одной проблеме пользователь получает одно сообщение вместо сотни.

Дедупликация: если один и тот же алерт срабатывает повторно, он дедублицируется.

Маршрутизация: разные типы алертов отправляются в разные каналы (слепо, PagerDuty, email).

Подавление: можно подавлять определенные алерты, если активны другие (например, не отправлять алерт о медленных запросах, если весь сервис недоступен).

Конфигурация Alertmanager

textglobal:
  resolve_timeout: 5m
  
route:
  receiver: 'default'
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 4h
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'
      continue: true
    - match:
        severity: warning
      receiver: 'slack'

receivers:
  - name: 'default'
    email_configs:
      - to: 'team@example.com'
        smarthost: 'smtp.gmail.com:587'
        auth_username: 'your-email@gmail.com'
        auth_password: 'your-password'
  
  - name: 'pagerduty'
    pagerduty_configs:
      - service_key: 'YOUR_PAGERDUTY_SERVICE_KEY'
  
  - name: 'slack'
    slack_configs:
      - api_url: 'YOUR_SLACK_WEBHOOK_URL'
        channel: '#alerts'

Экспортеры: Практическое руководство

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

Node Exporter: Метрики операционной системы

Node Exporter — наиболее часто используемый экспортер. Он собирает метрики операционной системы:

CPU: процентная загрузка в различных режимах (user, system, iowait, idle)
Память: использованная, свободная, буферированная
Диск: занято, свободно, используется
Сеть: переданные/полученные байты, ошибки, потери пакетов
Процессы: количество, состояние
Системное время: сколько система запущена (uptime)

Запуск Node Exporter простой:

bash./node_exporter --collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/) \
                 --collector.filesystem.fs-types-exclude=^(autofs|binfmt_misc|cgroup|configfs|debugfs|devpts|devtmpfs|fusectl|hugetlbfs|iso9660|mqueue|netprocfs|nsfs|overlay|proc|procfs|pstore|rpc_pipefs|squashfs|sysfs|tracefs)$$

Затем в Prometheus:

textscrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

PostgreSQL Exporter: Метрики базы данных

Для мониторинга PostgreSQL используется postgres_exporter:

textscrape_configs:
  - job_name: 'postgres'
    static_configs:
      - targets: ['localhost:9187']
    metric_relabel_configs:
      - source_labels: [__name__]
        regex: 'pg_stat_database.*'
        action: keep

Он собирает метрики:

  • Количество подключений
  • Размер базы данных
  • Количество коммитов/откатов
  • Блокировки
  • Индексы и таблицы

cAdvisor: Мониторинг контейнеров

cAdvisor собирает метрики контейнеров Docker и Kubernetes:

textscrape_configs:
  - job_name: 'cadvisor'
    static_configs:
      - targets: ['localhost:8080']

Метрики включают:

  • Использование CPU контейнером
  • Использование памяти
  • Объем ввода-вывода
  • Сетевую активность контейнера

Проблемы масштабирования и их решения

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

Проблема 1: Взрыв кардинальности

Кардинальность метрики — это количество уникальных комбинаций лейблов. Если использовать динамические лейблы (например, user_id, request_id, transaction_id), кардинальность может взорваться.

Симптомы: высокое использование памяти, медленные запросы, ошибки «query processing would load too many samples into memory».

Решение: избегайте использования высококардинальных лейблов. Вместо:

textrequests_total{user_id="12345", method="GET"}

Используйте:

textrequests_total{service="api", method="GET"}

Пользовательских IDs лучше обрабатывать через логирование и трейсинг, а не метрики.

Проблема 2: Использование памяти

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

Решение: используйте relabel_configs для отбрасывания ненужных метрик:

textmetric_relabel_configs:
  - source_labels: [__name__]
    regex: 'node_netstat_.*|node_vmstat_.*'
    action: drop

Уменьшайте retention period:

bash./prometheus --storage.tsdb.retention.time=7d

Проблема 3: Масштабирование на несколько кластеров

Для мониторинга нескольких кластеров или датацентров используется федерация (federation):

textscrape_configs:
  - job_name: 'federate'
    scrape_interval: 1m
    scrape_timeout: 30s
    honor_labels: true
    metrics_path: '/federate'
    params:
      'match[]':
        - '{job="prometheus"}'
        - '{__name__=~"job:.*"}'
    static_configs:
      - targets:
          - 'prometheus-dc1:9090'
          - 'prometheus-dc2:9090'

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

Решение 4: Remote Storage для долгосрочного хранения

Prometheus локальное хранилище оптимизировано для краткосрочного хранения (по умолчанию 15 дней). Для долгосрочного хранения используется remote storage:

Thanos: добавляет глобальный запрос, неограниченное retention и downsampling
VictoriaMetrics: альтернативная TSDB с лучшей сжимаемостью
Cortex: полнофункциональное распределенное решение

textremote_write:
  - url: http://victoriametrics:8428/api/v1/write
    queue_config:
      capacity: 100000
      max_shards: 100
      max_samples_per_send: 10000

Безопасность Prometheus

При развертывании Prometheus в production необходимо позаботиться о безопасности.

Аутентификация и шифрование

Prometheus поддерживает HTTPS и базовую аутентификацию. Конфигурация:

textglobal:
  external_labels:
    cluster: 'production'

scrape_configs:
  - job_name: 'secure-target'
    scheme: https
    tls_config:
      ca_file: /etc/prometheus/ca.crt
      cert_file: /etc/prometheus/client.crt
      key_file: /etc/prometheus/client.key
    basic_auth:
      username: 'prometheus'
      password: 'secure-password'

Изоляция данных

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

textglobal:
  external_labels:
    environment: 'production'
    cluster: 'main'
    region: 'eu-west-1'

Access Control

Для управления доступом к Prometheus UI используйте обратный прокси (nginx, Apache):

textlocation /prometheus/ {
    auth_basic "Prometheus";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://prometheus:9090/;
}

Оптимизация производительности: Практические советы

1. Правильный scrape_interval

Не устанавливайте слишком короткий интервал. Стандартные 15-30 секунд подходят для большинства случаев:

textscrape_configs:
  - job_name: 'critical-services'
    scrape_interval: 15s
  
  - job_name: 'infrastructure'
    scrape_interval: 30s
  
  - job_name: 'batch-systems'
    scrape_interval: 2m

2. Использование Recording Rules

Предвычисляйте часто используемые выражения:

textgroups:
  - name: optimization_rules
    interval: 1m
    rules:
      - record: node:cpu_usage:sum_rate1m
        expr: sum by (job) (rate(node_cpu_seconds_total[1m]))
      
      - record: instance:memory_usage_percent
        expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

3. Оптимальное использование TSDB

Конфигурируйте параметры TSDB:

bash./prometheus \
  --storage.tsdb.retention.time=30d \
  --storage.tsdb.retention.size=50GB \
  --storage.tsdb.wal-compression=true \
  --storage.tsdb.min-block-duration=2h \
  --storage.tsdb.max-block-duration=2h

Параметры:

  • retention.time: как долго хранить данные
  • retention.size: максимальный размер данных на диске
  • wal-compression: сжимать логи операций (снижает I/O, повышает CPU)
  • block-duration: размер блоков (меньше = чаще компактизация, но лучше запросы)

4. Эффективные запросы

Используйте точные фильтры вместо регулярных выражений:

text# Хорошо
rate(http_requests_total{job="api"}[5m])

# Плохо (полный скан)
rate(http_requests_total{job=~".*api.*"}[5m])

Ограничивайте временные окна для больших датасетов:

text# Хорошо
rate(http_requests_total[5m])

# Плохо (полный месяц)
rate(http_requests_total[30d])

Интеграция с Grafana

Grafana — визуализационная платформа, которая превосходно интегрируется с Prometheus. Процесс настройки простой:

  1. Добавьте Data Source в Grafana, указав URL Prometheus (обычно http://prometheus:9090)
  2. Создайте панели с PromQL запросами
  3. Используйте переменные для динамических дашбордов:
text{
  "templating": {
    "list": [
      {
        "name": "job",
        "type": "query",
        "datasource": "Prometheus",
        "query": "label_values(up, job)"
      },
      {
        "name": "instance",
        "type": "query",
        "datasource": "Prometheus",
        "query": "label_values(up{job=\"$job\"}, instance)"
      }
    ]
  }
}

В Grafana комьюнити существует множество готовых дашбордов для популярных систем: Node Exporter Full, PostgreSQL, Redis, Kubernetes и многих других.

Проблемы и их решение: Справочник

Проблема: Prometheus потребляет слишком много памяти

Причины могут быть:

  1. Взрыв кардинальности — найдите проблемные метрики через /tsdb-status
  2. Слишком длинный retention period
  3. Слишком много активных временных рядов

Решение:

  • Уменьшите retention_time
  • Используйте metric_relabel_configs для отбрасывания ненужных метрик
  • Проверьте лейблы на высокую кардинальность

Проблема: Медленные запросы

Причины:

  1. Слишком сложные выражения
  2. Слишком большие временные окна
  3. Неэффективные функции

Решение:

  • Используйте recording rules для предвычисления сложных выражений
  • Уменьшите временной диапазон
  • Используйте rate() вместо irate() для сглаживания

Проблема: Потеря данных при перезагрузке

Решение: используйте remote_write для дублирования данных:

textremote_write:
  - url: http://backup-prometheus:9009/api/v1/write

Проблема: Контроль версий конфигурации

Лучшая практика — хранить конфигурацию в Git:

bash# Валидация перед коммитом
./promtool check config prometheus.yml
./promtool check rules rules/*.yml

# Динамическая перезагрузка конфигурации
curl -X POST http://localhost:9090/-/reload

Развертывание в production: Пошаговая инструкция

Шаг 1: Установка

bash# Загрузка
wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz

# Распаковка
tar xvfz prometheus-2.47.0.linux-amd64.tar.gz
cd prometheus-2.47.0.linux-amd64

# Создание systemd сервиса
sudo useradd --no-create-home --shell /bin/false prometheus
sudo mkdir -p /etc/prometheus /var/lib/prometheus
sudo cp prometheus promtool /usr/local/bin/

Шаг 2: Конфигурация

text# /etc/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    environment: 'production'
    cluster: 'main'

rule_files:
  - '/etc/prometheus/rules/*.yml'

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
  
  - job_name: 'nodes'
    static_configs:
      - targets: ['node1:9100', 'node2:9100']

Шаг 3: Запуск как сервис

text# /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \
  --config.file /etc/prometheus/prometheus.yml \
  --storage.tsdb.path /var/lib/prometheus \
  --storage.tsdb.retention.time=30d
Restart=always

[Install]
WantedBy=multi-user.target

bashsudo systemctl daemon-reload
sudo systemctl enable prometheus
sudo systemctl start prometheus

Шаг 4: Интеграция с Alertmanager

text# /etc/prometheus/prometheus.yml
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']

rule_files:
  - '/etc/prometheus/rules/alerts.yml'

Инструменты для управления Prometheus

promtool

Утилита для валидации конфигурации и правил:

bash# Проверка синтаксиса конфигурации
promtool check config prometheus.yml

# Проверка правил алертов
promtool check rules rules/alerts.yml

# Тестирование выражений PromQL
promtool query instant 'up{job="prometheus"}'

API Prometheus

Prometheus предоставляет HTTP API для программного доступа:

bash# Текущее значение метрики
curl 'http://localhost:9090/api/v1/query?query=up'

# Диапазон значений
curl 'http://localhost:9090/api/v1/query_range?query=up&start=1677600000&end=1677700000&step=60'

# Доступные метрики
curl 'http://localhost:9090/api/v1/label/__name__/values'

# Доступные значения лейбла
curl 'http://localhost:9090/api/v1/label/job/values'

Клиентские библиотеки Prometheus

Для инструментирования собственного приложения используются клиентские библиотеки:

Go

goimport "github.com/prometheus/client_golang/prometheus"

httpRequestsTotal := prometheus.NewCounterVec(
    prometheus.CounterOpts{
        Name: "http_requests_total",
        Help: "Total HTTP requests",
    },
    []string{"method", "endpoint"},
)

httpRequestsTotal.WithLabelValues("GET", "/api/users").Inc()

Python

pythonfrom prometheus_client import Counter, Histogram

requests_total = Counter(
    'http_requests_total',
    'Total HTTP requests',
    ['method', 'endpoint']
)

request_duration = Histogram(
    'http_request_duration_seconds',
    'HTTP request duration',
    buckets=(0.01, 0.05, 0.1, 0.5, 1, 5)
)

requests_total.labels(method='GET', endpoint='/api').inc()

with request_duration.time():
    # Выполнить запрос
    pass

Java

javaimport io.prometheus.client.Counter;
import io.prometheus.client.Histogram;

static final Counter requests = Counter.build()
    .name("http_requests_total")
    .help("Total HTTP requests")
    .labelNames("method", "endpoint")
    .register();

static final Histogram duration = Histogram.build()
    .name("http_request_duration_seconds")
    .help("HTTP request duration")
    .register();

requests.labels("GET", "/api").inc();

Чек-лист для успешной реализации Prometheus

При развертывании мониторинга на Prometheus следуйте этому чек-листу:

Планирование и проектирование:

  •  Определены все критические метрики для бизнеса
  •  Спроектирована иерархия лейблов
  •  Определены SLO и SLA для приложений
  •  Рассчитаны требования к ресурсам Prometheus

Инструментирование приложений:

  •  Интегрированы клиентские библиотеки
  •  Определены счетчики для ключевых событий
  •  Определены гистограммы для латентности
  •  Избегнуты высококардинальные лейблы

Конфигурация Prometheus:

  •  Настроены все scrape_configs с правильными интервалами
  •  Созданы recording rules для оптимизации
  •  Настроены alerting rules с правильными условиями
  •  Настроен Alertmanager с правильной маршрутизацией
  •  Интегрированы экспортеры для инфраструктуры

Мониторинг самого Prometheus:

  •  Настроены алерты на высокое использование памяти
  •  Настроены алерты на высокую кардинальность
  •  Настроены алерты на проблемы с диском
  •  Настроены алерты на недоступность целей скрейпинга

Интеграция с Grafana:

  •  Добавлен Prometheus как Data Source
  •  Созданы основные дашборды
  •  Импортированы готовые дашборды из сообщества
  •  Настроены переменные для динамических фильтров

Тестирование и оптимизация:

  •  Протестированы все алерты
  •  Проверена производительность запросов
  •  Оптимизирована кардинальность метрик
  •  Настроено резервное копирование конфигурации

Документирование:

  •  Задокументированы все кастомные метрики
  •  Задокументированы правила алертов
  •  Создано руководство по устранению неполадок
  •  Задокументирована процедура масштабирования

Заключение

Prometheus — мощная и гибкая система мониторинга, которая стала стандартом в мире cloud-native приложений. Ее успех обусловлен простотой установки, эффективностью хранения данных и мощным языком запросов PromQL.

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

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

Мир DevOps и SRE-инженерии становится все сложнее, но с правильными инструментами мониторинга, такими как Prometheus, управление этой сложностью становится более управляемым и предсказуемым.

Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *