GH GambleHub

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).

Semantik:
  • 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.

Basic 'prometheus. yml'(Fragment):
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 p95:
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).
Remote schreiben (Beispiel):
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.

Beispiele für PromQL:
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.

Contact

Kontakt aufnehmen

Kontaktieren Sie uns bei Fragen oder Support.Wir helfen Ihnen jederzeit gerne!

Telegram
@Gamble_GC
Integration starten

Email ist erforderlich. Telegram oder WhatsApp – optional.

Ihr Name optional
Email optional
Betreff optional
Nachricht optional
Telegram optional
@
Wenn Sie Telegram angeben – antworten wir zusätzlich dort.
WhatsApp optional
Format: +Ländercode und Nummer (z. B. +49XXXXXXXXX).

Mit dem Klicken des Buttons stimmen Sie der Datenverarbeitung zu.