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 навіть в пікові моменти.