Изучите типы метрик Prometheus, работу Node и Process Exporter, а также экспортеры (PostgreSQL, SNMP, NGINX, Kafka) и настройку Pushgateway с Alertmanager.

Типы метрик в Prometheus

Графы (counter, gauge, histogram, summary)

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

Counter — монотонно растущий счётчик. Он подходит для подсчёта событий, которые только увеличиваются (запросы к API, количество ошибок).

# HELP http_requests_total Общее количество HTTP‑запросов
# TYPE http_requests_total counter
http_requests_total{method="GET",code="200"} 12456

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

# HELP node_cpu_seconds_total Общее время работы CPU в секундах
# TYPE node_cpu_seconds_total gauge
node_cpu_seconds_total{cpu="0"} 34567.89

Histogram — набор бакетов, фиксирующий распределение значений. Идеален, когда нужен детальный разрез по latency или размеру запросов.

# HELP http_request_duration_seconds Гистограмма времени обработки запросов
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.1"} 1023
http_request_duration_seconds_bucket{le="0.5"} 2543
http_request_duration_seconds_bucket{le="+Inf"} 3000

Summary — аналог histogram, но считает квантильные оценки (p50, p95) на лету. Удобно, когда интересует лишь несколько процентилей без необходимости хранить полную гистограмму.

# HELP rpc_duration_seconds Сводка длительности RPC
# TYPE rpc_duration_seconds summary
rpc_duration_seconds{quantile="0.5"} 0.012
rpc_duration_seconds{quantile="0.9"} 0.045
rpc_duration_seconds_sum 123.45
rpc_duration_seconds_count 5000

Лейблы и их влияние на cardinality

Лейблы позволяют добавить измерения к метрикам (например, method="POST" или region="eu-west"). Однако каждый уникальный набор лейблов создаёт отдельный временной ряд. При масштабных системах количество таких рядов (cardinality) может выйти из‑под контроля, что привод к росту потребления памяти и деградации производительности.

Чтобы контролировать cardinality, придерживайтесь нескольких правил:

• Не используйте динамические или уникальные значения (например, IP‑адреса, UUID) в качестве лейблов.
• Группируйте метрики по логическим сущностям (region, service) и оставляйте детали в тегах только при реальной необходимости.

Мобильная автоматизация склада

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

Тайм‑шаги и ретеншн

Тайм‑шаг (scrape_interval) определяет, как часто Prometheus будет запрашивать метрики у экспортеров. Хороший выбор интервала — компромисс между точностью данных и нагрузкой на систему. Для большинства сервисов 15 секунд достаточно, однако для критических SLA‑метрик может потребоваться более частый сбор (5 секунд).

Ретеншн (время хранения) задаётся в конфигурации сервера. По умолчанию хранение составляет 15 дней, но в продакшене часто увеличивают до 30‑90 дней, чтобы иметь возможность анализировать тренды. При этом важно помнить, что увеличение ретеншн линейно растягивает объём диска, поэтому планируйте ресурс заранее.

Node Exporter и Process Exporter

CPU, память, диск

Node Exporter собирает базовые системные метрики из /proc и /sys. Это позволяет в реальном времени увидеть загрузку процессора, потребление памяти и состояние дисков без дополнительной конфигурации. Например, метрика node_cpu_seconds_total разбита по режимам (user, system, idle, iowait), а node_memory_MemAvailable_bytes показывает, сколько памяти осталось для новых процессов.

Для визуализации часто используют графики, где «CPU usage» и «Memory usage» накладываются друг на друга, а дисковые I/O отображаются отдельными панелями. Это помогает быстро обнаружить узкие места, например, когда node_disk_io_time_seconds_total резко возрастает из‑за переполнения очереди запросов к SSD.

Пользовательские метрики процессов

Process Exporter позволяет достать метрики конкретных процессов, что особенно ценно в микросервисных архитектурах. С помощью файла конфигурации можно задать process_names или cmdline_regex и получать такие показатели, как process_resident_memory_bytes, process_cpu_seconds_total и количество открытых файловых дескрипторов.

Пример простого конфигурационного блока для мониторинга nginx и redis:

process_names:

• name: “nginx” cmdline:
  • “nginx”
• name: “redis” cmdline:
  • “redis-server”

После перезапуска Process Exporter в Prometheus появятся метрики process_resident_memory_bytes{process="nginx"} и process_resident_memory_bytes{process="redis"}, которые можно сравнивать с пороговыми значениями в Alertmanager.

Настройка снижения нагрузки

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

Дополнительные шаги по оптимизации:

• Разместить Node Exporter и Process Exporter на отдельном выделенном ядре с помощью taskset или cgroup‑ов.
• Включить кэширование результатов с помощью honor_labels: false в Prometheus, если метки не меняются часто.

Специализированные Exporter‑ы

PostgreSQL Exporter

PostgreSQL Exporter собирает метрики непосредственно из системных представлений pg_stat_* и функций pg_backend_*. Он позволяет оценить загрузку процессора, количество активных соединений, задержки запросов и состояние репликации. Пример конфигурации в prometheus.yml:

scrape_configs:

• job_name: ‘postgres’ static_configs:
  • targets: [‘db01:9187’]

Для большинства случаев достаточно включить предустановленные дашборды в Grafana, где уже есть визуализация таких показателей, как db_size_bytes, pg_stat_activity_count и pg_replication_lag_seconds. При необходимости можно добавить пользовательские запросы через параметр queries.yaml, что особенно полезно для мониторинга специфических функций бизнес‑логики.

SNMP Exporter

SNMP Exporter — это мост между традиционной сетью, где оборудование выставляет метрики по протоколу SNMP, и Prometheus. Он поддерживает версии SNMP v1/v2c/v3 и позволяет собрать такие показатели, как нагрузка процессора, использование памяти, статус интерфейсов и температуру.

Ключевой момент — правильно составить snmp.yml с маппингом OID к именам метрик. Пример небольшого файла:

После запуска Exporter-а он будет слушать HTTP‑эндпоинт /snmp, откуда Prometheus будет забирать агрегированные метрики. Это удобный способ интегрировать старое оборудование с современной стековой наблюдаемостью.

NGINX и Apache Exporter

Для веб‑серверов существует два популярных экспортера: NGINX Exporter (на основе nginx_status) и Apache Exporter (использует mod_status). Оба они предоставляют метрики запросов, активных соединений, времени ответа и статистики кэширования.

Самый простой способ включить их в Prometheus — добавить отдельные задачи scrape:

- job_name: ’nginx’ static_configs: - targets: [‘web01:9113’]

• job_name: ‘apache’ static_configs:
  • targets: [‘web02:9117’]

Помимо базовых показателей, NGINX Exporter умеет отдавать данные о TLS‑сессиях и скорости передачи байтов, тогда как Apache Exporter добавляет метрики о работе воркеров и состоянии модулей.

Kafka JMX Exporter

Kafka публикует почти все свои внутренние метрики через JMX. JMX Exporter‑а от Prometheus Community выступает в роли Java‑агента, который преобразует MBeans в привычный формат Prometheus.

Для типичного кластера достаточно добавить в kafka-run-class.sh параметр:

-javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent.jar=9404:/opt/jmx_exporter/kafka.yml

В файле kafka.yml задаются правила выбора MBean‑ов. Пример:

• kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec → kafka_broker_messages_in_total
• kafka.network:type=RequestMetrics,name=TotalTimeMs,request=Produce → kafka_network_request_total_time_ms

Собранные метрики позволяют наблюдать за задержкой репликации, потреблением дискового пространства и эффективностью продюсеров/консьюмеров. Интеграция с Grafana часто делается через готовый дашборд, где уже есть визуализация основных бизнес‑показателей, таких как lag и throughput.

Настройка Pushgateway и Alertmanager

Push‑модель для короткоживущих задач

Pushgateway — это вспомогательный компонент, позволяющий собирать метрики от процессов, которые появляются на короткое время и не могут постоянно опрашиваться Prometheus. В типичной схеме такие задачи (например, скрипты миграций, CI‑pipeline или однократные batch‑jobs) отправляют свои метрики в Pushgateway, а Prometheus периодически их считывает.

Ключевые моменты, которые стоит помнить при работе с Pushgateway:

• Идентификация метрик. Для каждой метрики необходимо указывать набор меток, которые однозначно определяют её источник (job, instance, task_id и т.д.). Это упрощает последующий фильтр и удаление устаревших данных.
• Срок жизни. По умолчанию Pushgateway хранит данные до тех пор, пока они явно не удалятся. Чтобы избежать «залипания» старых метрик, рекомендуется использовать параметр pushgateway.cleanup.interval или периодически вызывать DELETE‑запросы через API.
• Безопасность. Pushgateway обычно развёртывается в закрытой сети, но при открытом доступе следует включить базовую аутентификацию и ограничить доступ по IP.

Пример отправки метрик из Bash‑скрипта:

cat > metrics.txt <<EOF

TYPE my_job_successful counter

my_job_successful{job=“daily_backup”,instance=“ci-runner-01”} 1 EOF curl –data-binary @metrics.txt http://pushgateway:9091/metrics/job/daily_backup/instance/ci-runner-01

После того как метрика достигнет необходимого состояния, её можно удалить командой curl -X DELETE http://pushgateway:9091/metrics/job/daily_backup/instance/ci-runner-01. Такой подход гарантирует, что в системе не останется «мусора», а Prometheus будет видеть только актуальные данные.

Роутинг алертов по severities

Alertmanager отвечает за агрегацию, хранение и маршрутизацию алертов, получаемых от Prometheus. Один из самых популярных способов классификации событий — разделение по уровням тяжести (severity). Это позволяет направлять критические проблемы сразу к on‑call инженеру, а менее срочные — в канал дежурного мониторинга.

Конфигурация роутинга в alertmanager.yml выглядит примерно так:

route: receiver: default group_by: [‘alertname’, ‘job’] group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - match: severity: critical receiver: critical-team continue: true - match: severity: warning receiver: ops-team - match: severity: info receiver: info-archive receivers:

• name: critical-team pagerduty_configs:
  • service_key: ""
• name: ops-team email_configs:
  • to: “ops@example.com”
• name: info-archive webhook_configs:
  • url: “http://archive-service/alert”

Обратите внимание на параметр continue: true у критических алертов — он позволяет одновременно отправлять сообщение в несколько получателей, если это необходимо. Кроме того, группировка по полям alertname и job гарантирует, что дублирующие сработки от одного и того же источника будут агрегированы в один выпуск.

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

Полезные сервисы и обновления

Мобильная автоматизация склада

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

Маркировка «Честный знак»

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

Розничная торговля и инвентаризация

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

Вопросы и ответы

Что такое Counter и когда его использовать?

Counter — монотонно растущий счётчик. Его применяют для подсчёта событий, которые только увеличиваются, например, количество HTTP‑запросов, ошибок или обработанных сообщений.

Чем Gauge отличается от Counter?

Gauge может как расти, так и уменьшаться. Его используют для измерения текущих состояний, таких как загрузка CPU, свободная память или размер очереди.

Как выбрать между Histogram и Summary?

Histogram сохраняет распределение по бакетам и позволяет вычислять любые квантильные значения при запросе. Summary уже считает выбранные квантильные оценки (p50, p95) на лету, но не хранит полную гистограмму. Выбирайте Histogram, когда нужны гибкие запросы, и Summary — когда интересуют только фиксированные процентилы.

Как избежать высокой cardinality при работе с лейблами?

Не используй динамические значения (IP, UUID) в лейблах, группируй метрики по логическим сущностям (region, service) и ограничивай количество разных комбинаций. При необходимости агрегируй детали в отдельные метрики.

Как оптимизировать нагрузку экспортеров?

Отключай неиспользуемые коллекторы (например, --collector.systemd), фильтруй только нужные процессы в Process Exporter, увеличивай scrape_interval для тяжёлых экспортёров (30‑60 сек) и размещай их на отдельном ядре или в cgroup‑е.

Когда следует использовать Pushgateway?

Pushgateway подходит для короткоживущих задач (batch‑jobs, CI‑pipeline, скрипты), которые не могут быть опрошены Prometheus. Метрики публикуются в него, а Prometheus периодически их считывает.

Как настроить роутинг алертов по уровням severity в Alertmanager?

В alertmanager.yml создайте правила match: по метке severity (critical, warning, info) и укажите соответствующие receiver. При необходимости используйте continue: true для отправки алерта в несколько получателей.

Какие метрики предоставляет Node Exporter?

Node Exporter собирает системные показатели из /proc и /sys: нагрузка CPU (node_cpu_seconds_total), доступная память (node_memory_MemAvailable_bytes), состояние дисков, сетевой I/O, количество открытых файловых дескрипторов и многие другие базовые метрики.