Verteilung von Signalen und Metriken

(Abschnitt: Ökosystem und Netzwerk)

1) Ziel und Bereich

• Einheitliche Telemetriesprache und Datenverträge.
• Gesteuerte QoS-Kanäle: Priorität kritischer Signale.
• Transparentes SLI/SLO und vorhersehbare Alerting.
• Privatsphäre, Isolation und Einsparung von Metrikbudgets.

2) Taxonomie der Signale

1. Geschäftsereignisse: Onboarding, Einzahlungen/Auszahlungen, Spielereignisse, Zuschreibungen.
2. Te-Metriken: Latenz/Durchlauf/Fehlercode, Warteschlange, CPU/RAM/IO-Nutzung.
3. Protokolle: Strukturierte Aufzeichnungen über Vorgänge und Fehler.
4. Traces: Abfrage/Topic-Spans, Hop-to-Hop-Korrelation.
5. Gesundheitsstatus: synthetische Proben, Bereitschaft/Lebendigkeit, Herzschlag-Knoten.
6. Risiko/Compliance Signale: KYC/KYB/AML Treffer, Sanktionsereignisse.

Jede Klasse hat ihr eigenes Kritikalitätsniveau und ihre eigene Aufbewahrungs-/Versandrichtlinie.

3) Verteilungsarchitektur (Referenz)

Edge Collectors (SDKs/Agenten) → Ingress (HTTP/OTLP/gRPC/QUIC) → Shin (Kafka/Pulsar) → Handler (Stream-Jobs) → Speicher (TSDBs für Metriken, Objekt/Säule - für Protokolle/Ereignisse, Tracer) → Vitrinen/Dashboards/Alerts.
Multi-Tenant: namespace/tenant-id in den Schlüsseln, separate quota/limits/ACL.
Segmentierung nach QoS: kritisch (P0), wichtig (P1), Hintergrund (P2).
Egress: Abonnenten (Ops/BI/Third-Party) über Topic-Abonnements und materialisierte Ansichten.

4) Verträge und Schemata (Ereignisse/Metriken/Traces)

4. 1 Ereignisse (vereinfacht, YAML)

yaml event:
id: uuid kind: business    ops    risk ts: timestamp    # ISO8601 tenant: string    # org_id/namespace source: string    # service/peer-id trace_id: string type: string     # deposit. created    payout. failed    probe. ok...
attrs: object # semantic fields (no PII)
severity: info    warn    error    critical qos: P0    P1    P2

4. 2 Metriken (OpenMetrics/OTLP)

Gauge/Counter/Histogram mit stabilen Labels (begrenzte Kardinalität).
Kennungen: 'metric _ name {service, region, tenant, version, route}'.
Histogramme für Latenz/Größen statt p99 im Code.

4. 3 Treysa

Erforderliche Felder: 'trace _ id', 'span _ id', 'parent _ id', 'service', 'peer', 'route', 'qos'.
Links zwischen Domains (Consumer/Producer) und Netzwerk-Hops (Relay/Bridge).

5) QoS und Priorisierung

P0 (kritisch): SLI-Zahlungen/Auszahlungen, Brücken-/Knotenstatus, Burn-Rate-SLO → strikte Lieferung (Acks, Retries, Idempotenz), minimale Timeouts.
P1 (wichtig): Produktereignisse/Basismetriken → garantierte Lieferung innerhalb des SLO.
P2 (Hintergrund): detaillierte Protokolle, Debugging → Best-Effort, können bei Überlastung abgesprungen werden.

Richtlinien: verschiedene Warteschlangen, Quota für Produzenten, Backpressure, Rate-Limits, Dedup durch 'idempotency _ key'.

6) Kardinalität und Budget der Metriken

6-Label-Regel: maximal 6 Schlüssel pro Metrik, feste Wertwörterbücher.
Kardinalität ≤ 10k Zeitreihen/Metrik/Tenant.
Sampling: kopf-/tailbasiert für Traces; Downsampling Metriken 10s→1m→5m→1h.
Quotas: Punktlimits/sec und Bytes/sec pro Tentant und pro QoS-Klasse.
Linter Schemas: Lehnt Metriken mit „explodierenden“ Labels ab (ID, E-Mail, IP usw.).

7) Abholung und Lieferung: Push vs Pull

Push (OTLP/StatsD/HTTP): Flexibilität, mobile/edge-Clients, P0-Kanäle.
Pull (Prometheus): interne Infrastruktur, vorhersehbare Ziele.
Hybrid: exporters→gateway→TSDB; federated scrapes für die Regionen.
Transport: QUIC/HTTP/2, Kompression, Batching, TLS/mTLS, Jitter-Retrays.

8) SLI/SLO und Alerting

8. 1 Basis-SLIs

Verfügbarkeit% Endpunkte/Gateways,

Latency p50/p95/p99 auf kritischen Strecken,

Error-rate (5xx/timeout/abort),

Lieferung lag per Bus, Queue depth,

Freshness Vitrinen (verzögerte ingest→serve).

8. 2 Beispiele für SLO

P0 pipelines: Availability ≥ 99. 95%, p99 latency ≤ 400 мс, Delivery lag p95 ≤ 2 с.
P1: Availability ≥ 99. 9%, Freshness p95 ≤ 3 min.
P2: Freshness p95 ≤ 15 мин, no-page.

8. 3 Burn-Rate Alerts (Beispiel)

2-Stunden-Fenster: 'error _ budget _ burn ≥ 2 ×' → page.
6-Stunden-Fenster: 'error _ budget _ burn ≥ 1 ×' → Seite/Eskalation.
Kombination mit 'queue _ lag' und 'drop _ rate' P0.

9) Lagerung und Rückstellungen

TSDB-Metriken: Hochfrequenz - 7-14 Tage; Aggregate - 6-12 Monate.
Ereignisse/Protokolle: heißer Speicher 7-30 Tage, kalt (Objekt) 6-24 Monate.
Traces: Sampling 1-10%; Speichern von „langsamen/fehlerhaften“ Spans (tail-based).
Lösch-/Revisionsrichtlinien für PII und Anträge betroffener Personen.

10) Privatsphäre, Sicherheit und Isolation

PII-Minimierung: Tokenisierung/Pseudonymisierung von Feldern, Verbot von „rohen“ Identifikatoren in Metriken.
mTLS/Event Signaturen, Pinning von Produzentenschlüsseln.
ACL/ABAC zu Themen/Diensten/Tenanten, separate Schlüssel zum Schreiben/Lesen.
Tenant sandboxing: logische/physikalische Trennung, Limits und Rate-Limit per tenant.
Audit Trail: Unveränderliche Zugriffs-/Änderungsprotokolle für Config.

11) Verarbeitungsströme (Stream Jobs)

Enrich: Normalisierung, Geo/Version/Verkehrsklasse.
Aggregate: 10s/1m/5m Fenster, Histogramme, Quantenskizzen.
Detect: Anomalien (EWMA/ESD), Verteilungsdrift, Warteschlangenspitzen.
Route: Fan-Aus in den Schaufenstern/Ahlerts/Webhooks der Partner.
Guard: „roter Knopf“ - throttling/kill-switch nach Quelle/Thema.

12) Dashboards (Referenzlayouts)

Ops Core (Stunde/Real-Time): p95 Latenz, Fehlerrate, Lieferverzug, Queue-Tiefe, Erfolgsrate ingest.
Pipelines Health: freshness per pipeline, drop-rate, backpressure, burn-rate SLO.
Tenant Verwendung: Reihen/Sek., Bytes/Sek., Kardinalität, Top-Labels.
Sicherheit/Compliance: mTLS-Status, Ablaufschlüssel, Zugriffe, PII-Revisionen.
Business Lens: Konversions-/Auszahlungs-/Überbrückungs-SLIs neben den Tech-Metriken.

13) Beispiele für Konfigurationen

QoS-Klassen und Grenzwerte (YAML)

yaml telemetry:
qos:
P0:
topics: [payout. sli, bridge. finality, gateway. availability]
delivery: guaranteed retry:
attempts: 3 backoff_ms: [100, 400, 800]
max_queue_lag_ms: 2000
P1:
topics: [product. events, api. metrics]
delivery: at-least-once sampling: 1. 0
P2:
topics: [debug. logs, verbose. traces]
delivery: best-effort sampling: 0. 1 quotas:
tenant_default:
metrics_points_per_sec: 50_000 logs_mb_per_hour: 500 traces_spans_sampled_pct: 5

Kennzeichnungsetiketten (Richtlinie)

yaml metrics_policy:
allowed_labels: [service, route, code, region, tenant, version]
forbidden_labels: [user_id, email, ip, session_id]
max_label_value_count: 1000

Alerts burn-rate

yaml alerts:
- name: "p0_error_burn_2h"
expr: burn_rate_p0_2h > 2 action: [page_oncall, open_incident]
- name: "queue_lag_p0"
expr: queue_lag_ms_p95 > 2000 action: [page_oncall]

14) Datenschemata und Abfragen

Metrikregister (Katalog)

sql
CREATE TABLE metric_catalog(
name TEXT PRIMARY KEY,
unit TEXT, description TEXT,
labels JSONB, owner TEXT, qos TEXT, sla JSONB
);

Warteschlangen und Lag

sql
SELECT topic,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY lag_ms) AS lag_p95,
SUM(dropped) AS drops
FROM queue_metrics
WHERE ts >= now() - INTERVAL '24 hours'
GROUP BY topic;

Kardinalität nach Tentant

sql
SELECT tenant, metric_name, COUNT(DISTINCT series_id) AS series
FROM tsdb_series
WHERE day = current_date
GROUP BY tenant, metric_name
ORDER BY series DESC
LIMIT 50;

15) Prozesse und Rollen

Telemetry Owner - Schemata/Richtlinien/Quoten, Kontrolle der Kardinalität.
SRE/Ops - SLO, Alerts, Incidents, Scale-up.
Sicherheit/Compliance - Schlüssel, Zugriffe, PII, Audits.
Produkt/BI - KPI-Schaufenster, Analytik, A/B-Metriken.
Tenants (Partner) - korrekte SDK-Integration, Einhaltung von Verträgen.

16) Playbook der Vorfälle

A. Explosion der Kardinalität

1. Auto-Block Produzent/Metrik, 2) schneiden „schlechte“ Labels ab, 3) Retro-Aggregation, 4) Post-Mortem und Linter-Regeln.

B. Wachstum queue lag P0

1. Priorität einbeziehen, 2) Parties/Consumer erweitern, 3) temporär P2-Sampling reduzieren, 4) Engpassanalyse.

C. Der Fall der Freshness-Vitrinen

1. Wechseln Sie zum Backup-Konnektor, 2) aktivieren Sie den Degradierungsmodus („zuletzt finalisiert“), 3) benachrichtigen Sie die Eigentümer der Quellen.

D. PII-Leck in Metriken

1. Sofortige Thread-Blockierung, 2) Redaction auf der Hot Layer, 3) DPO/Compliance-Benachrichtigung, 4) Aktualisierung der Lender/SDK.

E. Masse 5xx/Spurfehler

1. Page, 2) Tail-basiertes Sampling ↑ für Fehler, 3) Trace-Diagnose der kritischen Route, 4) Release-Rollback/Ficha-Flag.

17) Checkliste Umsetzung

1. Genehmigung von Event/Metrik/Trace-Verträgen und einer Liste zulässiger Labels.
2. Starten Sie QoS-Klassen, Topics/Queues, Quotas und ein Metrikbudget.
3. Konfigurieren Sie ingest (Push/Pull), TLS/mTLS, Retrays und Idempotenz.
4. Aktivieren Sie Metrik-/Ereignisverzeichnisse und Schema-Linter.
5. Definieren Sie SLI/SLO, Burn-Rate Alerts und Eskalationen.
6. Bauen Sie Ops/Pipelines/Tenant/Security Dashboards.
7. Führen Sie Chaos-Tests der Telemetrie (Verluste/Jitter/Spikes).
8. Revitalisieren Sie regelmäßig die Kardinalität, Retentionen und Kosten der Lagerung.

18) Glossar

QoS ist die Qualitäts-/Prioritätsklasse der Lieferung.
Freshness - Verzögerung des Auftretens von Daten im Schaufenster.
Burn-Rate - Die Rate des Fehlerbudgets im Verhältnis zum SLO.
Cardinality - die Anzahl der einzigartigen Reihen von Metriken (Label-Kombinationen).
Tail-basiertes Sampling - Auswahl von „langsamen/fehlerhaften“ Traces.
Der Idempotency-Schlüssel ist der Schlüssel zur Deduplizierung von Ereigniswiederholungen.

Fazit: Bei der Verteilung von Signalen und Metriken geht es nicht nur darum, „Diagramme zu sammeln und anzuzeigen“, sondern um die Disziplin von Verträgen, QoS-Kanälen und Budgets. Nach diesem Rahmen erhält das Ökosystem eine vorhersehbare Beobachtbarkeit, die gegen Überspannungen resistent, privat gegenüber Daten und nützlich für Entscheidungen sowohl im operativen als auch im geschäftlichen Kreislauf ist.