Sammlung von Metriken: Prometheus, Grafana
Sammlung von Metriken: Prometheus, Grafana
1) Ziel und Rahmen
Die Aufgabe der Metrikkontur besteht darin, Zeitreihen zuverlässig zu sammeln und zu speichern, eine schnelle PromQL für RCA, Alerts per SLO und verständliche Dashboards zu liefern. Grundpaar: Prometheus (Scrape → Store → Query) und Grafana (Visualisierung, Alerts, Release Annotationen). Für lange Lagerung und globale Anfrage - Thanos/Cortex/Mimir.
2) Datenmodell und Semantik
Serie = Name der Metrik + Labelsatz (Schlüssel = Wert).
Typen: Zähler, Gauge, Histogramm, Zusammenfassung (im Produkt - häufiger Histogramm).
- ROT (API): 'rate', 'errors', 'duration' (Histogramme).
- USE (ресурсы): Utilization, Saturation, Errors (CPU/RAM/Disk/Net).
- Benennung: 'namespace _ subsystem _ metric _ unit' (z.B. 'http _ server _ requests _ total', 'db _ connections _ current').
Anti-Kardinalität: Minimieren Sie unterschiedliche Label-Werte (keine user_id request_id im Label).
3) Belichtung und Service Discovery
Exporteure: node_exporter, kube-state-metrics, cAdvisor, DB/Warteschlangen (postgres_exporter, redis_exporter, kafka_exporter).
Eigene Dienste: Client-Bibliotheken (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
Anmerkungen der Pod's:
yaml prometheus. io/scrape: "true"
prometheus. io/path: /metrics prometheus. io/port: "8080"
4) Histogramme und Latenz
Verwenden Sie explizite Tanks für Ihre SLOs:- Web/API: „[10ms, 25,50,100,200,400,800,1600]“
- Zahlungen/Auszahlungen: Fügen Sie einen Schwanz zu 5-10s hinzu.
promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)
Mit Beispielen (falls enthalten):
promql histogram_quantile(0. 95,
sum by (le, route) (rate(traces_spanmetrics_duration_bucket{route="/withdraw"}[5m]))
)
5) Aufzeichnungsregeln (recording rules)
Schwere Anfragen werden reduziert, SLI standardisiert.
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 und Alerts (Multi-Fenster brennen)
SLO 99. 9% erfolgreiche Anfragen/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 (vereinfacht):
yaml route:
receiver: pager group_by: ["service"]
receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true
7) Label-Hygiene und Einsparungen
Die Label-Namen sind stabil und standardisiert: 'service', 'env', 'region', 'route', 'code', 'version'.
Begrenzen Sie die Kardinalität: Metriken mit 'route' sollten template' http verwenden. route'(nicht die vollständige URL).
Logik-Sampling - in Traces; In Metriken gibt es keine user_id.
Veröffentlichungseigenschaften ('service. version') sind nützlich, um die alte/neue Version zu vergleichen.
8) Skalierung und HA
Prometheus - vertikal und sharding nach scrape-target:- Zwei Prometheus (A/B) kratzen die gleichen Ziele (HA → Alerts werden dupliziert).
- Thanos: Sidecar zu jedem Prometheus, Store + Query für globale Anfragen und Langzeitspeicherung (S3/GCS).
- Alternative: Cortex/Mimir (Remote-Schreiben, Multitenant, horizontale Skalierung).
yaml remote_write:
- url: https://mimir. example. com/api/v1/push basic_auth: { username: tenantA, password: $MIMIR_TOKEN }
Retention der lokalen TSDB:
yaml
--storage. tsdb. retention. time=15d
--storage. tsdb. max-block-duration=2h
9) Grafana: Dashboards, Warnungen, Anmerkungen
Standard-Dashboards:1. Platform Overview (SLO/RED, error-budget).
2. API by Route (RPS/5xx/p95, Vergleich 'version').
3. K8s Cluster/Nodes (control-plane, saturation).
4. DB/Cache/Queues (lag/locks/hit ratio/backlog).
5. Per-Release (vorher/nachher, Anmerkungen zu Releases aus CI).
Grafana Alerting: Auslöser durch PromQL, On-Call-Rotation, Mute-Zeiten „Release-Fenster“.
Annotations: CI fügt ein Release-Event mit 'commit', 'image hinzu. tag', unter Bezugnahme auf die Pipeline.
10) Kubernetes: Was man unbedingt messen muss
Control-plane: `apiserver_request_total`, etcd leader/fsync, scheduler latency.
Workloads: Restarts, 'container _ cpu _ cfs _ throttled _ seconds _ total', OOM, Pending/Evicted, PDB des Verstoßes.
Netzwerk: drops, conntrack, 'kube-proxy' Fehler.
Quoten/Limits: Requests vs Limits, HPA/VPA, Knotensaturation.
11) DB/Caches/Queues: Schlüsselsignale
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) Sicherheit und Multi-Tenant
RBAC zu Prometheus/Grafana, datasource-permishens.
TLS/mTLS-Kette auf ingress/zwischen Komponenten.
Isolierung von Mietern: separate Prometheus oder Tenant-Label in Cortex/Mimir; Chargen- und Anforderungslimits.
Geheimnisse in Warnmeldungen/Benachrichtigungen - verboten (verwenden Sie die Ticket-ID, nicht die PII).
13) Integration mit Releases und Auto-Rollbacks
SLO-Regeln → AnalysisTemplate (Argo Rollouts) oder CI-Gate.
Wenn Burn-Alert ausgelöst wird - Pause/Rollback canary; im Protokoll/Annotation - Link zur Freigabe.
Vergleich der Stable- und Kanarienversion über Label 'version'.
14) Typische Fehler (Anti-Muster)
Die unkontrollierte Kardinalität von Label's (user_id, url. voll, dynamische Schlüssel).
Mischen von prod und stage in einem Cluster ohne' env 'label.
Nur Gauge ohne RED/USE; ohne p95/p99 Histogramme.
Eisenalerts ohne Bezug zu SLO → Rauschen.
Fehlende Aufzeichnungsregeln → „schwere“ Anfragen bei Prod-Vorfällen.
Es gibt keine Release-Annotationen → es ist schwierig, Veränderungen und Degradationen zu vergleichen.
15) Implementierung Checkliste (0-45 Tage)
0-10 Tage
Node/kube-state/cAdvisor Exporteure; '/metrics' in den Diensten.
Basis RED/USE Dashboards; Standard-Balkendiagramm-Baketten.
Release-Anmerkungen aus CI einschließen.
11-25 Tage
Aufzeichnungsregeln für SLI; multi-window burn alerta.
HA Prometheus (doppeltes Scrape), ein Backup der GitOps Configs.
Alertmanager: Routen/Ruhemodus/On-Call-Rotationen.
26-45 Tage
Fernschreiben in Thanos/Cortex/Mimir, Langzeitlagerung.
Kardinalitätsoptimierung, Chargenlimits, Abfragen.
SLO-Gatting Releases und Auto-Rollback Integration.
16) Reifegradkennzahlen
Die RED/USE-Abdeckung für Schlüsseldienste ≥ 95%.
Durchschnittliche Durchlaufzeit „schwerer“ PromQL <2 c (p95) durch Recording-Regeln.
Nützliches/lautes Alarmverhältnis> 3: 1.
Kardinalität unter Kontrolle: <10M aktive Serien pro Cluster, keine Spitzen.
100% der Releases haben eine Annotation in Grafana und ein Vorher/Nachher-Mapping von Metriken.
17) Nützliche Snippets
Stable vs Canary Vergleich nach Version
promql histogram_quantile(0. 95,
sum by (le, version) (rate(http_request_duration_seconds_bucket{version=~"stable canary"}[5m]))
)
5xx-Fehler auf Routen
promql topk(5,
sum by (route) (rate(http_requests_total{status=~"5.."}[5m]))
)
CPU-Sättigung des Containers
promql rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1
Zuordnung von Metriken zu Traces (Beispiele enthalten)
promql sum (rate (http_request_duration_seconds_bucket[5m])) by (le) # clickable to the track
18) Schlussfolgerung
Prometheus + Grafana ist der De-facto-Standard für Metriken. Semantik und Disziplin gewinnen: RED/USE, ordentliche Label's, Histogramme unter SLO, Recording Rules und SLO Alerts. Fügen Sie HA und Langzeitspeicherung, Release-Annotationen und Auto-Rollback-Integration hinzu - und Sie erhalten eine schnelle, skalierbare und kostengünstige Metrikkontur, die Ihnen hilft, Entscheidungen in der Produktion zu treffen.