Überwachung der Infrastruktur

Überwachung der Infrastruktur

1) Ziele und Rahmen

• Warnung vor Fehlern vor dem Benutzer (Früherkennung).
• Diagnose der Grundursache (von Symptom zu Ursache).
• Unterstützen Sie SLO-Gatting-Releases und Auto-Rollbacks.
• Füttere die Post-Incident-Analyse (evidence as data).

Grundprinzipien: Observable by Design, weniger Lärm - mehr Signale, Automatisierung von Reaktionen, ein einheitliches Wahrheitspanel.

2) Der Dreiklang der Beobachtbarkeit

Die Metriken (timeseries): skorost/spros/oschibki/nassyschtschenije (USE/RED).
Protokolle: Ereignisdetaillierung mit Kontext; keine Geheimnisse/PII enthalten.
Traces: Verteilte Behandlungen mit Ursache-Wirkungs-Beziehungen.

• Profiling (CPU/heap/lock/io), eBPF für die Systemebene.
• Ereignisse/Audits (K8s Events, Änderungen der Config/Secrets).

3) SLI/SLO/SLA - Qualitätssprache

SLI (Indikator): 'availability', 'error _ rate', 'p95 _ latency', 'queue _ lag'.
SLO (Ziel): "erfolgreiche Anfragen ≥ 99. 9% in 30 Tagen".
Error Budget: zulässige Abweichung; wird für Auto-Stop-Releases verwendet.

yaml service: "api-gateway"
slis:
- name: success_rate query_good: sum(rate(http_requests_total{status!~"5.."}[5m]))
query_total: sum(rate(http_requests_total[5m]))
slo: 99. 9 window: 30d

4) Überwachungsschichtkarte

1. Hosts/VMs/Nodes: CPU/Load/Steal, RAM/Swap, Disk IOPS/Latency, Filesystem.
2. Netzwerk/LB/DNS: RTT, Pakete/Drops, Backlog, SYN/Timeout, health-probes.
3. Kubernetes/Orchestrator: API-Server, etcd, Controller, Scheduler; pods/nodes, pending/evicted, throttling, kube-events.
4. Dienstleistungen/Container: RED (Rate/Errors/Duration), readiness/liveness.
5. Datenbanken/Caches: QPS, lock wait, replication lag, buffer hit, slow queries.
6. Warteschlangen/Busse: consumer lag, requeue/dead-letter, throughput.
7. Speicher/Cloud: S3/Blob Fehler und Latenz, 429/503 von Anbietern.
8. Perimetergrenzen: WAF/Rate Limits, 4xx/5xx entlang der Routen, CDN.
9. Synthetik: HTTP-Scriptchecks (Einzahlung/Ausgabe), TLS/Zertifikate.
10. Wirtschaft/Kapazität: Kosten pro Service, Utilization, Headroom.

5) Whitebox и Blackbox

Whitebox: Exporteure/SDKs innerhalb der Dienste (Prometheus, OpenTelemetry).
Blackbox: externe Proben aus verschiedenen Regionen (Availability, Latency, TLS Expiry).
Kombinieren: „Merkmal außen“ + „Diagnose innen“.

yaml modules:
https_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"

6) Kubernetes: Schlüsselsignale

Кластер: `apiserver_request_total`, `etcd_server_has_leader`, etcd fsync.
Узлы: `container_cpu_cfs_throttled_seconds_total`, `node_pressure`.
Pods: Pending/CrashLoopBackOff, OOMKilled, Restarts.
Pläne/Limits: Requests vs Limits, PodDisruptionBudget, HPA/VPA.
Netzwerk: NetworkPolicy drops, conntrack exhaustion.

Дашборды: «Cluster health», «Workload saturation», «Top erroring services».

7) DB und Warteschlangen

PostgreSQL/MySQL: replication lag, deadlocks, slow query %, checkpoint I/O.
Redis/Memcached: hit ratio, evictions, rejected connections.
Kafka/RabbitMQ: consumer lag, unacked, requeue, broker ISR, disk usage.

8) RED/USE Metriken und Geschäftskorrelationen

RED: `rate` (RPS), `errors` (4xx/5xx), `duration` (p95/p99).
USE (für Ressourcen): Utilization, Saturation, Errors.
Mit dem Produkt in Verbindung bringen: Einzahlungen/Auszahlungen Erfolg, Betrugsflaggen, Umbau - das sind die „Wächter“ beim Kanarienauswurf.

9) Die Struktur der Warnung

Tier-1 (Paige): Vorfälle, die das SLO betreffen (Verfügbarkeit, 5xx, Latenz, Ausfall von clusterkritischen Komponenten).
Tier-2 (Ticket): Kapazitätsabbau, Fehlerwachstum ohne Auswirkungen auf SLO.
Tier-3 (Informationen): Trends, prädiktive Kapazität, auslaufende Zertifikate.

Regeln für Eskalationen: Zeit der Stille/Komprimierung von Duplikaten, On-Call-Rotation, „follow-the-sun“.

yaml route:
group_by: ["service","severity"]
receiver: "pager"
routes:
- match: { severity: "critical" }
receiver: "pager"
- match: { severity: "warning" }
receiver: "tickets"

10) Prometheus Regelbeispiele

10. 1 Fehler 5xx mit SLO-Schwelle

yaml groups:
- name: api rules:
- alert: HighErrorRate expr:
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m])) > 0. 005 for: 10m labels: { severity: "critical", service: "api-gateway" }
annotations:
summary: "5xx > 0. 5% 10m"
runbook: "https://runbooks/api-gateway/5xx"

10. 2 Brennen von Error-Budget (Multi-Window Burn)

yaml
- alert: ErrorBudgetBurn expr:
(1 - (
sum(rate(http_requests_total{status!~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
)) > (1 - 0. 999) 14 for: 5m labels: { severity: "critical", slo: "99. 9" }
annotations: { summary: "Fast burn >14x for 5m" }

10. 3 Systemsättigung (CPU Throttling)

yaml
- alert: CPUThrottlingHigh expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1 for: 10m labels: { severity: "warning" }
annotations: { summary: "CPU throttling >10%" }

11) Protokolle: Sammlung, Normalisierung, Retention

Standardisierung: JSON-Logs: 'ts', 'level', 'service', 'trace _ id', 'user/tenant'.
Pipeline: Agent (Fluent Bit/Vector) → Puffer → Index/Speicher.
Editorial: PII-Maskierung/Geheimnisse am Rand.
Retention: schnelle Lagerklasse (7-14 Tage), „kaltes“ Archiv (30-180 Tage).
Semantik: error budgets/deprecates - einzelne Kanäle.

12) Traces und OpenTelemetry

Instrumentieren Sie Eingangspunkte (Gateway), kliyent→servis Anrufe, DB/Caches/Warteschlangen.
Binden Sie Metriken an Trace-Attribute (Beispiele) für eine schnelle Navigation.
OTel Collector als zentrales Gateway: Filterung, Sampling, Export in ausgewählte Becends.

yaml receivers: { otlp: { protocols: { http: {}, grpc: {} } } }
processors: { batch: {}, tail_sampling: { policies: [ { name: errors, type: status_code, status_codes: [ERROR] } ] } }
exporters: { prometheus: {}, otlp: { endpoint: "traces. sink:4317" } }
service:
pipelines:
metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }
traces: { receivers: [otlp], processors: [tail_sampling,batch], exporters: [otlp] }

13) Synthetik und externe Kontrollen

HTTP-Runs von Business-Szenarien (Login, Einzahlung, Ausgabe, Kauf).
TLS/Domain: Laufzeit der Zertifikate/CAA/DNS health.
Regionalität: Stichproben der wichtigsten Länder/Anbieter (Routing/Blocklisten).
Synthetik muss alertieren, wenn sie für den Benutzer nicht verfügbar ist, selbst bei grüner interner Telemetrie.

14) Profiling und eBPF

Kontinuierliches Profiling: Identifizierung heißer Funktionen, Sperren.
eBPF: Systemereignisse (Syscalls, TCP retransmits), auf dem Markt mit minimalem Overhead.
Profil-Alerts ohne Stranizing (Tickets) und für Regressionen nach der Veröffentlichung - als Rollback-Signal.

15) Dashboards und das „Wahrheitspanel“

1. Platform Overview: SLI/SLO nach Schlüsseldiensten, Error-Budget, Alerts.

2. API RED: RPS/ERRORS/DURATION nach Routen.

3. K8s Cluster: control-plane, узлы, capacity headroom.

4. DB/Cache: lag/locks/slow query %, hit ratio.

5. Queues: backlog/lag, failed/repeat.

6. Per-release: Vergleich der Vorher/Nachher-Metriken (Kanarienfenster).

7. FinOps: cost per namespace/service, idle/oversized ресурсы.

16) Vorfälle, Alert Noise und Eskalation

Deduplizierung: Gruppierung nach Service/Ursache, Unterdrückung von Kaskaden.
Stille/Wartung: Releases/Migrationen sollten nicht alles rot „färben“.
Runbooks: jede kritische Alert mit Diagnoseschritten und einem „Button“ des Rollbacks.
Postmortem: Zeitleiste, was gelernt wurde, welche Signale hinzugefügt/gereinigt wurden.

17) Sicherheit bei der Überwachung

RBAC zum Lesen/Bearbeiten von Regeln/Datasors.
Geheimnisse: Exporteur/Agent-Token - über Secret Manager.
Isolation: Metriken von Kunden/Tenanten - in separate Räume/Leiben.
Integrität: Agenten-/Bildsignatur, Config über GitOps (Merge Revue).

18) Finanzen und Kapazität (FinOps)

Quoten und Budgets; Alerts für abnormales Wachstum.
Right-Sizing: Analyse von Anfragen/Limits, CPU/RAM-Recycling, Spot-Instances für nicht kritische Aufgaben.
„Cost per request/tenant“ als Leistungskennzahl.

19) Anti-Muster

Nur Infrastruktur-Metriken ohne benutzerdefinierte SLIs.
100 + Alert „über alles“ → On-Call-Blindheit.
Logs als einzige Quelle (ohne Metriken und Tracing).
Mutable Dashboards ohne Versionierung/Revue.
Das Fehlen von Synthetik: „alles ist grün“, aber die Front ist nicht zugänglich.
Keine Verknüpfung mit Releases: Man kann nicht beantworten, „was sich zum Zeitpunkt X verändert hat“.

20) Implementierung Checkliste (0-60 Tage)

0-15 Tage

Definieren Sie SLI/SLO für 3-5 Schlüsseldienste.
Grundlegende Exporteure/Agenten einbeziehen, JSON-Protokolle standardisieren.
Konfigurieren Sie Tier-1-Alerts (Verfügbarkeit, 5xx, p95).

16-30 Tage

Fügen Sie Synthetik nach kritischen Szenarien hinzu.
Trails (OTel) auf Input/Critical Services aktivieren.
Dashboards „Per-release“ und error-budget burn-rules.

31-60 Tage

DB/Warteschlangen/Cache mit fortgeschrittenen Signalen abdecken.
eBPF/Profiling für High-CPU-Dienste implementieren.
GitOps für Regeln/Dashboards/Alert, regelmäßige Geräuschreinigung.

21) Reifegradkennzahlen

Die SLO-Abdeckung der Schlüsseldienste ≥ 95%.
MTTA/MTTR (Ziel: min/zehn Minuten).
Der Anteil der Tier-1-Warnmeldungen, die durch eine Auto-Aktion oder einen schnellen Rollback geschlossen werden.
Das Verhältnis „nützlich „/“ laut “alert> 3: 1.
Synthetische Abdeckung aller „monetären“ Wege = 100%.

22) Anwendungen: Mini-Vorlagen

Prometheus - Barrierefreiheit nach Status-Klassen

yaml
- record: job:http:availability:ratio_rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Grafana - Hinweis für Kanarienvögel

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

Alertmanager - Pflicht und Stille

yaml receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true inhibit_rules:
- source_match: { severity: "critical" }
target_match: { severity: "warning" }
equal: ["service"]

23) Schlussfolgerung

Monitoring ist kein Satz von Zeitplänen, sondern das Betriebssystem SRE: SLI/SLO als Qualitätsvertrag, Metriken/Traces/Logs als Quellen der Wahrheit, Alerts als gesteuertes Signal, Synthetik als „Stimme des Nutzers“, GitOps als Disziplin des Wandels. Erstellen Sie einen einzigen Pfad vom Host bis zur API, binden Sie ihn an Releases und Rollbacks - und die Plattform ist vorhersehbar, schnell und kostengünstig.