GH GambleHub

Збір метрик: Prometheus, Grafana

Збір метрик: Prometheus, Grafana

1) Мета і рамка

Завдання контуру метрик - надійно зібрати і зберігати часові ряди, дати швидкий PromQL для RCA, алерти по SLO і зрозумілі дашборди. Базова пара: Prometheus (scrape → store → query) і Grafana (візуалізація, алерти, анотації релізів). Для довгого зберігання і глобального запиту - Thanos/Cortex/Mimir.

2) Модель даних і семантика

Серія = ім'я метрики + набір label'ів (ключ = значення).
Типи: counter, gauge, histogram, summary (в проді - частіше histogram).

Семантика:
  • RED (API): «rate», «errors», «duration» (гістограми).
  • USE (ресурси): Utilization, Saturation, Errors (CPU/RAM/Disk/Net).
  • Іменування: `namespace_subsystem_metric_unit` (например, `http_server_requests_total`, `db_connections_current`).

Анти-кардинальність: мінімізуйте різні значення label'ів (ніяких user_id, request_id в label).

3) Експонування та сервіс-дискавері

Експортери: node_exporter, kube-state-metrics, cAdvisor, БД/Очереди (postgres_exporter, redis_exporter, kafka_exporter).
Власні сервіси: клієнтські бібліотеки (Go/Java/Node/Python) → '/metrics'.
Service Discovery: Kubernetes, EC2/ASG, Consul, static files.

Базовий'prometheus. yml'( фрагмент):
yaml global:
scrape_interval: 15s evaluation_interval: 15s scrape_configs:
- job_name: 'kubernetes-nodes'
kubernetes_sd_configs: [{ role: node }]
relabel_configs:
- action: labelmap regex: __meta_kubernetes_node_label_(.+)
- job_name: 'apps'
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]
target_label: __metrics_path__
regex: (.+)
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
target_label: __address__
regex: (.+)
replacement: $1
Анотації pod'ів:
yaml prometheus. io/scrape: "true"
prometheus. io/path: /metrics prometheus. io/port: "8080"

4) Гістограми і latency

Використовуйте експліцитні бакети під ваші SLO:
  • Веб/API: `[10ms,25,50,100,200,400,800,1600]`
  • Платежі/виплати: додайте хвіст до 5-10s.
PromQL p95:
promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)
З Exemplars (якщо включені):
promql histogram_quantile(0. 95,
sum by (le, route) (rate(traces_spanmetrics_duration_bucket{route="/withdraw"}[5m]))
)

5) Правила запису (recording rules)

Скорочують важкі запити, стандартизують SLI.

yaml groups:
- name: api_sli interval: 30s rules:
- record: job:http:success_ratio:rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
- record: job:http:duration_p95:5m expr: histogram_quantile(0. 95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) SLO і алерти (multi-window burn)

SLO 99. 9% успішних запитів/30d.

yaml groups:
- name: slo_burn rules:
- alert: ErrorBudgetBurnHighShort expr: (1 - job:http:success_ratio:rate5m) > (1 - 0. 999) 14 for: 5m labels: { severity: critical }
annotations: { summary: "Fast burn >14x for 5m" }

- alert: ErrorBudgetBurnHighLong expr: (1 - job:http:success_ratio:rate5m) > (1 - 0. 999) 6 for: 1h labels: { severity: critical }
annotations: { summary: "Long burn >6x for 1h" }
Alertmanager (спрощено):
yaml route:
receiver: pager group_by: ["service"]
receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true

7) Label-гігієна і економія

Імена label'ів стабільні і стандартизовані: `service`, `env`, `region`, `route`, `code`, `version`.
Обмежуйте кардинальність: метрики з'route'повинні використовувати шаблонний'http. route'( а не повний URL).
Семплінг логіки - в трейсах; в метриках - ніякого user_id.
Властивості релізу ('service. version') корисні для порівняння старої/нової версії.

8) Масштабування і HA

Prometheus - вертикально і шардуванням по scrape-target:
  • Два Prometheus (A/B) скраплять одні й ті ж цілі (HA → алерти дублюються).
  • Thanos: Sidecar до кожного Prometheus, Store + Query для глобальних запитів і довготривалого зберігання (S3/GCS).
  • Альтернатива: Cortex/Mimir (remote-write, багатотенантність, горизонтальне масштабування).
Remote write (приклад):
yaml remote_write:
- url: https://mimir. example. com/api/v1/push basic_auth: { username: tenantA, password: $MIMIR_TOKEN }
Retenшн локального TSDB:
yaml
--storage. tsdb. retention. time=15d
--storage. tsdb. max-block-duration=2h

9) Grafana: дашборди, алерти, анотації

Стандартні дашборди:

1. Platform Overview (SLO/RED, error-budget).

2. API by Route (RPS/5xx/p95, порівняння'version').

3. K8s Cluster/Nodes (control-plane, saturation).

4. DB/Cache/Queues (lag/locks/hit ratio/backlog).

5. Per-Release (до/після, анотації релізів з CI).

Grafana Alerting: тригери по PromQL, ротації on-call, mute-times «вікна релізів».

Annotations: CI додає реліз-подія з'commit','image. tag', посиланням на пайплайн.

10) Kubernetes: що обов'язково міряти

Control-plane: `apiserver_request_total`, etcd leader/fsync, scheduler latency.
Workloads: рестарти,'container _ cpu _ cfs _ throttled _ seconds _ total', OOM, Pending/Evicted, PDB порушення.
Мережа: дропи, conntrack,'kube-proxy'помилки.
Квоти/ліміти: Requests vs Limits, HPA/VPA, saturation узлов.

11) БД/кеші/черги: ключові сигнали

PostgreSQL/MySQL: `connections`, `locks`, `deadlocks_total`, `xact_commit/rollback`, replication lag.
Redis: hit ratio, `evictions`, latency `instantaneous_ops_per_sec`.
Kafka/RabbitMQ: consumer lag, unacked, ISR, disk usage.

Приклади PromQL:
promql
Queue backlog sum by (topic) (kafka_consumergroup_lag)> 1000

Postgres replication lag max(pg_replication_lag_seconds) > 2

12) Безпека і мульти-тенантність

RBAC до Prometheus/Grafana, datasource-пермішени.
Ланцюжок TLS/mTLS на ingress/між компонентами.
Ізоляція орендарів: окремі Prometheus або tenant-label в Cortex/Mimir; ліміти на серію і запит.
Секрети в алертах/нотифікаціях - заборонені (використовуйте ID тікету, а не PII).

13) Інтеграція з релізами та авто-відкатами

SLO-правила → AnalysisTemplate (Argo Rollouts) або CI-gate.
При спрацьовуванні burn-алертів - pause/rollback canary; в лозі/анотації - посилання на реліз.
Порівняння стабільної і канарської версії через label'version'.

14) Типові помилки (анти-патерни)

Безконтрольна кардинальність label'ів (user_id, url. full, динамічні ключі).
Змішування prod і stage в одному кластері без'env'label.
Тільки gauge без RED/USE; без гістограм p95/p99.
Алерти по «залізу» без прив'язки до SLO → шум.
Відсутність recording rules → «важкі» запити в прод-інцидентах.
Немає анотацій релізів → складно зіставити зміни і деградації.

15) Чек-лист впровадження (0-45 днів)

0-10 днів

Node/kube-state/cAdvisor експортери; '/metrics'в сервісах.
Базові RED/USE дашборди; стандартні бакети гістограм.
Включити анотації релізів з CI.

11-25 днів

Recording rules для SLI; multi-window burn алерти.
HA Prometheus (подвійний scrape), резервна копія конфігів GitOps.
Alertmanager: маршрути/тихий режим/ротації on-call.

26-45 днів

Remote-write в Thanos/Cortex/Mimir, тривале зберігання.
Оптимізація кардинальності, ліміти на серії, запити.
SLO-гейтинг релізів і auto-rollback інтеграція.

16) Метрики зрілості

Покриття RED/USE за ключовими сервісами ≥ 95%.
Середній час виконання «важких» PromQL <2 c (p95) за рахунок recording rules.
Відношення корисних/галасливих алертів> 3:1.
Кардинальність під контролем: <10M активних серій на кластер, відсутність сплесків.
100% релізів мають анотацію в Grafana і зіставлення метрик до/після.

17) Корисні сніпети

Порівняння stable vs canary за версією

promql histogram_quantile(0. 95,
sum by (le, version) (rate(http_request_duration_seconds_bucket{version=~"stable    canary"}[5m]))
)

Помилки 5xx за маршрутами

promql topk(5,
sum by (route) (rate(http_requests_total{status=~"5.."}[5m]))
)

CPU saturation контейнера

promql rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1

Зв'язок метрик з трейсами (Exemplars включені)

promql sum (rate (http_request_duration_seconds_bucket[5m])) by (le) # clickable to the track

18) Висновок

Prometheus + Grafana - стандарт де-факто для метрик. Перемагають семантика і дисципліна: RED/USE, акуратні label'и, гістограми під SLO, recording rules і SLO-алерти. Додайте HA і довготривале зберігання, анотації релізів та інтеграцію з авто-відкатами - і у вас вийде швидкий, масштабований і економний контур метрик, який допомагає приймати рішення в проді.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Telegram
@Gamble_GC
Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.