Überwachungs-Stack

1) Warum Sie einen Beobachtbarkeits-Stack benötigen

Schnelle RCAs und reduzierte MTTRs: von Symptom zu Ursache in Minuten.
SLO-Management: Fehler-/Latenzmessung, Alerting nach fehlerhaftem Budget.
Release-Kontrolle: kanarische Berechnungen, Auto-Rollback nach Metriken.
Sicherheit und Audit: Zugangswege, Anomalien, Legal Hold.
FinOps-Transparenz: Kosten für Speicherung/Anfragen, Cost-per-SLO.

Methoden: Goldene Signale (Latenz/Verkehr/Fehler/Sättigung), ROT, USE.

2) Grundlegende Stack-Architektur

Komponenten nach Lagen

Sammlung/Agenten: Exporteure, Promtail/Fluent Bit, OTel SDK/Auto-Instr, Blackbox-probes.
Шина/ingest: Prometheus remote_write → Mimir/Thanos, Loki distributors/ingesters, Tempo/Jaeger ingesters.
Speicher: Objekt- S3/GCS/MinIO (lange Kälte), SSD (heiße Reihen).
Anfragen/Visualisierung: Grafana (Panels, SLO-Widgets), Kibana (wenn ELK).
Management: Alertmanager/Graphana-Alertas, Service-Katalog, RBAC, Secret Manager.

Bereitstellungsmuster

Managed (Grafana Cloud/Cloud Services) - schnell und teurer auf Volumen.
Self-hosted in K8s - volle Kontrolle, muss betrieben werden und FinOps.

3) Datenstandards: einheitliches „Beobachtbarkeitsschema“

3. 1 Metriken (Prometheus/OpenMetrics)

Obligatorische Etiketten: „env“, „region“, „cluster“, „namespace“, „service“, „version“, „tenant“ (wenn multi-tenant), „endpoint“.
Benennung: 'snake _ case', Suffixe'_ total','_ seconds','_ bytes'.
Histogramme: feste' Buckets'(SLO-orientiert).
Kardinalität: Keine' user _ id', 'request _ id' in Labels aufnehmen.

3. 2 Protokolle

Format: JSON; erforderliche Felder 'ts', 'level', 'service', 'env', 'trace _ id', 'span _ id', 'msg'.
PII: Maskierung des Agenten (PAN, Token, E-Mail usw.).
Loki-Labels: nur niedrige Kardinalität ('app', 'namespace', 'level', 'tenant').

3. 3 Spuren

OTel Semantik: 'service. name`, `deployment. environment`, `db. system`, `http.`.
Sampling: Die Zielpfade von p99 sind 'always _ on '/tail-sampling, der Rest ist' parent/ratio'.
ID einbetten: 'trace _ id/span _ id' in Logs und Metriken (Labels/Fields) eintragen.

4) Korrelation M-L-T (Metrics/Logs/Traces)

Aus dem Alert-Diagramm (Metrik) → gefilterte Protokolle durch 'trace _ id' → eine bestimmte Spur.
Von der Spur (Slow Span) → die Abfrage der Metriken eines bestimmten Backends im Span-Intervall.
Drilldown-Schaltflächen in den Bereichen: „zu den Protokollen“ und „zu den Spuren“ mit Variablensubstitution ('$ env','$ service','$ trace _ id').

5) OpenTelemetry Collector: Referenz-Pipeline

yaml receivers:
otlp:
protocols: { http: {}, grpc: {} }
prometheus:
config:
scrape_configs:
- job_name: kube-nodes static_configs: [{ targets: ['kubelet:9100'] }]

processors:
batch: {}
memory_limiter: { check_interval: 1s, limit_mib: 512 }
attributes:
actions:
- key: deployment. environment value: ${ENV}
action: insert tail_sampling:
decision_wait: 5s policies:
- name: errors type: status_code status_code: { status_codes: [ERROR] }
- name: important-routes type: string_attribute string_attribute: { key: http. target, values: ["/payments","/login"] }
- name: probabilistic type: probabilistic probabilistic: { sampling_percentage: 10 }

exporters:
otlphttp/mimir: { endpoint: "https://mimir/api/v1/push" }
otlphttp/tempo: { endpoint: "https://tempo/api/traces" }
loki:
endpoint: https://loki/loki/api/v1/push labels:
attributes:
env: "deployment. environment"
service: "service. name"

service:
pipelines:
metrics: { receivers: [prometheus, otlp], processors: [memory_limiter, batch], exporters: [otlphttp/mimir] }
logs:   { receivers: [otlp], processors: [batch], exporters: [loki] }
traces:  { receivers: [otlp], processors: [memory_limiter, attributes, tail_sampling, batch], exporters: [otlphttp/tempo] }

6) Alerting: SLO und Multi-Burn

Die Idee: Das Alertim liegt nicht auf der Ebene „CPU> 80%“, sondern auf dem Verbrauch des Error Budgets.

promql
5-minute error rate err_ratio_5m =
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m]))

Quick burn (1m window)
(err_ratio_1m / (1 - SLO)) > 14. 4

Slow burn (30m)
(err_ratio_30m / (1 - SLO)) > 2

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

7) Dashboards: Ordnerstruktur

00_Overview - Plattform: SLO, p95, 5xx%, Kapazität, aktive Vorfälle.
10_Services - nach Dienstleistungen: RPS, p95/p99, Fehler, Veröffentlichungen (Anmerkungen).
20_Infra - K8s/Knoten/Geschichten/Netzwerk, Etcd, Controller.
30_DB/Queues — PostgreSQL/Redis/Kafka/RabbitMQ.
40_Edge/DNS/CDN/WAF - ingress, LB, WAF-Regeln.
50_Synthetic - Aptime und Headless-Szenarien.
60_Cost/FinOps - Lagerung, Anfragen, heiß/kalt, Prognose.

Jedes Panel: Beschreibung, Einheiten, Besitzer, Runbook-Link, Drilldown.

8) Logs: LogQL Workshop

logql
API errors
{app="api", level="error"}     = "Exception"

Nginx 5xx in 5 minutes
{app="nginx"}      json      status=~"5.."      count_over_time([5m])

Extract Fields
{app="payments"}      json      code!=""      unwrap duration      avg()

9) Tracks: TraceQL und Tricks

{ service. name = "api" }      duration > 500ms

{ name = "HTTP GET /order" }      child. span. name = "SELECT" & child. duration > 50ms

10) Synthetik und Aptime

Blackbox-Exporteur: HTTP/TCP/TLS/DNS-Tests aus ≥3 Regionen/ASN.
Headless: Login/Deposit-Skripte nach Zeitplan.
Quorum-Alerts: Auslösen, wenn ≥2 Regionen einen Fehler sehen.
Status-Seite: automatische Updates + manuelle Kommentare.

11) Lagerung und Retention

Metriken: heißer 7-30 Tage (schnelle Reihen), Downsampling/Aufzeichnungsregeln, kalt - Objektspeicher (Monate).
Protokolle: heiß 3-7 Tage, dann - S3/GCS mit Index (Loki chunk store/ELK ILM).
Traces: 3-7 Tage' always _ on'+ Langzeitlagerung für Proben (tail-sampled/culling).

• Rollover in Größe und Zeit; Budget für Anfragen (Kontingente/Limits).
• Separate Richtlinien für prod/stage und Sicherheitsdaten.

12) Multi-Tenant und Zugänge

Teilen Sie durch 'tenant '/' namespace '/Spaces, Index-Muster und Auflösungen.
Tagging Ressourcen für die Abrechnung: 'tenant', 'service', 'team'.
Importierte Dashboards/Alerts befinden sich in den Räumen bestimmter Teams.

13) Sicherheit und Compliance

TLS/mTLS von Agenten zu Beckends, HMAC für private Gesundheit.
Read/Write RBAC, Audit aller Anfragen und Alert.
PII-Revision am Rand; das Verbot von Geheimnissen in Protokollen; DSAR/Legal Hold.
Isolation: separate Cluster/Nijmspaces für sensible Domänen.

14) FinOps: Kosten der Beobachtbarkeit

Wir reduzieren die Kardinalität von Labels und die Logik in ingest (und nicht in Anfragen).
Track Sampling + Zielalways-on für kritische Pfade.
Downsampling/Recording-Regeln für schwere Aggregationen.
Archivierung des seltenen Zugriffs auf Cold Object.
Метрики: `storage_cost_gb_day`, `query_cost_hour`, `cost_per_rps`, `cost_per_9`.

15) CI/CD und Beobachtbarkeitstests

Linting von Metriken/Logs in CI: Verbot der „Explosion“ der Kardinalität, Überprüfung von Histogrammen/Einheiten.
Contract-Beobachtbarkeitstests: obligatorische Metriken/Logfelder, 'trace _ id' in middleware.
Canary: Anmerkungen zu Releases auf Graphen, SLO-Auto-Rollback.

16) Beispiele: schnelle Anfragen

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

promql sum by (namespace, pod) (rate(container_cpu_cfs_throttled_seconds_total[5m])) > 0

promql max by (topic, group) (kafka_consumergroup_lag)

Von Protokollen zu Spuren (Loki → Tempo): Übergeben Sie' trace _ id 'als Link auf Tempo UI/Dashboard.

17) Stapelqualität: Checkliste

• Harmonisierte Metrik-/Log-/Track-Diagramme und Einheiten.
• 'trace _ id' in Protokollen und Metriken, Drilldown aus Panels.
• Multi-burn SLO-Alerts ohne Flapping (quorum/multi-window).
• Downsampling, Abfragequoten, Pitch/Range Limits.
• Retention und Speicherklassen werden dokumentiert und angewendet.
• RBAC/Audit/PII-Revision enthalten.
• Dashboards: Besitzer, Runbooks, ≤2 -3 Bildschirme, schnelle Antwort.
• FinOps-Dashboard (Volumen, Kosten, Top-Talker).

18) Implementierungsplan (3 Iterationen)

1. MVP (2 Wochen): Prometheus→Mimir, Loki, Tempo OTel Collector; grundlegende Dashboards und SLO-Alerts; Blackbox-Test.
2. Scale (3-4 Wochen): Tail-Sampling, Downsampling, Multi-Region ingest, RBAC/Spaces, FinOps-Dashboards.
3. Pro (4 + Wochen): SLO-Auto-Rollback, Schlüsselpfad-Headless-Synthetik, Legal Hold, SLO-Portfolio und Reporting.

19) Anti-Muster

„Schöne Grafiken ohne SLO“ - keine Aktion → kein Nutzen.
Etiketten mit hoher Kardinalität ('user _ id', 'request _ id') sind eine Explosion von Erinnerung und Kosten.
Logs ohne JSON und ohne' trace _ id'- keine Korrelation.
Alerts auf Ressourcen statt Symptome - Lärm und On-Call-Burnout.
Fehlende Retention-Politik - unkontrollierte Kostensteigerungen.

20) Mini-FAQ

Was soll man wählen: Loki oder ELK?
ELK für komplexe Suche/Facetten; Loki - billiger und schneller für Grep-ähnliche Szenarien. Oft wird ein Hybrid verwendet.

Braucht jeder Spuren?
Ja, zumindest auf den Schlüsselpfaden (Login, Checkout, Payments) mit Tail-Sampling - das beschleunigt die RCA drastisch.

Wie fange ich bei Null an?
OTel Collector → Mimir/Loki/Tempo → Basis-SLOs und Blackbox-Tests → dann Dashboards und Burn-Alerts.

Summe

Der Beobachtbarkeits-Stack ist keine Sammlung unterschiedlicher Tools, sondern ein kohärentes System: einheitliche Datenstandards → Korrelation von M-L-T → SLO-Alerting und Synthetics → Sicherheit und FinOps. Erfassen Sie Schaltungen, Etikettendisziplin und Retention, verbinden Sie OTel, fügen Sie Drilldown und Auto-Rollback hinzu - und Sie erhalten eine überschaubare Zuverlässigkeit mit überschaubaren Kosten.