Torrent Gear

API și instrumente de monitorizare a infrastructurii

1) Principii: de la obiective la instrumente

SLO-first: alege și personaliza instrumente în scopuri de produs (login, depozit, rata), și nu invers.

Standarde deschise: OpenTelemetry (trasee/metrici/busteni), formatul de expunere Prometheus, jurnalele Loki JSON.

Context unic: 'trace _ id'/' span _ id' în jurnale și valori; link-uri „tablou de bord → urme → jurnal”.

Cost-conștient: cardinalitatea metricii, jurnalele TTL, trasee de eșantionare - în avans.

2) Măsurători: colectare, stocare, vizualizare

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

Stocare (TSDB): Prometheus (single), Thanos/Cortex/Mimir (scale-out), VictoriaMetrics (economii CPU/RAM).

Vizualizare: Grafana ca „panou de sticlă”.

Ce trebuie măsurat pentru API (RED) și infrastructură (USE):

RED: 'rate (requires)', 'error _ ratio', 'latency p95/p99' по 'route', 'method', 'provider'.
UTILIZARE: CPU/Mem, descriptori de fișiere, bazine de conexiune, lag coadă, pauze GC.

Exportatori utili:

k8s: kube-state-metrics, nod-exportator, cAdvisor, exportatorii de intrare/gateway.
: , , , .
Service mash: Măsurători pentru trimiși, tablouri de bord istio/Linkerd.
PSP/внешние: exportatori personalizați (succes prin webhook, raport de succes PSP, latență prin apel).

Exemple de PromQL (schițe):

promql
Rata de succes a depozitelor (SLI)
suma (rata (ig_payments_requests_total{route="/payments/deposit,"status=~"2.."}[5m]))
/
suma (rata (ig_payments_requests_total{route="/payments/deposit"}[5m]))

p95 latenţă API histogram_quantile (0. 95, sumă [rata (http_request_duration_seconds_bucket[5m])) pe (le, traseu)]

DB conexiune piscină saturație db_connections_in_use/ db_connections_max

3) Jurnale: căutare, corelație, imutabilitate

Stivă: OpenSearch/Elasticsearch + Beats/Vector/Fluent Bit sau Grafana Loki (mai ieftin de stocat, log-as-stream).

Format: JSON cu câmpuri standard 'ts', nivel, serviciu, env, trace_id, user_pid, rută, stare, latency_ms'.

Practici: mascare PII, găleți de audit WORM, politici TTL/ILM, partiționare „env/region/brand”.

4) Urmărirea: unde se pierd milisecunde

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

Politica de eșantionare: 100% erori, † pentru cereri „lente”, 1-5% succes.

Теги iGaming: 'provider', 'psp', 'risk _ decision', 'bonus _ id',' market ',' ws _ table _ id'.

O rețetă rapidă pentru o dezbatere: de la graficul roșu SLO → urma unui traseu problemă → o durată „groasă” pe un furnizor de PSP/joc → un jurnal de cârlig web.

5) platforme APM: atunci când all-in-one

Solutii comerciale (Datadog, New Relic, Dynatrace, Grafana Cloud) inchide APM, busteni, trasee, sintetice, RUM.

Argumente pro: viteza de implementare, corelarea din cutie. Contra: blocare cost/furnizor.

Hibrid: core pe OSS (Prometheus + Grafana + Tempo + Loki), „finish” sintetice/alertă cu module comerciale pe flux critic.

6) Sintetice și ROMS: „în afara” și „prin ochii jucătorului”

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

Scripturi: autentificare → depunere (sandbox) → lansare joc → verificare cârlig web.

Geo: EU/LatAm/MEA/APAC, rețele mobile, ASN mix.

ROM: Web-SDK (TTFB/LCP/CLS), SDK mobil; segmentare după țară/rețea/dispozitiv.

7) Suprafețe de monitorizare a kubernetelor

Planul de control: etcd, API-server (apiserver_request_total, latență), programator/controllermanager.

Planul de date: kubelet, CNI, intrare/gateway; „PodDisruptionBudget” и эвикшены.

Autoscale: măsurători și evenimente HPA/VPA/Cluster Autoscaler; piscine calde.

Politici de rețea: evenimente picături/negare, latență DNS.

8) Baze de date, cozi, cache-uri

Postgres/MySQL: decalaj de replicare, blocaje, bloat, WAL, durata punctului de control, timeout.

Kafka/RabbitMQ: întârzierea consumatorilor, reechilibrări, adâncimea cozii, redeliverii.

Redis: evenimente, clienți blocați, procente de latență, lag replica.

PITR/copii de rezervă: sarcini ale operatorului de backup + tabloul de bord time-to-restore.

9) Rețea, CDN, WAF, furnizori de jocuri și PSP-uri

CDN/Edge: hit-ratio, TTFB pe regiuni, scut lovit, „miss storm”.

Manager WAF/bot: share challenges/blocks, ASN/countries, FPR on login/deposit.

Furnizori de jocuri: ora de pornire a mesei/slotului, eșec/timeout-uri de studio.

PSP: raportul de succes/latență prin metodă/țară/BIN, codurile de eroare 3DS/AVS, succesul și întârzierea cărților web.

10) Alertarea și datoria

Rutare: Alertmanager → PagerDuty/Opsgenie/Slack.

Reguli: simptomatic (SLO) + cauzal (resurse).

Anti-zgomot: grupare, suprimarea alertelor în lanț, ferestre de liniște pentru eliberare.

Porți SLO în CD: auto-pauză/rollback pe încălcări (Argo Rollouts/Flagger AnalysisRun).

Exemple de alerte (simplificate):

'login _ success _ ratio <99. 9% pentru 10m'
'p95/plăți/depozit> 0. 4s pentru 10m '
'db _ connections _ saturation> 0. 85 pentru 5m'
'kafka _ consumer _ lag> 30s'
'cdn _ hit _ ratio drop> 15% în 10m (pe regiune)'

11) Tablouri de bord care ajută cu adevărat

Debit de depozit: pâlnie, p95/p99, PSP/BIN/erori de țară, întârziere cârlig web.

Jocuri live/WS: conexiuni, RTT, retrimitere/reconectare, erori de furnizor.

Sănătate API: RED pe rute, saturații, puncte finale lente de top ↔ urme.

Panou DR: lag replicare, WAL de transport maritim, login sintetic/depozit din regiunea DR.

Securitate: WAF, scor bot, 401/403 anomalii, carti web semnate.

12) Managementul costurilor de telemetrie

Cardinalitatea măsurătorilor: nu includeți 'user _ id' în etichete, limite privind' ruta 'și' furnizor '.

Sub-eșantionare și clase de retenție (fierbinte 7-14 zile, cald 30-90, arhivă rece).

Jurnale: eveniment jump - activați eșantionarea/dedup; stacktrace stoc separat.

Urme: eșantionare dinamică de-a lungul căilor „scumpe” (plăți/concluzii).

13) Securitate și confidențialitate în monitorizare

mTLS de la agenți la colectori; criptare în repaus.

Pseudonimizarea 'user _ pid', interzicerea e-mail/telefon/documente în jurnalele.

RBAC/MFA, WORM pentru audit; DPA cu furnizori terți de monitorizare.

14) Integrarea cu CI/CD și rollback automat

Expunerea la SLI ca valori ale balului pentru analizele CD.

Eliberați etichetele ('versiune', 'rollout _ step') în valori/busteni/urme.

Porți canare automate: coborârea va continua numai cu SLO-uri verzi.

15) stivă de pornire rapidă (de referință)

Colectare/transport: OTEL Colector + Prometheus/VM Agent + Fluent Bit.

Stocare: VictoriaMetrics/Thanos (metrici), Loki/OpenSearch (busteni), Tempo/Jaeger (trasee).

Vizualizare: Grafana + tablouri de bord gata făcute k8s/Envoy/Postgres.

Sintetice RUM: Checkly/k6 + Grafana RUM (sau echivalent comercial).

Alertă: Alertmanager → PagerDuty/Slack; runbooks în referințe.

16) Lista de verificare a implementării (prod-ready)

SLO/SLI definit pentru autentificare/depunere/ofertă/ieșire.
RED/USE + Business SLI metrics; o singură etichetă ontologie.
Jurnalele JSON cu 'trace _ id', mascare PII, WORM pentru audit.
OpenTelemetry end-to-end; 100% eșantionare de eroare.
Sintetice din regiuni cheie + ROM în vânzări.
Tablouri de bord „depozit de curgere”, „WS”, „API de sănătate”, „DR.”
Alertă: simptome SLO + cauze de resurse; anti-zgomot.
Porțile SLO sunt conectate la CD; auto-rollback.
Planul de cost: retenție/eșantionare/cardinalitate.
DPA/securitate: mTLS, RBAC, confidențialitate jurnal.

Rezumat reluare

Monitorizarea puternică nu este un set de „grafice frumoase”, ci un sistem coerent: metrici RED/USE, jurnale cu 'trace _ id', urme OpenTelemetry, sintetice și RUM, plus tablouri de bord, alerte și porți SLO încorporate în CI/CD. Construiți o stivă în jurul standardelor deschise, controlați costul telemetriei și standardizați ontologia etichetelor - atunci orice API și probleme de infrastructură vor fi vizibile în avans și reparate înainte de a fi observate de jucători.