Betrieb und Verwaltung der Alerta- → nach Systemkapazität

Alerts nach Systemkapazität

1) Warum es notwendig ist

Kapazitive Alerts warnen schon lange vor dem Vorfall davor, sich den technischen Grenzen zu nähern: „Wir sind bei 80% der Decke - es ist Zeit zu skalieren“. Für Lebensmittelgeschäfte geht es direkt ums Geld: verpasste Wetten/Einzahlungen, Sessions-Drops, Live-Gaming-Verzögerungen und Anbieterausfälle = Umsatzeinbußen, Reputation, Strafen und Pullbacks.

• Es ist vorhersehbar, Spitzenlasten (Events, Turniere, Streams, große Kampagnen) standzuhalten.
• Schalten Sie Auto-Scaling rechtzeitig ein und planen Sie die Kapazität uplift.
• Reduzieren Sie den Lärm und wecken Sie „auf den Punkt“, wenn SLO/Geld gefährdet ist.
• Geben Sie Ingenieuren durch das Runbook genaue Empfehlungen.

2) Grundbegriffe

Kapazität (Capacity): Maximal stabile Bandbreite (RPS/TPS, Anschlüsse, IOPS, Durchlauf).
Headroom: Marge zwischen aktueller Last und Limits.
SLO/SLA: Ziele für Verfügbarkeit/Reaktionszeit; Alerts müssen „SLO-aware“ sein.
Burn-Rate: Geschwindigkeit der „Verbrennung“ des SLO-Budgets für Fehler/Latenz.
High/Low Watermark: obere/untere Ebenen für Alarme und Auto-Recovery.

3) Signalarchitektur und Datenquellen

Telemetrie: Metriken (Prometheus/OTel), Logs (ELK/ClickHouse), Traces (OTel/Jaeger).
Layer-Ansatz: Alerts nach Layer (Edge → API → Business Services → Warteschlangen/Streams → DB/Caches → Datei-/Objektspeicher → externe Anbieter).
Kontext: Ficheflagen, Releases, Marketingkampagnen, Turniere, Geo-Ausrichtung.
Zwischenfall-Reifen: Alertmanager/PagerDuty/Opsgenie/Slack; Einrasten in das Runbook und die Eskalationsmatrix.

4) Schlüsselmetriken nach Schichten (was zu überwachen ist und warum)

Edge / L7

RPS, 95-/99-Perzentil Latenz, Fehlerrate (5xx/4xx), offene Verbindungen.
Rate-limits/quotas, drops на CDN/WAF/Firewall.

API-шлюз / Backend-for-Frontend

Saturation durch Worker/Work-Pool, Warteschlange von Anfragen, Timeouts zu Downstreams.
Anteil der Degradation (Fallbacks, Circuit-Breakers).

Warteschlangen/Streaming (Kafka/Rabbit/Pulsar)

Lag/consumer delay, backlog growth rate, throughput (msg/s, MB/s).
Partition skew, rebalancing churn, ISR (für Kafka), retrai/Großvater-Leiter.

Asynchrone Worker

Zeitüberschreitung bei Vorgängen, Länge der Warteschlange, Prozentsatz überfälliger SLA-Vorgänge.
CPU/Memory/FD-Sättigung in Pools.

Caches (Redis/Memcached)

Trefferverhältnis, Latenz, Bewertungen, verwendeter Speicher, verbundene Clients/ops/s.
Cluster: Slots/Replikate, Failover-Events.

БД (PostgreSQL/MySQL/ClickHouse)

Active connections vs max, lock waits, replication lag, buffer/cache hit.
IOPS, read/write latency, checkpoint/flush, bloat/fragmentation.

Objekt-/Dateispeicher

PUT/GET latency, 4xx/5xx, egress, requests/sec, provider limits.

Externe Anbieter (Zahlungen/KUS/Spieleanbieter)

TPS Limits, Fenster QPS, Fehlerrate/Timeout, Warteschlange Retrays, „Kosten pro Anruf“.

Infrastruktur

CPU/Memory/FD/IOPS/Netzwerk-Sättigung auf Knoten/Pods/ASG.
HPA/VPA Veranstaltungen, Pending Pods, Container OOM/Throttling.

5) Arten von kapazitiven Alerts

1. Statische Schwellenwerte

Einfach und unkompliziert: 'db _ connections> 80% max'. Gut als „Signal-Beacon“.

2. Adaptive (dynamische) Schwellenwerte

Basierend auf Saisonalität und Trend (Rolling Windows, STL-Zerlegung). Sie erlauben den Fang „ungewöhnlich hoch für diese Stunde/Tag der Woche“.

3. SLO-orientiert (Burn-Rate)

Sie werden ausgelöst, wenn die Geschwindigkeit des error-budget-Durchfressens den SLO im X-Stunden-Horizont trifft.

4. Prognostisch (Prognose-Warnungen)

„Nach 20 Minuten mit dem aktuellen Trend wird die Warteschlange 90% erreichen“. Verwenden Sie eine lineare/Robust/Prophet-ähnliche Vorhersage auf kurzen Fenstern.

5. Zusammengesetzte (Multi-Signal)

Trigherrali bei der Kombination: "queue _ lag ↑" + "consumer _ cpu 85%" + "autoscaling bei max' →" braucht einen manuellen Eingriff ".

6) Schwellenwertpolitik und Anti-Lärm

• Nach oben: Warnung 70-75%, Kreta 85-90%. Nach unten: Hysterese 5-10 pp. Um nicht „an der Schwelle zu sägen“.

• „for: 5m“ für Kreter, „for: 10-15m“ für Warnungen. Nachtmodus: Das Unkritische in einen Chat ohne Paging rotieren.

• Gruppieren Sie nach Service/Cluster/Geo, um keine Incident-Karten zu produzieren.

• Wenn der KYC-Anbieter auf Out- und API-Fehler ist die Folge - Paging des Eigentümers der Integration, nicht alle Verbraucher.

• Erhöhen Sie während der Lagerzeit die Lärmschwellen für „erwartetes Wachstum“, lassen Sie SLO-Alerts jedoch intakt.

7) Regelbeispiele (Pseudo-Prometheus)

ALERT PostgresConnectionsHigh
IF (pg_stat_activity_active / pg_max_connections) > 0. 85
FOR 5m
LABELS {severity="critical", team="core-db"}
ANNOTATIONS {summary="Postgres connections >85%"}

ALERT StreamBacklogAtRisk
IF (kafka_consumer_lag > 5_000_000 AND rate(kafka_consumer_lag[5m]) > 50_000)
AND (hpa_desired_replicas == hpa_max_replicas)
FOR 10m
LABELS {severity="critical", team="streaming"}

ALERT ApiLatencySLOBurn
IF slo_latency_budget_burnrate{le="300ms"} > 4
FOR 15m
LABELS {severity="page", team="api"}
ANNOTATIONS {runbook="wiki://runbooks/api-latency"}

ALERT RedisEvictions
IF rate(redis_evicted_keys_total[5m]) > 0
AND (redis_used_memory / redis_maxmemory) > 0. 8
FOR 5m
LABELS {severity="warning", team="caching"}

ALERT PSPThroughputLimitNear
IF increase(psp_calls_total[10m]) > 0. 9 psp_rate_limit_window
FOR 5m
LABELS {severity="warning", team="payments", provider="PSP-X"}

8) SLO-Ansatz und Geschäftspriorität

Vom Signal zur Auswirkung auf das Geschäft: Kapazitätsalerts sollten sich auf das Risiko für SLO beziehen (spezifische Spiele/Geo/GGR-Metriken, Einzahlungsumwandlung).
Multi-Level: Warnungen für den On-Call-Dienst; Kreta - die Seite des Domain-Inhabers; SLO-Drop ist ein Major-Vorfall und ein Team „konsolidierter“ Kanal.
Ficheflags der Degradation: automatische Reduzierung der Belastung (teilweise nur lesen, Schneiden von schweren Fich, Verringerung der Häufigkeit von Jackpot-Broadcasts, Ausschalten von „schweren“ Animationen in Live-Spielen).

9) Auto-Scaling und „richtige“ Auslöser

HPA/VPA: Ziel nicht nur für CPU/Speicher, sondern auch für Geschäftskennzahlen (RPS, queue lag, p99 latency).
Warm-up-Timings: Kaltstart und Anbieterlimits (ASG-Spin-up, Container-Builder, Caches-Warm-up) berücksichtigen.
Guardrails: Stoppbedingungen bei lawinenartigem Fehlerwachstum; Schutz vor „Skeilim Problem“.
Capacity-playbooks: wo und wie man einen Shard/Party/Replikat hinzufügt, wie man Traffic auf Regionen umverteilt.

10) Prozess: vom Entwurf bis zum Betrieb

1. Limit Mapping: Sammeln Sie „wahre“ Bottleneck-Limits für jede Schicht (max conns, IOPS, TPS, quotas Provider).
2. Auswahl von Metriken-Prädiktoren: Welche Signale zeigen am frühesten „nach N Minuten ruhen“ an.
3. Design der Schwellen: high/low + SLO-burn + composite.
4. Runbook für jedes Kreta: Diagnoseschritte („was zu öffnen“, „welche Befehle“, „wohin zu eskalieren“), drei Handlungsoptionen: schnelles Umgehen, Skalieren, Degradieren.
5. Testen: Lastsimulationen (Chaos/Spieltage), „Trockenläufe“ von Alerts, Anti-Noise-Check.
6. Revue und Adoption: Signalinhaber = Servicebesitzer. Ohne Besitzer gibt es keine Seite.
7. Retrospektiven und Tuning: wöchentliche Analyse von False/Missing; Metrik „MTTA (ack), MTTD, MTTR, Rauschen/Signalverhältnis“.

11) Anti-Muster

CPU> 90% ⇒ Panik: ohne Korrelation mit Latenz/queues kann dies normal sein.
„Eine Schwelle für alle“: Verschiedene Regionen/Zeitzonen - unterschiedliche Verkehrsprofile.
Alert ohne Runbook: Eine Seite ohne klare Aktion erschöpft den On-Call.
Anbieterblindheit: Externe Quoten/Limits sind oft die ersten, die Szenarien „durchbrechen“ (PSP, KYC, Fraud, Spieleanbieter).
Keine Hysterese: „Sägen“ an der Grenze von 80 %/79%.

12) Funktionen von iGaming/Finplatforms

Peaks nach Zeitplan: Prime Time, Turnierfinale, große Spiele; Erhöhen Sie die Ziel-Replikate im Voraus und füllen Sie die Caches.
Live-Streams und Jackpots: Ausbrüche von Broadcast-Events → Limits bei Brokern/Websites.
Zahlungen und KYC: Anbieterfenster, Betrugsbekämpfung; halten Ersatzrouten und „grace-Modus“ Einlagen.
Geo-Balance: Lokale Ausfälle des Anbieters sollen den Verkehr in die Nachbarregion lenken, wo es einen Kopfraum gibt.
Haftung: Mit dem Risiko des Verlustes von Wetten/Jackpots - Sofortige Seite an das Domain-Team + Business Alert.

13) Dashboards (Mindestsatz)

Capacity Overview: Hauptraum nach Schichten, Top 3 Risikobereiche, Burn-Rate SLO.
Stream & Queues: lag, backlog growth, consumer saturation, HPA state.
DB & Cache: Anschlüsse, repl-lag, p95/p99 Latenz, Trefferverhältnis, Bewertungen.
Anbieter: TPS/Fenster/Kontingente, Timeouts/Fehler, Kosten für Anrufe.
Release/Feature Kontext: Releases/Ficheflags neben Kurven.

14) Checkliste Umsetzung

• Liste der „wahren“ Limits und Besitzer.
• Karte der metrischen Prädiktoren + Verbindungen zwischen Schichten.
• Statische Schwellen + Hysterese.
• SLO-Burn-Alerts auf kritischen Pfaden (Einzahlung, Wette, Live-Spielstart).
• Prognostische Warnungen in der Warteschlange/Streams/Connects.
• Suppression/maintenance des Fensters; Anti-Lärm der Politik.
• Runbook 'und mit Teams, Charts, Ficheflags der Degradation.
• Wöchentliche Analyse von False Positives und Tuning.
• Erfassung von Marketingkampagnen und Veranstaltungskalendern.

15) Beispiel einer Runbook-Vorlage (abgekürzt)

Signal: „StreamBacklogAtRisk“

Ziel: Ein Wachstum von> 10 Mio. Lag und eine Verzögerung der Behandlungen von> 5 Min.

1. Überprüfen Sie' hpa _ desired/max', throttle/oom in den Pods.

2. Siehe' rate (lag)', Verteilung nach Parteien (skew).

3. Überprüfen Sie den Broker (ISR, under-replicated, network).

• Erhöhen Sie consumer-replicas um + N, erhöhen Sie max-in-flight.
• Aktivieren Sie einen Prioritätspool für „kritische Punkte“.
• Die Häufigkeit von Sekundärbehandlungen/-maßnahmen vorübergehend herabsetzen.
• Wenn 'ASG at max' - fordern Sie einen temporären Uplift von der Cloud an; parallel - den Abbau schwerer Funktionen einbeziehen.
• Rollback: Zurück zum Profil „normaler Verkehr“ nach 'lag <1 Million' 15 Minuten.
• Eskalation: Kafka Cluster Owner, dann SRE-Plattform.

16) KPIs und Signalqualität

Coverage:% der kritischen Pfade, die durch kapazitive Alerts geschlossen werden.
Noise/Signal: nicht mehr als 1 falsche Seite pro On-Call/Woche.
MTTD/MTTR: Kapazitive Vorfälle werden ≤5 Minuten vor SLO-Stößen erkannt.
Proactive saves: Anzahl der verhinderten Vorfälle (nach Post-Mortems).

17) Schnellstart (konservative Standardwerte)

DB: Warnung 75% der Anschlüsse/IOPS/lat; Kreta 85%, Hysterese 8-10 pp.
Caches: 'hit <0. 9 'Und' evictions> 0'> 5 min - Warnung; 'used _ mem> 85%' - Kreta.
Warteschlangen: 'lag' Wachstum> 3 σ des Durchschnitts für 30d + 'hpa at max' - Kreta.
API: `p99 > SLO1. 3 '10 min - Warnung;' burn-rate> 4 '15 min - Kreta.
Anbieter: „throughput> 90% der Quote“ - Warnung; „timeouts> 5%“ - Kreta.

18) FAQ

F: Warum nicht einfach „CPU> 80%“ alertieren?
A: Ohne Latenz/Warteschlangen-Kontext ist es ein Rauschen. Die CPU selbst ist nicht gleich Risiko.

F: Sind adaptive Schwellenwerte erforderlich?
A: Ja, für die tägliche/wöchentliche Saisonalität - reduzieren Sie die Fehlalarme.

F: Wie kann man Marketing/Events berücksichtigen?
A: Kampagnenkalender → Anmerkungen auf Grafiken + temporäre Anti-Noise-Anpassung, aber SLO-Alerts nicht berühren.