Prometheus: сбор метрик

(Раздел: Технологии и Инфраструктура)

Краткое резюме

Prometheus — индустриальный стандарт для метрик по времени: он скрейпит таргеты по HTTP, хранит серии в TSDB, считает агрегаты в PromQL и триггерит алерты через Alertmanager. Для iGaming это основа SLO-подхода (RED/USE, бизнес-метрики платежей), быстрой диагностики p95/p99 и автоматических решений (freeze/rollback).

1) Модель данных и кардинальность

Метрика: `name{label1="v1", label2="v2"} value @ timestamp`.
Кардинальность = произведение мощностей всех уникальных наборов лейблов; главный фактор стоимости.

• базовые: `service`, `env`, `region`, `instance`, `pod`, `container`, `version`;
• доменные: `route`, `psp`, `tenant` (осторожно!), `game_provider`.
• Нельзя класть `user_id`, `session_id`, случайные/высококардинальные значения.

2) Типы метрик

Counter — только растет (например, `http_requests_total`).
Gauge — моментальные значения (например, `queue_depth`).
Histogram/Summary — распределения латентности. В проде — Histogram (с поддержкой `histogram_quantile()` и exemplars).
Native Histograms — переменные бакеты, повышают точность и экономят размер (включайте там, где доступно).

go var httpLatency = prometheus. NewHistogramVec(
prometheus. HistogramOpts{
Name:  "http_request_duration_seconds",
Help:  "HTTP latency",
Buckets: prometheus. DefBuckets ,//or custom
},
[]string{"route","method"},
)

3) Экспортеры и что мерить

Сервисные: ваш код (SDK для Go/Java/Node/Python), RED-метрики API, бизнес-метрики (конверсия платежей).
Системные: node_exporter, cAdvisor/kubelet.
Сторонние: БД/кэши (mysqld_exporter, postgres_exporter, redis_exporter), NGINX/HAProxy, Kafka/RabbitMQ.
OTel-метрики: через OpenTelemetry Collector → Prometheus Remote Write или Prometheus-receiver → в общий стэк.

4) Scrape и relabel: как подключать таргеты

Базовый `prometheus.yml`

yaml global:
scrape_interval: 15s evaluation_interval: 15s external_labels:
env: "prod"
region: "eu-west"

scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['10. 0. 1. 10:9100','10. 0. 1. 11:9100']

- job_name: 'payments-api'
metrics_path: /metrics scheme: https tls_config:
ca_file: /etc/ssl/ca. crt cert_file: /etc/ssl/tls. crt key_file: /etc/ssl/tls. key relabel_configs:
- source_labels: [__address__]
regex: '(.):\d+'
target_label: instance replacement: '$1'

Kubernetes через Prometheus Operator

Используйте ServiceMonitor/PodMonitor вместо ручного `scrape_configs`.

yaml apiVersion: monitoring. coreos. com/v1 kind: ServiceMonitor metadata: { name: payments-api }
spec:
selector: { matchLabels: { app: payments-api } }
namespaceSelector: { matchNames: [ "prod" ] }
endpoints:
- port: metrics interval: 15s scheme: http relabelings:
- action: replace targetLabel: service replacement: "payments-api"

K8s аннотации (без Operator, упрощенно)

yaml metadata:
annotations:
prometheus. io/scrape: "true"
prometheus. io/port: "9102"
prometheus. io/path: "/metrics"

5) Хранение: TSDB, WAL и ретеншн

WAL (Write-Ahead Log) → быстрое восстановление после рестарта.
Compaction: сжатие блоков, экономия диска/CPU.
Ретеншн: храните горячие данные 7–30 дней; долгосрочное — выносите (см. «Масштабирование»).

• `--storage.tsdb.retention.time=15d`
• `--storage.tsdb.max-block-chunk-segment-size`
• Диск: быстрый SSD/NVMe; избегать сетевых томов без нужды.

6) PromQL: основы и частые паттерны

Rate/irate

promql rate(http_requests_total{route="/deposit"}[5m])

Ошибки и доля успешных

promql sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))

p95 латентности

promql histogram_quantile(0. 95,
sum by (le, route) (rate(http_request_duration_seconds_bucket[5m]))
)

Очереди/насыщение

promql max(queue_depth{queue="withdrawals"}) by (region)

7) Recording rules и производительность

Считайте тяжелые выражения заранее и храните как серии.

yaml groups:
- name: api. rules interval: 30s rules:
- record: job:http:request_duration_seconds:p95 expr:
histogram_quantile(0. 95,
sum by (le, job) (rate(http_request_duration_seconds_bucket[5m])))
- record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))

Плюс: быстрые дашборды, меньше нагрузка на CPU Prometheus.

8) Alerting и SLO (burn rate)

Burn-rate алерты (multi-window, multi-burn)

yaml groups:
- name: slo. payments rules:
- alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 5m labels: { severity: "page" }
annotations:
summary: "SLO fast burn"
runbook: "https://runbooks/payments/slo"
- alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket" }

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

9) Корреляция с трассировками и логами

Включайте exemplars: кликабельный `trace_id` в бакетах гистограмм.
Проставляйте в метрики лейблы `service`, `version`, `region` для «release compare».
На дашбордах — аннотации релизов (Git SHA/версия).

10) Масштабирование и долговременное хранение

Федерация: верхний Prometheus агрегирует из нижних (по job/label-фильтрам).
Remote Write: отправка рядов в backends длительного хранения/кластеры (Thanos/Cortex/Mimir).

Плюсы: бесконечная ретеншн, горизонтальное масштабирование, global view.
Минусы: сложнее эксплуатация, стоимость.
Шардинг по функциям: отдельные инстансы для системных метрик, бизнес, безопасностных.

11) Безопасность

TLS/mTLS между Prometheus ↔ таргеты/Alertmanager/remote_write.
Базовая/токен-аутентификация для /targets и API (перед проксирующим шлюзом).
RBAC: ограничьте доступ к UI/сериям по ролям; скрывайте приватные лейблы.
PII-гигиена: не пишите PII в метрики; используйте хэши/псевдонимы.

12) Kubernetes-практики

Prometheus Operator: CRD (ServiceMonitor, PodMonitor, Alertmanager, Prometheus).
kube-state-metrics + cAdvisor → полная картина кластера.
Тейнинги и ресурсы: выделенные ноды для мониторинга; лимиты CPU/RAM.
Снижение шума: лейбл-селекторы для «производственных» неймспейсов, паддинг scrape_interval там, где можно.

13) Бизнес-метрики и продукт

Платежи: `payments_success_total{psp, currency}`, `payment_conversion_ratio`, `ttw_seconds_histogram`.
Игровая активность: ставки/мин, удержание сессий как gauge, дроп-офф при ошибках.
Риск/фрод: триггеры по аномалиям скорости/гео; логирование отдельно, метрики — агрегаты.

14) Стоимость и производительность (FinOps)

Контролируйте кардинальность (тэг-ревью перед добавлением нового лейбла).
Сэмплинг гистограмм/редкие экспортеры → `scrape_interval`↑ для не-критичных таргетов.
Downsampling в бэкендах длительного хранения.
Кэширование дашбордов и широкая опора на recording rules.

15) Примеры «быстрого старта»

Экспортер RED в приложении (Python)

python from prometheus_client import Counter, Histogram, start_http_server reqs = Counter('http_requests_total','', ['route','method','status'])
lat = Histogram('http_request_duration_seconds','', ['route','method'])
start_http_server(8000)

def handle(req):
with lat. labels(req. route, req. method). time():
status = app(req)
reqs. labels(req. route, req. method, str(status)). inc()
return status

Пороговые алерты p95

promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }

16) Чек-лист внедрения

1. Определите набор базовых метрик (RED/USE) и доменных показателей.
2. Согласуйте лейблы и гайд по кардинальности.
3. Настройте scrape/ServiceMonitor, TLS/mTLS, relabel.
4. Включите гистограммы для ключевых путей и exemplars.
5. Создайте recording rules для p95, success ratio, бизнес-агрегатов.
6. Введите SLO-алерты (burn rate) и рутинг Alertmanager.
7. Поднимите дашборды: service map, release compare, платежи.
8. Решите про федерацию/remote_write и ретеншн.
9. Ограничьте доступ (RBAC), проверьте отсутствие PII.
10. Включите runbooks и game-day проверки.

17) Анти-паттерны

Лейблы с высокой кардинальностью (user/session/request_id).
Summary вместо Histogram для ключевых SLO → нет `histogram_quantile`.
Scrape «всего подряд» без фильтрации/ротации → рост затрат и шума.
Алерты по сырым метрикам без SLO → алерт-фэтиг.
Отсутствие recording rules → «тяжелые» дашборды.
Доверие к метрикам без TLS/mTLS → риск подмены/утечки.

Итоги

Prometheus дает iGaming-платформе наблюдаемость, привязанную к целям: точные гистограммы, стабильные агрегаты, четкие SLO-алерты и масштабирование до много-регионной карты. Дисциплина лейблов, корректные recording rules, связи с трассировками/логами и продуманная архитектура хранения обеспечивают быстрые релизы и предсказуемый p99 даже в пиковые моменты.