Результаты обучения.

• Знать: архитектуру Prometheus (pull-модель, экспортёры, TSDB), типы метрик (Gauge, Counter, Summary, Histogram), синтаксис PromQL для фильтрации и агрегации, структуру конфигурации (prometheus.yml).
• Уметь: устанавливать и запускать Prometheus, Alertmanager, Grafana и ключевые экспортёры (Node, Redis, PostgreSQL); писать запросы PromQL (rate, sum by, histogram_quantile); настраивать алерты и визуализацию; защищать мониторинг с помощью базовой аутентификации и HTTPS через reverse proxy.
• Владеть: методикой автоматического обнаружения целей (file_sd_config, DNS SRV records), практикой записи метрик по push-модели (Pushgateway), основами федерации и долгосрочного хранения (remote_write/remote_read через TimescaleDB).

Архитектура Prometheus: pull-модель, экспортёры и TSDB.

В основе Prometheus лежит архитектура, кардинально отличающаяся от классических систем мониторинга (Zabbix, Nagios). Вместо «пуша» (агент сам отправляет данные) Prometheus использует pull-модель — он сам периодически «вытягивает» метрики с настроенных целей (targets) по протоколу HTTP. Основные компоненты архитектуры:

• Prometheus server — центральный компонент, который опрашивает экспортёры, сохраняет метрики в TSDB (time series database) на диске и предоставляет веб-интерфейс и API для запросов PromQL.
• Exporters — специальные прокси-агенты, которые подключаются к конкретным сервисам (ОС, БД, веб-серверам), собирают с них метрики через их собственные интерфейсы и отдают их в формате, понятном Prometheus (endpoint /metrics).
• Alertmanager — компонент для маршрутизации, группировки и отправки алертов в каналы нотификации (Slack, PagerDuty, email). Prometheus генерирует алерты, но отправляет их не напрямую, а в Alertmanager.
• Service Discovery — механизм автоматического нахождения целей для мониторинга (file-based, Consul, Kubernetes, EC2). Ключевая фича для динамических облачных инфраструктур.

Почему pull-модель? Она упрощает обнаружение сервисов, не требует открытия дополнительных портов наружу и централизует управление конфигурацией. Именно поэтому Prometheus стал стандартом для Kubernetes и облачных сред.

Установка Prometheus: бинарный способ + systemd сервис.

Prometheus распространяется как статически скомпилированный бинарный файл (написан на Go), что делает установку максимально простой — не нужны зависимости или интерпретаторы. Пошаговый процесс (на примере Ubuntu/Debian):

1. Скачивание: перейдите на страницу загрузки (prometheus.io/download) и скопируйте ссылку на последнюю версию для Linux amd64. В терминале:

   cd /opt
   wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz
   tar -xvf prometheus-2.45.0.linux-amd64.tar.gz
   mv prometheus-2.45.0.linux-amd64 prometheus

2. Создание пользователя и файлов:

   useradd --no-create-home --shell /bin/false prometheus
   chown -R prometheus:prometheus /opt/prometheus

3. systemd unit: создайте файл /etc/systemd/system/prometheus.service со следующим содержимым:

   [Unit]
   Description=Prometheus
   After=network.target
   
   [Service]
   User=prometheus
   Group=prometheus
   ExecStart=/opt/prometheus/prometheus --config.file=/opt/prometheus/prometheus.yml --storage.tsdb.path=/opt/prometheus/data
   
   [Install]
   WantedBy=multi-user.target

   Важные флаги: --config.file — путь к конфигурации, --storage.tsdb.path — куда сохранять временные ряды (TSDB).
4. Запуск и проверка:

   systemctl daemon-reload
   systemctl start prometheus
   systemctl enable prometheus
   systemctl status prometheus

   После запуска веб-интерфейс будет доступен на порту 9090 (http://ваш-сервер:9090).

Совет: В продакшене всегда используйте systemd (или аналогичную систему инициализации), чтобы Prometheus автоматически перезапускался при сбое и стартовал при загрузке ОС.

Конфигурация prometheus.yml: глобальные параметры, scrape и rule files.

Главный конфигурационный файл Prometheus — prometheus.yml. Он написан в формате YAML и состоит из четырёх основных блоков:

1. global: параметры, действующие по умолчанию для всех целей. Ключевые: scrape_interval — как часто опрашивать цели (по умолчанию 15 секунд), evaluation_interval — как часто вычислять правила алертинга и рекординга (тоже 15 секунд).
2. alerting: настройки подключения к Alertmanager (список его эндпоинтов).
3. rule_files: список файлов, содержащих правила записи (recording rules) и правила алертов (alerting rules). Prometheus будет периодически загружать их и применять.
4. scrape_configs: самая важная секция — описание целей (jobs) для мониторинга. Каждый job имеет имя (job_name) и список таргетов. Самый простой способ — static_configs, где вы вручную перечисляете адреса и порты целей. Пример:

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

Prometheus по умолчанию ожидает, что цель будет отдавать метрики по пути /metrics. Вы также можете указать путь явно через metrics_path. Важный совет: всегда проверяйте конфигурацию перед перезапуском с помощью утилиты promtool:

./promtool check config prometheus.yml

Интерфейс и базовые метрики: Status, Targets, Graph.

После запуска откройте веб-интерфейс Prometheus на порту 9090. Вы увидите несколько вкладок:

• Graph — главная вкладка для выполнения запросов PromQL и просмотра графиков (таблицы). Здесь вы можете вводить выражения (например, prometheus_target_interval_length_seconds) и переключаться между режимами отображения: таблица или график.
• Alerts — отображает текущее состояние всех определённых алертов (inactive, pending, firing).
• Status → Targets — одна из самых важных страниц. Здесь вы видите все настроенные цели, их состояние (UP — успешно опрашивается, DOWN — недоступна), время последнего опроса, ошибки (если есть). Это первое место для диагностики при проблемах со сбором метрик.
• Status → Configuration — показывает текущую загруженную конфигурацию (фактически, prometheus.yml) в удобном для чтения виде.
• Status → Runtime & Build Information — техническая информация о версии, времени работы и ключевых параметрах (например, флаг storage.tsdb.retention.time).

Как проверить, что цель работает: перейдите в Status → Targets, найдите нужный job. Если статус UP — всё хорошо. Если DOWN — проверьте, доступен ли эндпоинт /metrics с помощью curl или браузера.

Node Exporter: мониторинг ОС Linux (CPU, память, диск, сеть).

Первый и самый базовый экспортёр, который вы должны запустить на каждой серверной ноде. Node Exporter собирает метрики операционной системы: загрузку CPU, использование памяти, дисковое пространство, сетевой трафик, количество открытых файлов, нагрузку (load average) и многое другое — около 500 метрик по умолчанию. Он работает как отдельный процесс и отдаёт метрики в формате Prometheus на порту 9100 по пути /metrics.

Установка и запуск:

cd /opt
wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz
tar -xvf node_exporter-1.6.0.linux-amd64.tar.gz
sudo mv node_exporter-1.6.0.linux-amd64/node_exporter /usr/local/bin/

[Unit]
Description=Node Exporter
After=network.target

[Service]
User=node_exporter
Group=node_exporter
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=multi-user.target

sudo useradd --no-create-home --shell /bin/false node_exporter
sudo systemctl daemon-reload
sudo systemctl start node_exporter
sudo systemctl enable node_exporter

Подключение к Prometheus: Добавьте в scrape_configs вашего prometheus.yml:

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

Важно: Node Exporter имеет множество коллекторов (модулей), которые можно включать/выключать флагами. Например, для отключения сетевых метрик используйте --no-collector.netstat. В учебных целях оставляйте всё включенным.

redis_exporter: мониторинг Redis (команды, память, подключения).

redis_exporter — экспортёр для мониторинга серверов Redis. Он подключается к Redis через TCP, выполняет команду INFO (и другие, если настроено), парсит вывод и преобразует его в метрики Prometheus. Доступные метрики: количество выполненных команд (redis_commands_total), использованная память (redis_memory_used_bytes), количество подключений (redis_connected_clients), состояние репликации и многое другое.

Установка и запуск:

cd /opt
wget https://github.com/oliver006/redis_exporter/releases/download/v1.53.0/redis_exporter-v1.53.0.linux-amd64.tar.gz
tar -xvf redis_exporter-v1.53.0.linux-amd64.tar.gz
sudo mv redis_exporter /usr/local/bin/

redis_exporter &

Подключение к Prometheus:

- job_name: 'redis'
  static_configs:
    - targets: ['localhost:9121']
  # если используете пароль, его нужно передать через параметры экспортёра, а не через labels

Совет: Если Redis использует пароль или запущен не на стандартном порту, запускайте экспортёр с флагами: redis_exporter --redis.addr=myredis:6380 --redis.password='mypass'. В production всегда запускайте экспортёр на той же ноде, что и Redis, чтобы избежать сетевых проблем.

postgres_exporter: мониторинг PostgreSQL (активность, статистика таблиц).

postgres_exporter собирает метрики из PostgreSQL. Он подключается к базе данных через lib/pq (драйвер для Go) и выполняет SQL-запросы к системным таблицам (pg_stat_database, pg_stat_bgwriter, pg_stat_user_tables и др.). Метрики: количество активных подключений, размер баз данных, количество транзакций, процент «устаревших» записей (bloat), задержки репликации и т.д.

Установка и настройка:

cd /opt
wget https://github.com/prometheus-community/postgres_exporter/releases/download/v0.13.0/postgres_exporter-0.13.0.linux-amd64.tar.gz
tar -xvf postgres_exporter-0.13.0.linux-amd64.tar.gz
sudo mv postgres_exporter /usr/local/bin/

CREATE USER prometheus WITH PASSWORD 'prom_password';
GRANT pg_monitor TO prometheus;  -- для версий PostgreSQL >= 10
-- или GRANT SELECT ON pg_stat_database, pg_stat_bgwriter, ... для старых версий

export DATA_SOURCE_NAME="postgresql://prometheus:prom_password@localhost:5432/postgres?sslmode=disable"
postgres_exporter &

Подключение к Prometheus:

- job_name: 'postgres'
  static_configs:
    - targets: ['localhost:9187']
  # рекомендуем добавить метку окружения
  labels:
    env: 'production'

Важно: postgres_exporter поддерживает пользовательские запросы через файл queries.yaml — вы можете добавлять свои метрики, специфичные для вашего приложения.

Инструментация приложения на Go: добавление клиентской библиотеки promhttp.

Чтобы мониторить ваше собственное приложение, а не только системные сервисы, нужно добавить в код экспорт метрик. Prometheus предоставляет официальные клиентские библиотеки для большинства языков (Go, Python, Java, Ruby, Rust). Рассмотрим пример на Go — простейший HTTP-сервер, который считает количество запросов и измеряет их длительность с помощью Summary.

Шаг 1: импорт библиотек

import (
    "net/http"
    "time"
    "math/rand"
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

Шаг 2: определение метрик

var (
    // Counter: количество запросов (только растёт)
    totalRequests = prometheus.NewCounterVec(
        prometheus.CounterOpts{
            Name: "app_requests_total",
            Help: "Total number of requests.",
        },
        []string{"method"},
    )
    // Summary: время ответа с квантилями (p50, p90, p99)
    requestDuration = prometheus.NewSummaryVec(
        prometheus.SummaryOpts{
            Name:       "app_request_duration_seconds",
            Help:       "Request duration in seconds.",
            Objectives: map[float64]float64{0.5: 0.05, 0.9: 0.01, 0.99: 0.001},
        },
        []string{"method"},
    )
)

Шаг 3: регистрация метрик и экспорт эндпоинта

func init() {
    prometheus.MustRegister(totalRequests, requestDuration)
}

func main() {
    http.Handle("/metrics", promhttp.Handler())
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8080", nil)
}

Шаг 4: увеличение счётчика и измерение времени внутри обработчика

func handler(w http.ResponseWriter, r *http.Request) {
    start := time.Now()
    totalRequests.WithLabelValues(r.Method).Inc()
    
    // симуляция работы
    time.Sleep(time.Duration(rand.Intn(2000)) * time.Millisecond)
    
    duration := time.Since(start).Seconds()
    requestDuration.WithLabelValues(r.Method).Observe(duration)
    w.WriteHeader(http.StatusOK)
    w.Write([]byte("OK"))
}

После компиляции и запуска на порту 8080 эндпоинт /metrics будет отдавать метрики в формате Prometheus. Добавьте этот таргет в prometheus.yml, и вы сможете видеть графики app_requests_total и квантили времени ответа.

Типы метрик в Prometheus: Counter, Gauge, Summary, Histogram.

Понимание типов метрик критически важно для правильного использования PromQL. Каждый тип предназначен для определённых сценариев:

1. Counter — монотонно возрастающее значение (может сброситься только при перезапуске). Используется для подсчёта событий: количество запросов, ошибок, выполненных задач. В PromQL к ним почти всегда применяется функция rate() или irate() для получения частоты событий в секунду. Пример: http_requests_total.
2. Gauge — значение, которое может произвольно увеличиваться и уменьшаться. Используется для метрик состояния: температура, использование памяти, количество активных подключений. К ним применяют агрегацию (avg, min, max), но не rate. Пример: go_memstats_alloc_bytes.
3. Summary — считает квантили (процентили) на стороне клиента (в вашем приложении). Позволяет узнать, какое время выполнения запроса у 90%, 95%, 99% запросов. Не требует дополнительных вычислений на сервере Prometheus, но квантили фиксированы в коде. Пример: request_duration_seconds{quantile="0.95"}.
4. Histogram — аналогичен Summary, но квантили вычисляются на стороне сервера Prometheus с помощью функции histogram_quantile(). Это более гибко (можно запросить любой квантиль), но требует больше ресурсов. Состоит из _bucket (счётчики запросов, попавших в определённые интервалы), _sum и _count. Пример: prometheus_tsdb_compaction_duration_seconds_bucket.

Правило выбора: Для простоты начинайте с Counter и Gauge. Если нужно знать распределение (например, 99% запросов быстрые, а 1% — очень медленные), используйте Histogram (на сервере Prometheus) или Summary (в приложении).

Обработка метрик: функции rate, irate, increase, delta.

PromQL предоставляет мощные функции для анализа временных рядов. Самые важные:

• rate(v range-vector) — вычисляет среднюю скорость роста per second для counter за указанный временной интервал. Идеально для метрик типа «запросы в секунду». Пример: rate(http_requests_total[5m]) — среднее количество запросов в секунду за последние 5 минут. Устойчив к выбросам и повторным перезапускам.
• irate(v range-vector) — вычисляет мгновенную скорость роста, используя последние две точки выборки. Лучше подходит для быстро меняющихся данных, но более чувствителен к шуму. Пример: irate(node_network_receive_bytes_total[5m]) — текущая скорость приёма байт на интерфейсе.
• increase(v range-vector) — возвращает общий прирост counter за указанный интервал. Фактически, rate * количество_секунд_в_интервале. Пример: increase(http_requests_total[1h]) — сколько запросов пришло за последний час.
• delta(v range-vector) — работает с gauge и показывает разницу между последним и первым значением за интервал. Пример: delta(temperature_celsius[1h]) — на сколько градусов изменилась температура за час (может быть отрицательной).

Важно: Все эти функции требуют range-vector в качестве аргумента, то есть метрику нужно указывать с [интервалом], например my_metric[5m]. Без интервала вы получите ошибку. Применяйте rate и irate только к counter — применение к gauge даст бессмысленный результат.

Автоматическое обнаружение целей: file_sd_config и DNS SRV записи.

Когда ваша инфраструктура динамически меняется (добавляются/удаляются сервера, переезжают контейнеры), ручное добавление таргетов в static_configs становится неэффективным. На помощь приходят механизмы service discovery. Два самых универсальных:

1. file_sd_config — позволяет загружать список таргетов из JSON или YAML файлов. Prometheus периодически перечитывает эти файлы (по умолчанию каждые 5 минут). Вы можете написать скрипт на любом языке (Python, Bash), который будет опрашивать ваш инвентарь (CMDB, облачное API) и обновлять файл с целями. Пример конфигурации:

   - job_name: 'file_sd'
     file_sd_configs:
       - files:
         - '/opt/prometheus/targets/*.json'
         refresh_interval: 10s

   Формат JSON файла:

   [{"targets": ["10.0.0.1:9100"], "labels": {"env": "prod"}}]

2. DNS SRV records — если в вашей компании используется DNS для именования сервисов (например, _prometheus-http._tcp.example.com), Prometheus может напрямую опрашивать DNS и получать список A/AAAA записей. Пример конфигурации:

   - job_name: 'dns_sd'
     dns_sd_configs:
       - names:
         - '_prometheus._tcp.example.com'
         type: 'SRV'
         port: 9100

   Prometheus найдёт все SRV записи, извлечёт из них целевые адреса и порты (если указаны) и начнёт их опрашивать.

Выбор метода: file_sd_config — самый гибкий, подходит для любых нестандартных источников (самописные инвентари). DNS SRV — отличный выбор, если у вас уже есть развитая DNS-инфраструктура и сервисы регистрируются в ней.

Federation: сбор метрик с нескольких серверов Prometheus.

Federation (федерация) позволяет одному серверу Prometheus («глобальному») собирать метрики с других серверов Prometheus («локальных»). Это необходимо в иерархических инфраструктурах: в каждом дата-центре или кластере Kubernetes работает свой Prometheus, собирающий детальные метрики. Глобальный Prometheus опрашивает их и хранит агрегированные данные (например, суммарное количество запросов по всем ДЦ).

Как настроить:

1. На локальном Prometheus (который будет отдавать метрики) нужно разрешить доступ к эндпоинту /federate и опционально ограничить передаваемые метрики через параметр --web.enable-admin-api (не требуется для базовой федерации). Конфигурация локального сервера не меняется, он просто отдаёт метрики как обычно.
2. На глобальном сервере нужно добавить job с типом federate, который будет опрашивать эндпоинт /federate локального Prometheus и передавать ему параметр match[] — список метрик, которые мы хотим собирать. Важно: никогда не пытайтесь собрать все метрики с локального сервера — это вызовет проблемы с масштабируемостью. Забирайте только агрегированные данные (recording rules). Пример конфигурации глобального Prometheus:

   - job_name: 'federate'
     scrape_interval: 15s
     honor_labels: true
     metrics_path: '/federate'
     params:
       'match[]':
         - '{__name__=~"job:.*"}'  # собираем только recording rules, которые начинаются с 'job:'
     static_configs:
       - targets:
         - 'prometheus-dc1:9090'
         - 'prometheus-dc2:9090'

Важные флаги: honor_labels: true сохраняет оригинальные метки с локального сервера, не перезаписывая их метками глобального. Параметр match[] поддерживает регулярные выражения. Настоятельно рекомендуется использовать recording rules для предварительной агрегации данных на локальных серверах и забирать только их.

Long-Term Storage: remote_write/remote_read и TimescaleDB.

По умолчанию Prometheus хранит данные на локальном диске (TSDB). Это быстро, но не масштабируемо и не надёжно: вы не можете кластеризовать Prometheus из коробки, а время хранения ограничено (по умолчанию 15 дней, можно увеличить флагом --storage.tsdb.retention.time). Для долгосрочного хранения (месяцы, годы) и централизованного анализа метрик со всех серверов используется remote storage через протоколы remote_write и remote_read.

Как это работает: Prometheus продолжает работать как обычно (pull), но дополнительно, с заданной периодичностью, отправляет копию метрик (обычно после агрегации или без неё) во внешнюю систему через remote_write. При запросах PromQL, если данные отсутствуют в локальной TSDB, Prometheus может обратиться к внешнему хранилищу через remote_read.

Пример настройки для TimescaleDB (PostgreSQL + расширение timescaledb):

1. Установите TimescaleDB и создайте базу данных metrics.
2. Скачайте и запустите адаптер prometheus-timescale-adapter (или remote_storage_adapter для Prometheus).
3. В prometheus.yml добавьте блок:

   remote_write:
     - url: "http://localhost:9201/write"
   remote_read:
     - url: "http://localhost:9201/read"

Альтернативы: VictoriaMetrics (популярная замена Prometheus с поддержкой кластеризации), Thanos (обёртка вокруг Prometheus, добавляющая глобальный взгляд и долгосрочное хранение в S3), Cortex (горизонтально масштабируемый Prometheus). Для небольших проектов можно просто увеличить retention.time до 30-90 дней, но для корпоративных масштабов используйте remote storage или Thanos.

Grafana: установка, подключение Prometheus как Data Source, импорт дашбордов.

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

Установка на Ubuntu/Debian:

sudo apt-get install -y software-properties-common
sudo add-apt-repository "deb https://packages.grafana.com/oss/deb stable main"
wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -
sudo apt-get update
sudo apt-get install -y grafana
sudo systemctl daemon-reload
sudo systemctl start grafana-server
sudo systemctl enable grafana-server

Подключение Prometheus как Data Source: Зайдите в Grafana → Configuration → Data Sources → Add data source → выберите Prometheus. Укажите URL вашего Prometheus (например, http://localhost:9090), нажмите Save & Test. Должно появиться сообщение «Data source is working».

Импорт готового дашборда: Перейдите в Create → Import. В поле Grafana.com Dashboard ID или URL введите ID дашборда (например, для Node Exporter — 1860, для Redis — 763). Нажмите Load, выберите ваш Data Source (Prometheus) и нажмите Import. Готовый дашборд с множеством панелей появится в разделе Dashboards.

Создание собственной панели: Create → Dashboard → Add new panel. В поле запроса введите PromQL выражение (например, rate(node_cpu_seconds_total{mode="user"}[5m])). Настройте визуализацию (график, столбцы, таблицу). Сохраните дашборд.

Alertmanager: группировка, подавление и маршрутизация уведомлений.

Alertmanager — компонент, который принимает алерты от Prometheus, дедуплицирует их, группирует, подавляет (inhibit) и отправляет в конечные каналы уведомлений (Slack, PagerDuty, email, webhook). Prometheus генерирует алерт как firing (условие выполнено), но не отправляет его напрямую. Вместо этого он периодически отправляет список всех активных алертов в Alertmanager, который уже решает, кому и как уведомлять.

Базовая конфигурация Alertmanager (alertmanager.yml):

route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'slack'
receivers:
- name: 'slack'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/...'
    channel: '#alerts'
    title: '{{ .GroupLabels.alertname }}'
    text: '{{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}'

Подключение Alertmanager к Prometheus: В prometheus.yml добавьте секцию:

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

Совет: Всегда настраивайте repeat_interval не слишком коротким (минимум час), иначе вы заспамите каналы. Для критичных проблем лучше использовать PagerDuty с эскалацией, а не просто повторяющиеся сообщения.

Создание алертов в Prometheus: синтаксис rules и best practices.

Алерты в Prometheus определяются в rule files (файлах правил) вместе с recording rules. Каждый алерт — это запрос PromQL, который выполняется каждые evaluation_interval (обычно 15 секунд). Если запрос возвращает хотя бы одну серию данных (проверка истинна), алерт переходит в состояние pending. Если он остаётся истинным в течение for (например, 1 минуту), он становится firing и отправляется в Alertmanager.

Пример rule file (alerts.yml):

groups:
- name: instance_down
  rules:
  - alert: InstanceDown
    expr: up == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minute."

Обязательные поля:

• alert — название алерта (например, InstanceDown).
• expr — выражение PromQL, которое при истинности срабатывает. Важно: выражение должно возвращать непустой вектор.
• for — время (в секундах/минутах), в течение которого выражение должно быть истинно, прежде чем алерт перейдёт в firing. Избавляет от ложных срабатываний на кратковременных пиках.
• labels — добавляет/переопределяет метки к алерту (например, severity). Alertmanager использует метки для маршрутизации.
• annotations — информационные поля (summary, description), которые будут отправлены в уведомление. Здесь можно использовать шаблонизацию: {{ $labels.instance }} — значение метки instance.

Best practices: Всегда добавляйте for для алертов, чувствительных к кратковременным флуктуациям. Не создавайте алерты на «среднее значение CPU» — используйте перцентили или конкретные пороговые значения. Хороший алерт должен требовать действия человека; если действие можно автоматизировать, автоматизируйте его и удалите алерт. Используйте severity: critical (ночной звонок), warning (только в рабочие часы), info (только в чат).

Проверка правил: Используйте promtool check rules alerts.yml.

Pushgateway: отправка метрик от batch-задач (cron, CI/CD).

Prometheus работает по pull-модели — он сам опрашивает цели. Но что делать с задачами, которые живут не постоянно, а запускаются периодически? Например, cron-скрипт, который парсит логи раз в час и считает статистику, или pipeline CI/CD, который должен сообщить результат выполнения. Prometheus не сможет «увидеть» такую задачу — она уже завершилась к моменту опроса. Решение — Pushgateway.

Pushgateway — это промежуточный сервис, который принимает метрики по HTTP-запросам (push) и хранит их в своей памяти. Prometheus затем опрашивает Pushgateway (pull) как обычную цель и забирает накопленные метрики. Pushgateway не предназначен для хранения большого количества метрик от постоянно работающих сервисов — только для короткоживущих batch-задач.

Установка и запуск:

cd /opt
wget https://github.com/prometheus/pushgateway/releases/download/v1.6.0/pushgateway-1.6.0.linux-amd64.tar.gz
tar -xvf pushgateway-1.6.0.linux-amd64.tar.gz
sudo mv pushgateway-1.6.0.linux-amd64/pushgateway /usr/local/bin/
sudo useradd --no-create-home --shell /bin/false pushgateway
# создайте systemd unit аналогично Node Exporter

Отправка метрик в Pushgateway из скрипта (Bash):

#!/bin/bash
# ... логика скрипта ...
echo "my_batch_job_duration_seconds 42.5" | curl --data-binary @- http://localhost:9091/metrics/job/my_batch_job
echo "my_batch_job_success 1" | curl --data-binary @- http://localhost:9091/metrics/job/my_batch_job/instance/$(hostname)

Подключение к Prometheus: Просто добавьте таргет Pushgateway в scrape_configs:

- job_name: 'pushgateway'
  static_configs:
    - targets: ['localhost:9091']
  honor_labels: true  # не перезаписывать метки job/instance, переданные клиентом

Важное ограничение: Pushgateway — это не долговременное хранилище. Метрики удаляются при удалении группы заданий или при перезапуске Pushgateway. Никогда не используйте его для серверных метрик (CPU, память) — для этого есть экспортёры.

Мониторинг самого Prometheus: встроенные метрики и дашборды.

Prometheus собирает метрики о своей собственной работе и отдаёт их по стандартному пути /metrics. Это обязательный минимум для контроля за системой мониторинга. Ключевые метрики, на которые стоит обращать внимание:

• prometheus_tsdb_head_samples_appended_total — общее количество добавленных сэмплов в TSDB. Позволяет оценить нагрузку.
• prometheus_tsdb_compactions_total — количество компактизаций TSDB. Частые компактизации могут указывать на проблемы с диском.
• prometheus_target_scrape_pool_exceeded_total — если этот счётчик растёт, значит scrapers (потоки опроса) не справляются с нагрузкой, нужно увеличивать scrape_interval или количество воркеров (флаг --storage.tsdb.max-block-duration).
• prometheus_rule_evaluation_failures_total — ошибки при вычислении правил (обычно из-за синтаксических ошибок или таймаутов).
• prometheus_engine_query_duration_seconds{quantile="0.99"} — время выполнения самых медленных запросов PromQL. Если превышает несколько секунд, возможно, вы пытаетесь агрегировать слишком много данных (нужны recording rules или remote storage).

Готовые дашборды для Prometheus в Grafana: Импортируйте дашборд с ID 3662 («Prometheus 2.0 Stats») или 11835 («Prometheus Remote Write»). Они покажут количество сэмплов в секунду, использование TSDB, задержки опроса и другие ключевые показатели. Настройте алерт на метрику prometheus_target_scrape_pool_exceeded_total с порогом > 0, чтобы вовремя узнать о перегрузке самого Prometheus.

Reverse proxy (NGINX) + Basic Auth: защита Prometheus от внешнего доступа.

По умолчанию Prometheus не имеет встроенной аутентификации — любой, кто имеет доступ к порту 9090, может выполнять запросы PromQL. В production это недопустимо. Стандартное решение — спрятать Prometheus за обратным прокси (reverse proxy) с базовой аутентификацией (Basic Auth) и, желательно, HTTPS.

Схема: Prometheus слушает только на localhost:9090 (флаг --web.listen-address=127.0.0.1:9090). NGINX принимает внешние запросы на порту 80/443, проверяет логин/пароль (Basic Auth) и проксирует запросы к внутреннему порту 9090.

Настройка NGINX:

1. Сгенерируйте файл паролей:

   sudo apt-get install apache2-utils
   sudo htpasswd -c /etc/nginx/.htpasswd prometheus_user

2. Создайте конфигурацию сайта /etc/nginx/sites-available/prometheus:

   server {
       listen 80;
       server_name prometheus.example.com;
       location / {
           proxy_pass http://127.0.0.1:9090;
           proxy_set_header Host $host;
           auth_basic "Prometheus Access";
           auth_basic_user_file /etc/nginx/.htpasswd;
       }
   }

3. Активируйте и перезагрузите NGINX:

   ln -s /etc/nginx/sites-available/prometheus /etc/nginx/sites-enabled/
   systemctl reload nginx

Теперь при попытке доступа к http://prometheus.example.com браузер запросит логин и пароль. Для дополнительной защиты добавьте HTTPS с помощью Let's Encrypt (certbot).

Важно: Не забудьте также защитить Alertmanager (порт 9093) и Grafana (порт 3000). Grafana имеет свою собственную систему аутентификации, но для дополнительной безопасности можно также проксировать её через тот же NGINX.

Активный backup и snapshot: как сохранить и восстановить TSDB.

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

Создание снимка (snapshot): Отправьте HTTP POST запрос на эндпоинт /api/v1/admin/tsdb/snapshot. Для работы требуется флаг --web.enable-admin-api (по умолчанию выключен для безопасности). Добавьте его в systemd unit: ExecStart=... --web.enable-admin-api и перезапустите Prometheus. Затем выполните:

curl -X POST http://localhost:9090/api/v1/admin/tsdb/snapshot

{"status":"success","data":{"name":"20241215T123456Z-abcde"}}

Восстановление из снимка:

1. Остановите Prometheus: systemctl stop prometheus.
2. Очистите или переместите текущую TSDB: mv /opt/prometheus/data /opt/prometheus/data.old.
3. Скопируйте снимок как новую TSDB: cp -r /path/to/snapshot /opt/prometheus/data.
4. Запустите Prometheus: systemctl start prometheus.

Альтернатива: Для кластерного бэкапа с федерацией или Thanos используйте remote_write в долгосрочное хранилище (VictoriaMetrics, TimescaleDB). Снэпшоты подходят для отдельных инстансов Prometheus небольшого размера (до сотен гигабайт).

Автоматизация: Настройте cron-задачу, которая раз в сутки создаёт снимок и загружает его в S3 с помощью скрипта.