Collecte de métriques : Prometheus, Grafana

Collecte de métriques : Prometheus, Grafana

1) Objectif et cadre

La tâche du contour des métriques est d'assembler et de stocker de manière fiable les séries chronologiques, de donner rapidement le BouQL pour RCA, les alertes SLO et les dashboards compréhensibles. Paire de base : Prometheus (scrape → store → query) et Grafana (visualisation, alertes, annotations de sortie). Pour le stockage long et la demande globale - Thanos/Cortex/Mimir.

2) Modèle de données et sémantique

Série = nom de la métrique + jeu d'étiquettes (clé = valeur).
Types : counter, gauge, histogramme, résumé (dans la vente - plus souvent histogramme).

• RED (API) : 'rate', 'errors', 'duration' (histogrammes).
• USE (ресурсы): Utilization, Saturation, Errors (CPU/RAM/Disk/Net).
• Nom : 'namespace _ subsystem _ metric _ unit' (par exemple, 'http _ server _ requests _ total', 'db _ connexions _ current').

Anti-cardinalité : minimisez les différentes valeurs de label (pas de user_id request_id dans label).

3) Exposition et service discovery

Exportateurs : node_exporter, kube-state-metrics, cAdvisor, OBD/files d'attente (postgres_exporter, redis_exporter, kafka_exporter).
Services propres : bibliothèques clientes (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

yaml prometheus. io/scrape: "true"
prometheus. io/path: /metrics prometheus. io/port: "8080"

4) Histogrammes et latitude

• Web/API : '[10ms, 25,50,100,200,400,800,1600]'
• Paiements/décaissements : ajoutez la queue à 5-10s.

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

promql histogram_quantile(0. 95,
sum by (le, route) (rate(traces_spanmetrics_duration_bucket{route="/withdraw"}[5m]))
)

5) Règles d'enregistrement (règles d'enregistrement)

Réduire les demandes lourdes, standardiser 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 et alertes (multi-window burn)

SLO 99. 9 % des demandes réussies/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" }

yaml route:
receiver: pager group_by: ["service"]
receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true

7) Label-hygiène et économie

Les noms du label's sont stables et normalisés : 'service', 'bou', 'région', 'route', 'code', 'version'.
Limitez la cardinalité : les métriques avec 'route' doivent utiliser le modèle 'http. route '(pas l'URL complète).
Sampling de la logique - dans les trails ; Il n'y a pas de user_id dans les métriques.
Propriétés de sortie ('service. version ') sont utiles pour comparer l'ancienne/nouvelle version.

8) Mise à l'échelle et HA

• Deux Prometheus (A/B) grattent les mêmes cibles (les alertes HA → sont dupliquées).
• Thanos : Sidecar à chaque Prometheus, Store + Query pour les demandes globales et le stockage à long terme (S3/GCS).
• Alternative : Cortex/Mimir (écriture à distance, multitenance, mise à l'échelle horizontale).

yaml remote_write:
- url: https://mimir. example. com/api/v1/push basic_auth: { username: tenantA, password: $MIMIR_TOKEN }

yaml
--storage. tsdb. retention. time=15d
--storage. tsdb. max-block-duration=2h

9) Grafana : dashboards, alertes, annotations

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

2. API by Route (RPS/5xx/p95, comparaison 'version').

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

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

5. Per-Release (avant/après, annotation des releases de CI).

Alerting Grafana : Déclencheurs par BouQL, rotation sur appel, mute-times « fenêtre de sortie ».

Annotations : CI ajoute un événement de sortie avec 'commit', 'image. tag ', référence à la pipline.

10) Kubernetes : ce qui est nécessaire pour mesurer

Control-plane: `apiserver_request_total`, etcd leader/fsync, scheduler latency.
Workloads : restarts, 'container _ cpu _ cfs _ throttled _ seconds _ total', OOM, Pending/Evicted, violation PDB.
Réseau : drops, conntrack, bugs 'kube-proxy'.
Quotas/limites : Requests vs Limits, HPA/VPA, saturation de nœuds.

11) OBD/caches/files d'attente : signaux clés

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) Sécurité et multi-ténacité

RBAC à Prometheus/Grafana, datasource-permishen.
Chaîne TLS/mTLS sur ingress/entre les composants.
Isolation des locataires : Prometheus ou tenant-label séparé à Cortex/Mimir ; limites de série et de demande.
Les secrets dans les alertes/notations sont interdits (utilisez l'ID tiket plutôt que PII).

13) Intégration avec les sorties et les retours automatiques

Règles SLO → AnalyseTemplate (Argo Rollouts) ou CI-gate.
Lors du déclenchement des burn-alerts - pause/rollback canary ; Dans le logue/annotation, lien vers la version.
Comparaison de la version stable et canarienne via le label 'version'.

14) Erreurs typiques (anti-modèles)

Cardinalité incontrôlée des étiquettes (user_id, url. full, clés dynamiques).
Mélange de prod et de stage dans un seul cluster sans « bou » label.
Seulement gauge sans RED/USE ; sans histogrammes p95/p99.
Les alertes « fer » sans référence à SLO → le bruit.
L'absence d'enregistrement des règles → les demandes « lourdes » dans les incidents.
Il n'y a pas d'annotations de version → il est difficile de comparer les modifications et les dégradations.

15) Chèque de mise en œuvre (0-45 jours)

0-10 jours

Node/kube-state/cAdvisor exportateurs ; '/metrics'dans les services.
Dashboards de base RED/USE ; les réservoirs standard des histogrammes.
Inclure les annotations de version de CI.

11-25 jours

Règles d'enregistrement pour SLI ; multi-window burn alert.
HA Prometheus (double scrape), sauvegarde des configues GitOps.
Alertmanager : itinéraires/mode silencieux/rotation sur appel.

26-45 jours

Remote-write à Thanos/Cortex/Mimir, stockage à long terme.
Optimisation de la cardinalité, limites des séries, demandes.
Version SLO et intégration auto-rollback.

16) Métriques de maturité

Couverture RED/USE pour les services clés ≥ 95 %.
Temps moyen d'exécution des « lourds » BouQL <2 c (p95) grâce aux règles d'enregistrement.
Rapport alertes utiles/bruyantes> 3:1.
Cardinalité sous contrôle : <10M séries actives par cluster, pas de surtensions.
100 % des versions ont une annotation dans Grafana et une correspondance des métriques avant/après.

17) Extraits utiles

Comparaison de stable vs canary par version

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

Erreurs 5xx par itinéraire

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

CPU saturation conteneur

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

Association des métriques avec les trajets (Exemplars inclus)

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

18) Conclusion

Prometheus + Grafana est la norme de facto pour les métriques. La sémantique et la discipline sont gagnantes : RED/USE, label soigné, histogrammes sous SLO, règles d'enregistrement et alertes SLO. Ajoutez le stockage HA et à long terme, les annotations de version et l'intégration avec les retours automatiques - et vous obtiendrez un contour de mesure rapide, évolutif et économique qui vous aidera à prendre des décisions dans la vente.