Torrent Gear

API und Infrastrukturüberwachungstools

1) Prinzipien: Von Zielen zu Werkzeugen

SLO-first: Wählen und konfigurieren Sie die Tools für die Produktziele (Login, Einzahlung, Wette) und nicht umgekehrt.

Offene Standards: OpenTelemetry (Traces/Metriken/Logs), Prometheus Expositionsformat, Loki JSON-Logs.

Einheitlicher Kontext: 'trace _ id '/' span _ id' in Protokollen und Metriken; Links „dashboard → trace → log“.

Kosten-aware: Kardinalität der Metriken, TTL-Logs, Sampling-Traces - im Voraus.

2) Metriken: Sammeln, Speichern, Visualisieren

Сбор: Prometheus / Agent-режим (VictoriaMetrics Agent, Grafana Agent, OpenTelemetry Collector).

Speicher (TSDB): Prometheus (Single), Thanos/Cortex/Mimir (horizontale Skalierung), VictoriaMetrics (CPU/RAM-Einsparungen).

Visualisierung: Grafana als „Glasscheibe“.

Was ist für API (RED) und Infrastruktur (USE) zu messen:

RED: `rate(requests)`, `error_ratio`, `latency p95/p99` по `route`, `method`, `provider`.
USE: CPU/Mem, file descriptors, connection pools, queue lag, GC pauses.

Nützliche Exporteure:

k8s: kube-state-metrics, node-exporter, cAdvisor, ingress/gateway exporters.
БД/кэши: postgres_exporter, mysql_exporter, redis_exporter, kafka_exporter, rabbitmq_exporter.
Service Mash: Envoy metrics, istio/Linkerd dashboards.
PSP/внешние: custom exporters (webhook success, PSP success ratio, callback latency).

Beispiele für PromQL (Skizzen):

promql
Erfolgsquote der Einlagen (SLI)
sum(rate(ig_payments_requests_total{route="/payments/deposit",status=~"2.."}[5m]))
/
sum(rate(ig_payments_requests_total{route="/payments/deposit"}[5m]))

p95 latency API histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

Sättigung des DB-Verbindungspools db_connections_in_use/ db_connections_max

3) Logs: Suche, Korrelation, Unveränderlichkeit

Stack: OpenSearch/Elasticsearch + Beats/Vector/Fluent Bit oder Grafana Loki (billiger zu speichern, „Log-as-a-Stream“).

Format: JSON mit Standardfeldern 'ts, level, service, env, trace_id, user_pid, route, status, latency_ms'.

Praktiken: PII-Maskierung, WORM-Baketas für Audits, TTL/ILM-Richtlinien, Partitionierung nach 'env/region/brand'.

4) Tracing: Wo Millisekunden verloren gehen

Стек: OpenTelemetry SDK/Collector → Jaeger/Tempo/Honeycomb/New Relic Traces.

Die Politik semplirowanija: 100 % der Fehler, adaptiw für "die langsamen" Anfragen, 1-5 % der Erfolgreichen.

Теги iGaming: `provider`, `psp`, `risk_decision`, `bonus_id`, `market`, `ws_table_id`.

Schnelles Debag-Rezept: Aus dem roten SLO-Graph → Trace der Problemroute → der „dicke“ Span auf dem PSP/Spieleanbieter → das Webhook-Log.

5) APM-Plattformen: wenn „all-in-one“

Kommerzielle Lösungen (Datadog, New Relic, Dynatrace, Grafana Cloud) schließen APM, Logs, Traces, Synthetics, RUM.

Vorteile: Geschwindigkeit der Implementierung, Korrelation „out of the box“. Nachteile: Kosten/Anbieter-Lock.

Hybrid: Kern auf OSS (Prometheus + Grafana + Tempo + Loki), „dorisovat“ Synthetik/Alerting durch kommerzielle Module auf kritischem Flow.

6) Synthetik und RUM: „Außen“ und „Spieleraugen“

Синтетика: Checkly, Grafana Synthetic Monitoring, k6 Cloud, Uptrends, Pingdom, Catchpoint, ThousandEyes.

Skripte: Login → Einzahlung (Sandbox) → Starten des Spiels → Überprüfen des Webhooks.

Geo: EU/LatAm/MEA/APAC, Mobilfunknetze, ASN-Mix.

RUM: Web-SDK (TTFB/LCP/CLS), mobile SDK; Segmentierung nach Land/Netzwerk/Gerät.

7) Kubernetes-Überwachungsflächen

Control plane: etcd, API-server (apiserver_request_total, latency), scheduler/controllermanager.

Data plane: kubelet, CNI, ingress/gateway; `PodDisruptionBudget` и эвикшены.

Autoscale: HPA/VPA/Cluster Autoscaler Metriken und Ereignisse; Warm-Pools.

Netzwerkrichtlinien: drops/deny events, DNS latency.

8) Datenbanken, Warteschlangen, Caches

Postgres/MySQL: Replikations-Lag, Deadlocks, Bloat, WAL, Checkpoint Duration, Timeouts.

Kafka/RabbitMQ: consumer lag, rebalances, queue depth, redeliveries.

Redis: revictions, blocked clients, latency percentiles, replica-lag.

PITR/Backups: Aufgaben der Backup-Operatoren + Dashboard „Zeit bis zur Wiederherstellung“.

9) Netzwerk, CDN, WAF, Spieleanbieter und PSP

CDN/Edge: Trefferverhältnis, TTFB nach Regionen, Schildtreffer, „Sturm der Fehlwürfe“.

WAF/Bot Manager: Teilen Sie Herausforderungen/Blöcke, ASN/Länder, FPR auf Login/Einzahlung.

Spielanbieter: Startzeit für Tisch/Slot, Opt-Out/Timeouts pro Studio.

PSP: Erfolgsquote/Latenz nach Methode/Land/BIN, Fehlercodes 3DS/AVS, Webhooks Erfolg & Verzögerung.

10) Alerting und Pflicht

Routing: Alertmanager → PagerDuty/Opsgenie/Slack.

Regeln: symptomatisch (SLO) + kausal (Ressourcen).

Antischum: Gruppierung, Unterdrückung von Kettenalerts, Fenster der Stille zur Freigabe.

SLO-Gates in CD: Auto-Pause/Rollback bei Verstößen (Argo Rollouts/Flagger AnalysisRun).

Beispiele für Alert (vereinfacht):

`login_success_ratio < 99. 9% for 10m`
`p95 /payments/deposit > 0. 4s for 10m`
`db_connections_saturation > 0. 85 for 5m`
`kafka_consumer_lag > 30s`
`cdn_hit_ratio drop > 15% in 10m (per region)`

11) Dashboards, die wirklich helfen

Einzahlungsfluss: Trichter, p95/p99, PSP/BIN/Länderfehler, Webhook-Verzögerung.

Live-Spiele/WS: Verbindungen, RTT, Resend/Reconnect, Fehler nach Anbieter.

Gesundheit API: RED nach Routen, Saturationen, Top-Slow-Endpunkte ↔ Trace.

DR-Panel: Replikation lag, WAL-Versand, synthetisches Login/Deposit aus der DR-Region.

Sicherheit: WAF, Bot Score, 401/403 Anomalien, signierte Webhooks.

12) Verwaltung der Telemetriekosten

Die Kardinalität der Metriken: Schließen Sie' user _ id 'nicht in Labels ein, Grenzen für' route' und 'provider'.

Downsampling und Retention-Klassen (heiße 7-14 Tage, warme 30-90, kaltes Archiv).

Protokolle: Ereignissprung - Sampling/Dedup einschalten; Stacktrace separat aufbewahren.

Traces: dynamisches Sampling auf „teuren“ Wegen (Zahlungen/Auszahlungen).

13) Sicherheit und Privatsphäre bei der Überwachung

mTLS von Agenten bis Sammler; Verschlüsselung at-rest.

Pseudonymisierung von 'user _ pid', Verbot von E-Mail/Telefon/Dokumenten in Protokollen.

RBAC/MFA, WORM für Audit; DPA mit externen Monitoring-Anbietern.

14) Integration mit CI/CD und Auto-Otcat

SLI-Exposition als Prom-Metrik für CD-Analysen.

Release Labels ('version', 'rollout _ step') in Metriken/Logs/Traces.

Automatische Kanarientore: Die Deploy wird nur mit grünen SLOs fortgesetzt.

15) Schneller Start-Stack (Referenz)

Abholung/Transport: OTEL Collector + Prometheus/VM Agent + Fluent Bit.

Tresor: VictoriaMetrics/Thanos (Metriken), Loki/OpenSearch (Protokolle), Tempo/Jaeger (Trails).

Visualisierung: Grafana + fertige Dashboards k8s/Envoy/Postgres.

Synthetik & RUM: Checkly/k6 + Grafana RUM (oder kommerzielles Analogon).

Alerting: Alertmanager → PagerDuty/Slack runbooks in Links.

16) Checkliste Umsetzung (prod-ready)

SLO/SLI für Login/Einzahlung/Wette/Auszahlung definiert.
RED/USE + Business SLI Metriken; einheitliche Ontologie der Labels.
JSON Logs mit 'trace _ id', PII Masking, WORM für Audit.
OpenTelemetry end-to-end; Fehlersampling 100%.
Synthetik aus Schlüsselregionen + RUM in der Produktion.
Dashboards „Einzahlung Flow“, „WS“, „API Gesundheit“, „DR“.
Alerting: SLO-Symptome + Ressourcenursachen; Antischum.
SLO-Gates sind mit der CD verbunden; AutoCheck.
Kostenplan: Retenschen/Sampling/Kardinalität.
DPA/security: mTLS, RBAC, Protocol Privacy.

Zusammenfassung

Starke Überwachung ist keine Sammlung von „schönen Diagrammen“, sondern ein kohärentes System: RED/USE-Metriken, Protokolle mit 'trace _ id', OpenTelemetry-Traces, Synthetik und RUM sowie Dashboards, Alerting und SLO-Gates, die in Ihre CI/CD eingebettet sind. Stellen Sie einen Stack um offene Standards zusammen, kontrollieren Sie die Kosten der Telemetrie und standardisieren Sie die Ontologie von Labels - dann werden alle Probleme mit APIs und Infrastruktur im Voraus sichtbar und behoben, bevor die Spieler sie bemerken.