Betrieb und Management → Leistungsmetriken

Leistungsmetriken

1) Warum Leistungsmetriken benötigt werden

• die Degradation zu Vorfällen zu erkennen,
• Voraussage von Kapazität und Budget,
• Vergleich alternativer Lösungen (Cache vs DB, gRPC vs REST),
• Verwalten von Regressionen nach Releases.

Grundsätze: einheitliches Metrikvokabular, Aggregation nach Perzentilen (p50/p90/p95/p99), getrennte Erfassung von „heißen“ und „kalten“ Pfaden, Kontext (Version, Region, Anbieter, Gerät).

2) Taxonomie der Metriken

2. 1 Basis-SRE-Rahmen

Vier goldene Signale: Latenz, Verkehr, Fehler, Sättigung.
ROT (für Microservices): Rate, Fehler, Dauer.
USE (für Eisen): Utilization, Sättigung, Fehler.

2. 2 Ebenen

Infrastruktur: CPU, RAM, Festplatte, Netzwerk, Container, Knoten.
Plattform/Dienste: API-Endpunkte, Warteschlangen, Caches, DBs, Event-Busse.
Kundenerfahrung: Web Vitals, mobile SDKs, Streaming, CDN.
Datenplattform: ETL/ELT, Streams, Schaufenster, BI-Latenzen.
Geschäftskritische Flows: Autorisierung, KYC, Einzahlungen/Auszahlungen, Spielrunden.

3) Katalog der Schlüsselmetriken und Formeln

3. 1 API und Microservices

RPS (Requests per second).
Latency p50/p95/p99 (ms) - vorzugsweise „end-to-end“ und „backend-only“.
Fehlerrate (%) = 5xx + validierte 4xx/alle Abfragen.
Sättigung: durchschnittliche Länge der Worker-Warteschlange, „In-Flight“ -Anfragen.
Kalte Startrate (für FaaS).
Throttling/Dropped Requests.

SLO-Beispiel: p95 Latenz ≤ 250 ms bei RPS bis 2k in der Region EU-Ost; Fehler ≤ 0. 5%.

3. 2 Datenbanken

QPS/Transactions/s, avg/median query time, p95 query time.
Lock Waits / Deadlocks, Row/Index Hit Ratio, Buffer Cache Miss%.
RepLag (Replikation), Checkpoint/Flush Zeit, Autovacuum lag.
Hot Keys/Skew sind die Top N Schlüssel für die Last.

Kernel Request Formula: QPS/ vCPU_core_count → Signal für Sharding.

3. 3 Cache und CDN

Hit Ratio (%), Evictions/s, Latency p95, Item Size percentiles.
Origin Offload (%) для CDN, TTFB, Stale-while-revalidate hit%.

3. 4 Warteschlangen/Streams

Ingress/egress msg/s, Consumer Lag (Nachrichten/Zeit), Rebalance Rate.
Processing Time p95, DLQ Rate.

3. 5 Infrastruktur/Container

CPU Utilization %, CPU Throttle %, Run Queue length.
Memory RSS/Working Set, OOM kills, Page Faults.
Disk IOPS/Latency/Throughput, Network RTT/ retransmits.
Node Saturation: pods pending, pressure (CPU/Memory/IO).

3. 6 Web-Client (UX)

Core Web Vitals: LCP, INP, CLS.
TTFB, FCP, TTI, Resource Timing (DNS, TLS, TTFB, download).
Error Rate (JS), Long Tasks, SPA route change time.
CDN Geo-Latenz (Perzentil).

3. 7 Mobiler Kunde

App Start time (cold/warm), ANR rate, Crash-free sessions %.
Network round-trips/session, Payload size, Battery drain/session.
Offline-Erfolgsrate (Cashed-Transaktionen).

3. 8 Datenplattform und Reporting

Freshness Lag (T-now → витрина), Throughput rows/s, Job Success %.
Kosten pro TB verarbeitet, Skew nach Parteien, Spätveranstaltungen%.
BI Time-to-Render p95 für wichtige Dashboards.

3. 9 Domänenkritische Flows (iGaming als Beispiel)

Auth p95, KYC TTV (Time-to-Verify), Deposit/Withdrawal p95.
Game Round Duration p95, RNG call latency, Provider RTT p95.
Payment PSP success rate, Chargeback investigation SLA.

4) Normalisierung, Perzentile und Attribution

Perzentile vs. Mittel: Wir fixieren p50/p90/p95/p99 - Mittel glätten Spitzenschmerzen.
Schnitte: App-Version, Region, Anbieter, Netzwerkkanal (4G/Wi-Fi), Gerät.
Korrelation: Wir verknüpfen „backend-only“ und „real-user“ Metriken für Ursache-Wirkungs-Ketten.
Beispiele/Spuren: Wir verbinden extreme Perzentile mit Spuren.

5) Schwellen und Alerts (ungefähres Raster)

Latenz p95 (Kern-API): Warnung> 250 ms, kritisch> 400 ms 5 min in Folge.
Error rate: warning > 0. 5%, kritisch> 2% (Endpoint, nicht global).
DB RepLag: warning > 2 s, critical > 10 s.
Kafka consumer lag (time): warning > 30 s, critical > 2 min.
Web LCP (p75): warning > 2. 5 s, critical > 4 s.
Mobile ANR: warning > 0. 5%, critical > 1%.
ETL Freshness: warning > +15 min, critical > +60 min от SLA.

Wir verwenden statische + adaptive Schwellenwerte (Saisonalität, Tagesmuster), Deduplizierung und Alert-Gruppierung nach Service/Releases.

6) Leistungstest

Typen: baseline, stress, long (soak), chaos (degrade links/PSP).
Lastprofile: nach realen Traces (distributionsbasiert), „Bursts“, regionale Spitzen.
Ziele: Erreichen von SLO mit gezielten RPS- und Mix-Operationen, Validierung von Backpress.
Durchlaufmetriken: Durchlauf, Fehler%, p95 Latenz, Pause GC, CPU throttle, queue lag, cost/run.

Regressionsregel: Eine Freigabe gilt als erfolgreich, wenn p95 bei gleichem Profil nicht> 10% verschlechtert wird und die Abfragekosten (CPU-ms/Request) nicht> 15% steigen.

7) Kapazitätsplanung und Preis/Leistung

Anforderungsmodell: RPS nach Stunden × durchschnittliche Arbeit/Anforderung (CPU-ms, IO-ops).
Headroom: 30-50% Lagerbestand für kritische Pfade, Auto-Scaling nach P95.
Cost KPIs: Cost per 1k requests, Cost per GB served, $ per 1 p. p. LCP Verbesserungen.
Caching/Denormalisierung: „Cache-ROI“ = (CPU-ms-Einsparungen − Cache-Kosten).
Warme und kalte Regionen: Offload in CDN/Edge, schreibgeschützte Replikation.

8) Beobachtungs- und Profilierungspraktiken

Traces: verteilte Trace-IDs durch alle Hop's; Sampling ist intelligent (tail-based).
Metriken: Prometheus/OpenTelemetry, einheitliche Notation von Namen und Labels.
Logs: mit Korrelation nach Trace/Span, Budget nach Log-Rauschen, PII-Bearbeitung.
Profiler: CPU/Heap/Alloc/Lock Profile, kontinuierliches Profiling (eBPF).
Beispielinstanzen: Wir verknüpfen p99-Bursts mit einem bestimmten Span/SQL/PSP-Kolleg.

9) Release- und Team-Metriken (der Vollständigkeit halber)

DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.
RAUM: Zufriedenheit, Leistung, Aktivität, Kommunikation, Effizienz.
Bei diesen Metriken geht es nicht um Eisen, sondern direkt um die Nachhaltigkeit der Leistung.

10) Anti-Muster

Den Durchschnitt verfolgen: p95/p99 ignorieren.
„Globale“ Fehlerrate: verbirgt schmerzhafte Endpunkte.
Ohne Attribution nach Version: keine Client-Regressionen auffangen.
Alert-Spam: Schwellenwerte ohne Hysterese und Korrektur der Saisonalität.
Blind-Optimierung: Kein Profiling und keine Traces.
Mischung aus UX und Backend-Latenz: Falsche Schlussfolgerungen aus der Kundenerfahrung.

11) Checklisten

Einheitlicher Metrikstandard

• Wörterbuch der Metriken mit Formeln, Einheiten, Besitzern
• Obligatorische Perzentile p50/p90/p95/p99
• Trace-Korrelation und Log-Korrelation
• Tags: Region, Version, Anbieter, Gerät, Netzwerkkanal
• Schwellenwerte mit Hysterese und Deduplizierung

Vor der Veröffentlichung

• Baseline p95/p99 auf Stage und Prod
• Kanarienverkehr + Vergleich der A/B-Metriken
• Ficha-Flagge mit schnellem Rollback
• Beobachtungsplan (Observability Runbook)

Regelmäßig

• Die langsamsten Top-N-Abfragen/SQL-Reviews
• Cache-Richtlinien und TTL-Prüfung
• Überprüfung von Freshness und DB-Replikationen
• Degradationstests externer Anbieter (PSP, KYC)

12) Mini-Playbooks (Beispiel)

Degradation p95/api/payments

1. Überprüfen Sie error% und externe PSP-Timeouts.
2. Überprüfen Sie die Verbraucherschlange der Kollegenschlange.
3. Siehe trace Beispiele p99: SQL/HTTP Flaschenhals?
4. Verzeichnis/Limit-Cache aktivieren, N + 1 senken.
5. Budget: vorübergehend Anhebung der Worker-Ressourcen um 20%, einschließlich Autoscale.
6. Post-fix: Index nach (psp_id, Status, created_at), Retray-Jitter.

Wachstum der RepLag in der DB

1. Überprüfen Sie „schwere“ Anfragen und lange Transaktionen.
2. Erhöhen Sie die Parallelität der Replikation, verdichten Sie den Checkpoint.
3. Offload Lesen in Cache/Replikate nur lesen.
4. Bei Spitzenfenstern - teilweise Denorm + Batchi.

13) Beispielformeln/SQL (vereinfacht)

Fehlerrate nach Endpunkt

sql
SELECT endpoint,
100. 0 SUM(CASE WHEN status >= 500 THEN 1 ELSE 0 END) / COUNT() AS error_pct
FROM http_logs
WHERE ts >= now() - interval '5 minutes'
GROUP BY 1
HAVING COUNT() > 500;

Latency p95 (TDigest/Approx)

sql
SELECT endpoint, approx_percentile(latency_ms, 0. 95) AS p95_ms
FROM http_metrics
WHERE ts >= date_trunc('hour', now())
GROUP BY 1;

Verbraucher Lag (Zeit)

sql
SELECT topic, consumer_group,
max(produced_ts) - max(consumed_ts) AS lag_interval
FROM stream_offsets
GROUP BY 1,2;

Web LCP p75

sql
SELECT approx_percentile(lcp_ms, 0. 75) AS lcp_p75
FROM web_vitals
WHERE country = 'UA' AND device IN ('mobile','tablet')
AND ts >= current_date;

14) Einbettung in Dashboards und Reporting

KPI-Karten: p95 Latenz, Fehler%, RPS, Sättigung mit WoW/DoD-Trends.
Top N „schlechteste“ Endpoints/SQL/Ressourcen, klickbare Drill-Down → Trace.
Korrelation der Client-Versionen: Graph „Version → p95 LCP/INP → Conversion“.
Weltkarte: Geo-Latency (CDN), PSP Latency nach Regionen.
SLO-Panel: Zeitanteil im SLO, Abgänge aus dem SLO, „Fehlerbudget“.

15) Ergebnisse

Leistungsmetriken sind eine Systemdisziplin: einheitliches Vokabular, Perzentile, Attribution, gute Beobachtbarkeit und strenge SLOs. Durch die Kombination von technischen (Latenz, Lags, Cache-Hits) und Produktsignalen (KYC-Zeit, p95-Kaution, LCP) steuern Sie die Qualität der Erfahrung und die Kosten für ihre Lieferung - vorhersehbar und skalierbar.