Monitorizare și exploatare forestieră

1) De ce contează în iGaming

Bani în timp real: acceptarea depozitelor, plăți instantanee, calcularea pariurilor și câștigurilor, turnee - totul este sensibil la întârzieri și eșecuri.
Reglementare și audit: este necesară trasabilitatea completă a acțiunilor (KYC/AML, plăți, limitele jocului responsabil).
Arhitectură distribuită complexă: gateway-uri API, orchestrație de plăți, EDA/Kafka, servicii de furnizori, clienți mobili, fronturi, autobuz BI.
Scopul: de a reduce MTTD/MTTR, păstrați SLO pe semnalele de aur și să ofere rata de incidente.

2) Concepte de bază ale observabilității

Jurnale: evenimente detaliate (JSON structurat) potrivite pentru investigații și audituri.
Valori: agregate în timp (TSDB), potrivite pentru SLO/alerte.
Urme: lanțuri de cauze și efecte ale cererilor (trace/span) prin servicii/brokeri/baze de date.
Evenimente: evenimente de domeniu (BetPlased, DepositApproved) - o punte de legătură între valorile de afaceri și tehnologie.

3) „Semnale de aur” și SLI/SLO pentru iGaming

Latență: P95/P99 pe fluxuri critice (autorizare, depozit, rată, start sesiune, rotire).
Trafic: SPR prin API, TPS prin plată, EPS prin eveniment.
Erori: 5xx/4xx share, declin-rate, eșuat-in, erori de furnizor.
Saturație: CPU, memorie, IO, Kafka lag, conexiuni DB, fir-piscine.

• SLI: '1 - (failed_payments/ total_payments)'
• SLO: 99. 7% din autorizațiile de card de succes în 30 de zile (bugetul de eroare 0. 3%).

4) Arhitectura de colectare și prelucrare

1. Injecție: agenți (OTel Collector/Fluent Bit), SDK în aplicație, RUM/sintetice.
2. Rutare: broker/autobuz de telemetrie (OTLP/HTTP/GRPC), filtre și mascare PII.

• Valori: TSDB (agregare, sub-eșantionare).
• Jurnale: cald (indexat )/cald (mai puțin indexat )/rece (depozit obiect, WORM).
• Trasee: stocare indexată în timp cu retenții și prelevarea de probe.
• 4. Analytics/alerts: rules (PromQL/LogQL/SQL), corelation with tracks and releases.
• 5. Tablouri de bord: tipuri tehnice + de afaceri (plăți, RNG/furnizori, motor de turneu).

5) Log standard (JSON) și taxonomie eveniment

Sunt recomandate logarea JSON strictă, cheile și nivelurile unice.

Уровни: 'DEBUG

Таксономия: 'auth.', 'payment.', 'gameplay.', 'risk.', 'psp.', 'kyc.', 'rg.' (joc responsabil), 'ops.'.

json
{
"ts": "2025-11-04T19:45:31. 842Z",
"lvl": "AUDIT",
"event_type": "payment. deposit_approved",
"correlation_id": "c-7d2c1f0b",
"trace_id": "2d6a9c0e4c0b1f72",
"span_id": "9f3a81d2a1c3b764",
"request_id": "r-8f12de9e",
"tenant": "brand_eu",
"psp": "acq_xyz",
"user_id_hash": "u:sha256:1e63…",
"device_id": "d-3c8f…",
"ip_trunc": "203. 0. 113. 0/24",
"amount_minor": 5000,
"currency": "EUR",
"result": "approved",
"latency_ms": 312,
"tags": ["pci_safe", "kyc_passed", "low_risk"],
"extra": {
"bin": "411111",
"method": "card",
"region": "EU",
"ab_test": "checkout_v2"
}
}

• Mascăm PAN/BIN (stocăm doar câmpuri valabile după politică), e-mail/telefon - hash/token.
• IP trunchiat la/24, GeoIP magazin separat.
• Interzicem textul gratuit în „extra” pentru intrarea utilizatorului fără dezinfectare.

6) Corelație: trace_id, correlation_id, idempotency_key

Adăugați 'trace _ id' (din OTel),' span _ id', 'corelation _ id' (end-to-end pentru procesul de afaceri),' idempotency _ key '(pentru cereri de plată) la fiecare jurnal și metrică.
Transferați bagajele (chiriaș/marcă, piață, opțiune A/B) pentru a construi felii.

7) Măsurători: Tehnice și de afaceri

Tehnic: RPS, p95 latență, rata de eroare, saturație, GC, utilizarea piscinei, Kafka lag de consum.
Business: CR registratsii→depozit, autorizații de succes, anulări de plăți, NGR/GGR, ARPPU, anomalii RTP, drop-off la etapa KYC, ponderea limitelor responsabile.

promql sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

8) Urmărirea și OpenTelemetry

Instrumentăm gateway-ul, orchestratorul de plăți, nucleul jocului, notificările, KYC/AML, integrarea cu furnizorii.
Eșantionarea capului pentru fluxul total + eșantionarea cozii (ridicată) pentru erori/intervale latente și plăți.
Propagarea contextului: „traceparent ”/„ tracestat”, antete Kafka, metadate gRPC.
Adnotarea se desfășoară cu evenimente de domeniu: 'BetPlased', 'WithinRequired'.

9) Alertarea fără zgomot

Praguri în mai multe etape (avertizare/critică), suprimarea clapetelor, eliminarea duplicatelor, a timpului.
Corelație: asociem „5xx growth” + „Kafka lag” + „p95 latency PSP” → un singur incident.
Alerte bazate pe SLO: cheltuiți bugetul de eroare - escaladați.
Alerte-as-Code (GitOps), teste de revizuire și regulă.

yaml groups:
- name: payments rules:
- alert: PaymentErrorSpike expr: (sum(rate(payment_errors_total[5m])) / sum(rate(payment_attempts_total[5m]))) > 0. 02 for: 10m labels: { severity: "critical", team: "payments" }
annotations:
summary: "Payment errors> 2% per 10m"
runbook: "runbooks/payments/error-spike. md"

10) Căutare jurnal (exemplu LogQL)

logql
{app="psp-orchestrator", level=~"ERROR    FATAL"}
= "decline"
json amount_minor > 10000 region="EU"

Scopul este de a elimina rapid zgomotul și de a evidenția eșecurile „scumpe” din regiunea țintă.

11) Tablouri de bord: ceea ce este obligatoriu

Plăți Sănătate: succes/eșecuri prin PSP, latență prin metodă, harta regiunilor, furnizori SLA.
Joc de bază: RPS de furnizori, p95 spin, raportul de eroare SDK, anomalii RTP de sloturi.
Călătoria jucătorului: registratsiya→KUS→depozit→igra→vyvod.
Infra: Kafka lag, conexiuni DB, cache hit ratio, cluster Kubernetes (grilă de păstăi/noduri).

12) Stocare, retenție și cost (FinOps)

Cardinalitatea sub control: evitați măsurătorile cu etichete foarte schimbătoare (user_id).
Retenţii: măsurători la cald 30-90 zile, sub-eşantionare până la 13 luni; busteni fierbinte 7-14 zile, cald 30-90 zile, rece 1-3 ani (luând în considerare regulamentul).
WORM/imutabilitate pentru jurnalele de audit, Object Lock.
Politici de compresie/partiționare și ILM; indici separați pentru audit/PII-safe.
Eșantionarea jurnalelor pe INFO/DEBUG; EROARE/AUDIT - complet.

13) Siguranță și conformitate

PII/PCI: tokenizare, hashing, mascare; minimizarea datelor.
RBAC/ABAC: acces la jurnale/piste - după rol, separarea copertinelor.
Secrete și chei: nu logați acreditări/jetoane; detectoare secrete pe CI.
Pistă de audit: intrări în panoul de administrare, modificări ale limitelor/plăților, ajustări manuale ale soldului - numai la indicele AUDIT, invariabil.
Legal-hold: un mecanism de înghețare a retențiilor în investigații.

14) Calitatea datelor de telemetrie

Schema Registry pentru busteni/evenimente (versioning, compatibilitate).
Nomenclatura unică a câmpurilor (snake_case, unități de măsură).
Validarea la injectare (picătură de evenimente murdare, măsurători ale căsătoriei).
Backpressure și protecție împotriva „furtunilor de jurnal”.

15) procese SRE, apeluri online și runbooks

Matrice oncall și escaladări; Ore liniștite și rotații.
Cărțile de alergare sunt legate de alerte (pași de diagnosticare, rețete SQL/LogQL, phicheflags pentru degradare).
Postmortem fără penalități, elemente de acțiune cu proprietarii și termene limită.
Indicatori de echipă: MTTD/MTTR, procent de alerte zgomotoase, acoperire Runbuk.

16) ROM și sintetice

RUM: WebVitals (LCP, CLS, INP), erori frontale, amprente digitale ale dispozitivului, regiuni/furnizori.
Sintetice: scenarii „registratsiya→depozit→spin→vyvod” din diferite regiuni; locații private pentru căi interne (admin/back office).

17) Practici de lansări, experimente și phicheflags

Conectăm piese cu versiuni de lansare (comite/artefact).
A/B etichete în bagaje → tabloul de bord „efectul experimentului asupra SLI”.
Canare/Blue-Green: panouri separate pentru canari, rata de ardere a bugetului de eroare.

18) Semnale de detectare și antifraudă a anomaliilor

Declanșatoare statistice (conștiente de sezonalitate) privind scăderea ratei/riscul de încărcare/creșterea noilor carduri.
Corelații: „creșterea depozitelor nereușite + noua versiune a adaptorului PSP”.
Reguli de streaming (Kafka → Flink) pentru reacții în timp aproape real.

19) Foaie de parcurs privind implementarea (pe etape)

Etapa 0 - Bază: jurnale JSON, câmpuri de corelație unificate, metrici de serviciu de bază, tablouri de bord comune, primele alerte.
Etapa 1 - Urmărire: instrumentație OTel, eșantionare cap + coadă, conectare la bușteni.
Etapa 2 - Business SLI/SLO: plăți/ieșiri/valori de joc, alerte SLO, procese de eroare-buget.
Etapa 3 - Maturitate: Alerte-as-Code, ILM, retenții separate, anomalii-detectare, per-service runbuki, practici SRE în CI/CD.

20) Lista de verificare

• JSON numai jurnale, chei unice, PII mascare.
• În fiecare eveniment: 'trace _ id',' span _ id', 'corelation _ id',' tenant '.
• Metrica acoperă semnalele de aur și fluxurile de afaceri.
• SLO-urile sunt descrise, există un buget de eroare și alerte privind rata de ardere.
• Prelevarea de probe este activată pentru erori de plată și latențe ridicate.
• ILM și WORM sunt configurate pentru jurnalele de audit.
• RBAC pentru telemetrie, audit de acces.
• Tablouri de bord pentru plăți/Game Core/Player Journey/Infra.
• Runbooks sunt legate de fiecare alertă critică.
• Postmortems și elemente de acțiune - în restanțe cu proprietarii.

Apendicele A: Atribute OpenTelemetry (recomandare)

"service. nume „,” serviciu. versiune ',' implementare. mediu "

'cloud. Regiunea ',' k8s. pod. nume ',' k8s. container. nume "

'tenant', 'brand', 'market', 'ab _ test', 'user _ segment'

"plata. metoda ',' psp ',' joc. furnizor „,” joc. "

Apendicele B: Exemple de valori pentru SLO

'payment _ success _ ratio', 'retragere _ ttw _ p95' (time-to-wallet), 'psp _ latency _ p99'

'game _ spin _ latency _ p95', 'provider _ error _ rate', 'kafka _ consumer _ lag'

'auth _ success _ ratio', 'kyc _ step _ dropout', 'cache _ hit _ ratio'

Apendicele C: Rețete rapide de investigare

"Creștere 'payment _ error _ rate" "→ comparați prin PSP/regiune/metodă, verificați urmele, consultați versiunea adaptorului.
„p99 rotiri ↑” → de urmărire, front→geytvey→provayder furnizor de verificare/canale, limitele firului de piscină, retraiele de rețea.
„Kafka lag” ↑ → consumatori de sănătate, producători retro, backpressure, chiuvete lente/DB.