Observabilitate și telemetrie

(Secțiunea: Tehnologie și infrastructură)

Scurt rezumat

Observabilitatea este capacitatea de a răspunde la „de ce funcționează așa?” fără eliberarea de noi clădiri. În iGaming, acest lucru este esențial: turnee de vârf, vârfuri de plată, multi-regionalitate și cerințe responsabile de jocuri de noroc/PII. Baza - valori, busteni, urme, unite prin identificatori si standarde comune (OpenTelemetry), cu contracte SLO, alerta rezistenta la zgomot si control al costurilor.

1) Cadrul de observabilitate: în ce constă

Valori (numere de timp): RED/UTILIZARE, KPI de afaceri, SLI. Stocate în TSDB.
Jurnale (evenimente în text/JSON): audit, erori, fapte de afaceri, securitate.
Urme (deschideri): calea de solicitare prin servicii, latențe, cauze ale întârzierilor.
Profilare: CPU/memorie/fluxuri eBPF, conținut heap/lock.
ROM și sintetice: utilizatori reali (web/app) + verificări robot.
Catalog telemetrie: scheme, politici PII, perioade de păstrare, etichete de cost.

2) Taxonomia și principiile semnalului

RED для API: Rata, Erori, Durata.
UTILIZARE pentru infrastructură: Utilizare, saturație, erori (procesor, discuri, rețea, cozi).
SLI/SLO: indicatori măsurabili (de ex. solicitări de succes/toate, latență p95), obiective de accesibilitate (ex. "99. 9% în 30 de zile"), bugetul de eroare → declanșează procesul.
Cardinalitate înaltă cu înțelepciune: etichetele ar trebui să fie utile în reduceri (regiune/chiriaș/furnizor), dar nu arunca în aer TSDB.

3) Standardele și corelația end-to-end

OpenTelemetry (OTel): un singur SDK/protocol pentru valori, busteni si urme.
Identificatori: 'trace _ id',' span _ id', 'corelation _ id',' player _ id' (pseudonim), 'payment _ route'.
Flow ID: gateway de intrare → toate microserviciile → plăți/cozi de → PSP/locuri de muncă → jurnale/metrici/deschideri.

Exemplu: Anteturi de corelare

traceparent: 00-<trace_id>-<span_id>-01 x-request-id: <correlation_id>

4) Metrics: ce și cum măsurăm

Denumire/Etichete

'service =' payments-api '', 'env =' prod', 'region =' eu-vest '', 'chiriaş', 'provider =' pspX '' '.

Exemple Prometheus

prometheus
RED http_requests_total{service="api",route="/deposit",method="POST",status="200"}
http_request_duration_seconds_bucket{service="api",le="0. 25",route="/deposit"} 1234 http_request_errors_total{service="api",route="/deposit"}

USE cpu_utilization_ratio{node="n1"} 0. 71 queue_depth{queue="withdrawals"} 128

Бизнес payments_success_total{psp="X",currency="EUR"} 4521 payment_conversion_ratio{route="pspX"} 0. 948

Histograme și exemplare

Păstrați histogramele de latență (nativ-histograme/ β uckets) și legați exemplar cu 'trace _ id' pentru a sări de la „lent bucket” la o anumită pistă.

5) Jurnale: structurate și sigure

Numai JSON (nici o „formă liberă” în prod).
Поля: 'timestamp', 'severitate', 'serviciu', 'trace _ id',' corelaţie _ id', 'player _ id _ hash', 'eveniment', 'sumă', 'monedă', 'ip _ hash'.
PII mascare/hashing, indici separați/retenție pentru sensibili.
Conducte jurnal: parsare → normalizare → îmbogățire (geo/ASN) → editare → indexare PII.

Exemplu de eveniment JSON

json
{
"ts":"2025-11-05T10:42:31Z",
"sev":"ERROR",
"service":"payments-api",
"event":"psp_timeout",
"trace_id":"9c5e...e2",
"route":"pspX",
"duration_ms": 3100,
"attempt":2,
"player_id_hash":"p:1b7f...",
"pii_redacted":true
}

6) Urme: în cazul în care timpul este pierdut

Spans: cerere de intrare, apeluri furnizor (PSP/furnizori de jocuri), baza de date/cache, RPC interservicii.
Atribute: 'db. sistem „,” net. peer. nume „,” mesagerie. sistem „,” psp. ruta ',' joc. furnizor ".

• cap-based pentru volum,
• pe bază de coadă (după condiții: erori, p95 +, segment VIP),
• pastrare garantata pentru plata/PII-critice.

7) Observabilitatea frontală și mobilă

RUM: TTFB, FCP/LCP/CLS/INP, JS erori, rețele și rutare SPA.
Rapoarte de avarie: simbolism, deobfuscation, build version, device/OS.
Sintetice: scenarii de intrare/depozit/rată; verificări geodistribuite.

8) SLO, SLI și bugetul de eroare

Exemplu SLO (Pseudo-YAML)

yaml service: payments-api sli:
- name: availability expr: sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
- name: latency_p95 expr: histogram_quantile(0. 95, rate(http_request_duration_seconds_bucket[5m]))
targets:
availability: "99. 9%/30d"
latency_p95: "<=250ms/30d"
error_budget_policy:
fast_burn: 5% for 1h -> page, freeze deploy slow_burn: 20% for 24h -> incident, improvement plan

Alertarea prin bugetul de eroare, nu prin „fiecare metrică”.
Proceduri de congelare pentru arderea bugetară: eliberări limită/canari.

9) Alertarea fără zgomot

Multi-fereastră, multi-arde reguli: fereastră scurtă/lungă.
Deduplicare/înrădăcinare: prin serviciu/regiune/critică în apel.
URL-ul Runbook și autocolarea contextului (cele mai recente expedieri, modificări de configurare, graficul de dependență).
Ore liniștite și suprimarea în timpul lucrărilor programate.

Exemplu de regulă (ideea PromQL)

promql alert: PaymentsSLOFastBurn expr: slo_error_rate_5m > 2 slo_budget_rate for: 15m labels: { severity="page", service="payments-api" }
annotations:
summary: "SLO fast burn"
runbook: "https://runbooks/payments/slo"

10) Profilare și eBPF

eBPF/profilere: grafice CPU/flacără, latență I/O, picături de rețea, anomalii Syscall.
Utile pentru blocaje p99, bruiaj și înghețuri rare.

11) Observabilitatea afacerii (produs și risc)

Finanțe/monetizare: conversie depozit, TTW (time-to-wallet), autor ./decontare, anulări/chargebacks.
Activitatea de joc: retenție/streak, cota de pariuri live, „stickiness” de furnizori.
Antifraudă/abuz: viteză de acțiune, dispozitiv/meciuri IP, corelații.
Indicatori RG: sesiuni lungi, „dogon”, creșterea fripturii.
Măsurătorile de afaceri sunt corelate cu măsurătorile tehnice și evenimentele de adnotare.

12) Siguranță, PII și conformitate

Zone de date: seturi de date/etichete jurnal ('pi = true', 'region = EU').
Mascarea înainte de indexare, aliasarea identificatorilor.
Magazinele WORM pentru audit; acces jurnal bazat pe roluri.
Perioade de păstrare: diferite pentru techlogs/audituri/afaceri.
Interzicerea secretelor brute în bușteni; verificări de scanare în CI.

13) Managementul valorii (FinOps)

Limita de cardinalitate: atenție cu 'user _ id',' session _ id'.
Participare/retentie: cald (7-14 zile), cald (30-90), rece (arhiva).
Eșantionare bazată pe coadă și măsurători de sub-eșantionare.
Facturare după etichete „echipă”, „serviciu”, „chiriaș”: rapoarte „cine arde observabilitatea”.

14) Instrumente (stivă de referință)

Metrics: Prometheus/lac pentru metrica, tablouri de bord Grafana.
Busteni: Loki/ELK; reguli de ingestie, reducere/parsare.
Trasee: colecționari Tempo/Jaeger/OTel; exemplars-link-uri de la metrici.
Sintetice: Blackbox exportator, roboți de browser.
Alertă: Alertmanager/integrare chat, rotație de gardă.
Profilare: eBPF/profilare continuă.

15) Exemple: Implementarea fundației rapid

python from prometheus_client import Counter, Histogram, start_http_server reqs = Counter('http_requests_total','', ['route','method','status'])
lat = Histogram('http_request_duration_seconds','', ['route'])
def handle(req):
with lat. labels(route=req. route). time():
status = app(req)
reqs. labels(route=req. route,method=req. method,status=str(status)). inc()

go tid:= ctx. Value("trace_id")
logger = logger. With("trace_id", tid)
logger. Info("deposit-accepted", "amount", amt, "route", route)

prometheus http_request_duration_seconds_bucket{..., le="0. 25"} 1023 # exemplar: trace_id=9c5e...

16) Procese și sistem de operare

Dicționar unificat de metrici/etichete (denumire-ghid) și șablon tablou de bord.
Eliberați automat adnotările în coloane.
Incidente: card, cronologie, RCA fără taxe, elemente de acțiune.
Alarme de antrenament („ziua jocului”): picături simulate, întârzieri PSP, supraîncălzirea memoriei cache.
Runbooks: instrucțiuni pas cu pas și legături automate din alerte.

17) Lista de verificare a maturității

1. OTel SDK/colector → un singur export de valori/busteni/trasee.
2. RED/UTILIZARE acoperă toate serviciile + SLI/SLO prin API cheie.
3. Corelație "trace _ id' ⇄ busteni ⇄ metrici (exemplare, jump-link-uri).
4. Alerte privind erorile de buget cu legături multi-burn și runabook.
5. RUM + sintetice pentru „depozit/rata/retragere”.
6. Profilare (eBPF) pe lista albă de vânzare.
7. Politici PII: mascare, zone, acces, perioade de păstrare.
8. Raportul financiar privind costul telemetriei (etichetele „echipă/serviciu”).
9. „Pregătirea pentru încărcarea de vârf”: planul de testare, cache-urile de încălzire, șabloanele de alertă.
10. Revizuiri regulate ale RCA și SLO/prag.

18) Antipattern

Jurnalele "foi" fără structură și "trace _ id'.
Alerte pentru fiecare metrică → alertă FAT.
Histograme fără găleți corecte → „plat” p95.
Cardinalitatea nelimitată a etichetelor → o explozie de valoare.
Lipsa de RUM/sintetice este „toate ok”, dar utilizatorul nu este.
Amestecarea PII cu tehnologi, retenție nedeterminată.
Izolarea telemetrică de KPI-urile de afaceri - „latența scade, veniturile prea”.

Rezumat

Observabilitatea puternică este un limbaj comun între produs, SRE, securitate și plăți. Prin conectarea măsurătorilor, jurnalelor, pieselor pentru OTel, introducerea SLO cu un buget de erori, făcând alertarea inteligentă și gestionabilă a costurilor, obțineți un sistem care observă probleme mai devreme, se recuperează mai repede și trece în mod previzibil vârfuri de trafic și sarcini de turneu.