Сбор метрик: 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.
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 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, многотенантность, горизонтальное масштабирование).
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
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 и долговременное хранение, аннотации релизов и интеграцию с авто-откатами — и у вас получится быстрый, масштабируемый и экономный контур метрик, который помогает принимать решения в проде.