Monitoraggio e logica

1) Perché è importante nel iGaming

Denaro in tempo reale: accezione dei depositi, versamenti immediati, calcolo delle scommesse e delle vincite, tornei - tutti sensibili a ritardi e guasti.
Controllo e regolazione: è necessaria la tracciabilità completa (KYC/AML, pagamenti, limiti di gioco responsabile).
Architettura distribuita complessa: API gateway, pianificazione dei pagamenti, EDA/Kafka, servizi fornitori, clienti mobili, fronti, bus BI.
Obiettivo: ridurre la MTTD/MTTR, mantenere la SLO a segno d'oro e fornire la forenseria degli incidenti.

2) Concetti base di osservabilità

Loghi: eventi dettagliati (strutturati da JSON) adatti a indagini e verifiche.
Metriche: unità nel tempo (TSDB), adatte a SLO/alert.
Trainer: catene causali di query (trace/span) attraverso servizi/broker/database.
Gli eventi di dominio (BetPlaced, DepositApproved) sono un ponte tra le metriche aziendali e la tecnologia.

3) «Segnali d'oro» e SLI/SLO per il iGaming

Latency: P95/P99 su flussi critici (autorizzazione, deposito, tasso, inizio sessione, spin).
Traffic: RPS API, TPS per i pagamenti, EPS per gli eventi.
Errors: 5xx/4xx, decline-rate, failed-withdrawals, errori dei provider.
Saturation: CPU, memory, IO, Kafka lag, DB connections, thread-pools.

• SLI: `1 - (failed_payments / total_payments)`
• SLO: 99. 7% di autorizzazioni di carte in 30 giorni (errore budget 0. 3%).

4) Architettura di raccolta e lavorazione

1. Iniezione: agenti (OTTEL Collector/Fluent Bit), SDK nell'applicazione, RUM/sintetico.
2. Routing: broker/bus di telemetria (OTLP/HTTP/GRPC), filtri e maschera PII.

• Metriche: TSDB (aggregazioni, downsampling).
• Logi: hot (indicizzabili )/warm (meno indicizzabili )/cold (archivio oggetti, WORM).
• Trailer: time-indexed storage con rettifiche e tail-sampling.
• 4. Analisi/alert, regole (PromQL/LogQL/SQL), correlazione con tracamia e rilascio.
• 5. Dashboard: viste tecniche + business (pagamenti, RNG/provider, motore di tornei).

5) Lo standard del covo (JSON) e la tassonomia degli eventi

Si consiglia una logica JSON rigorosa, chiavi unificate e livelli.

Уровни: `DEBUG < INFO < NOTICE < WARN < ERROR < FATAL < AUDIT`

Таксономия: `auth.`, `payment.`, `gameplay.`, `risk.`, `psp.`, `kyc.`, `rg.` (responsible gaming), `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"
}
}

• Mascheriamo PAN/BIN (memorizzando solo i campi validi), email/telefono - hash/token.
• Taglia l'IP fino a/24.
• Proibisce il testo libero in «extra» per l'input personalizzato senza assistenza sanitaria.

6) Correlazione: trace _ id, correlation _ id, idempotency _ key

Aggiungi «trace _ id» (da OTEL), «span _ id», «correlation _ id» (passante per il processo aziendale), «idempotency _ key» per le richieste di pagamento.
Trasmettere baggage (tenant/brand, market, A/B-variante) per costruire tagli.

7) Metriche: tecnica e business

Tecnico: RPS, p95 latency, error rate, saturation, GC, pool usage, Kafka consumer lag.
Business: CR registratsii→depozit, autorizzazioni di successo, annullamenti, NGR/GGR, ARPPU, anomalie RTP, drop-off alla fase KYC, quota di limiti responsabili.

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

8) Tracing e OpenTelemetry

Strumentalizziamo il gateway, l'orchestratore, il nucleo giochi, le notifiche, KYC/AML, l'integrazione con i provider.
Head-sampling per flusso totale + tail-sampling (aumentato) per errori/latent span e pagamenti.
Presentazione del contesto: «traceparent »/« tracestate», Kafka headers, gRPC metadata.
Annotiamo gli eventi di dominio «BetPlaced», «WithdrawalRequested».

9) Alerting senza rumore

Soglie a più zeri (warning/critical), soppressione del flapping, deduplicazione, time slot.
Correlazione: colleghiamo «altezza 5xx» + «Kafka lag» + «p95 latency PSP» a un incidente.
Alert SLO-based: spendiamo error-budget - scaliamo.
Alerts-as-Code (GitOps), gelosia e test di regole.

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) Ricerca nei fogli (esempio di LogQL)

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

L'obiettivo è quello di eliminare rapidamente il rumore e evidenziare i guasti «costosi» nella regione di destinazione.

11) Dashboard: cosa obbligatoria

Pagments Health: successo/rifiuto per PSP, latency per metodo, mappa delle regioni, SLA provider.
Game Core: RPS per provider, p95 schiena, errato ratio SDK, anomalie RTP per slot.
Player Journey: registratsiya→KUS→depozit→igra→vyvod (vortice di conversione, tempo tra i passi).
Infra: Kafka lag, DB connessioni, cache hit ratio, cluster Kubernets (griglia sottostante/nodi).

12) Conservazione, retenza e costo (FinOps)

La cardinalità è sotto controllo: evitare le metriche con etichette altamente modificabili (user _ id).
Retenze: metriche hot 30-90 dn, downsampling fino a 13 mes; logi hot 7-14 dn., warm 30-90 dn., cold 1-3 anni (tenendo conto della regolazione).
WORM/immutability per i logi di controllo, Object Lock.
Compressione/partizionamento e regole ILM indici separati per audited/PII-safe.
Sampling dei reparti su INFO/DEBUG; ERRORE/AUDIT- Completi.

13) Sicurezza e compliance

PII/PCI: tornitura, hash, occultamento; Ridurre al minimo i dati.
RBAC/ABAC: accesso a login/trade - per ruolo, separazione dei tenti.
Segreti e chiavi: non logificare credentials/token; rilevatori di segreti su CHI.
Trail di controllo: accessi all'admink, modifiche ai limiti/pagamenti, regolazioni manuali del saldo - solo nell'indice AUDITS, invariate.
Legale-hold - Meccanismo di congelamento delle retene durante le indagini.

14) Qualità dei dati della telemetria

Schema Registry per loghi/iventi (versioning, compatibilità).
Carattere unico dei campi (snake _ case, unità).
La validazione sull'iniezione (il drop degli eventi sporchi, le metriche sul matrimonio).
Backpressure e protezione contro le tempeste.

15) Processi SRE, oncall e runbuki

Matrice Oncall e escalation; Quiet Hours e rotazioni.
I runbuki sono collegati agli alert (passi diagnostici, prescrizioni SQL/LogQL, ficcoflagi per il degrado).
Postmortem senza punizioni, action items con proprietari e deadline.
Indicatori di comando: MTTD/MTTR, percentuale di alert rumorosi, rivestimento con runbook.

16) RUM e sintetico

RUM: WebVitals (LCP, CLS, INP), errori di fronte, impronte digitali, regioni/provider.
Sintetica: scenari «registratsiya→depozit→spin→vyvod» provenienti da diverse regioni; luoghi privati per percorsi interni (adminca/back office).

17) Pratiche di lancio, sperimentazione e ficcoflag

Trailer con versioni di release (commit/artefact).
Tag A/B in baggage «effetto SLI».
Canary/Blue-Green: pannelli separati per canarini, errore-budget burn rate.

18) Rilevamento di anomalie e segnali anti-frode

Trigger statistici (seasonality-aware) su decline-rate/marceback-risk/comparsa di nuove mappe.
Correlazioni: «aumento dei depositi non pagati + nuovo rilascio dell'adattatore PSP».
Regole di streaming (Kafka n'Flink) per le reazioni near-real-time.

19) Road map di implementazione (per fasi)

Fase 0 - Base: loghi JSON, campi di corellazione unificati, metriche di base dei servizi, dashboard comuni, primi alert.
Fase 1 - Tracing: utensili OTEL, head + tail sampling, collegamento con i loghi.
Fase 2 - Business SLI/SLO: pagamenti/conclusioni/metriche di gioco, SLO-alert, error-budget processi.
Fase 3 - Maturità: Alerts-as-Code, ILM, retenze separate, anomalia-oggetto, per-servizio runbook, pratiche SRE in CI/CD.

20) Foglio di assegno per la gelosia

• Login solo JSON, chiavi unificate, travestimento PII.
• In ogni evento: «trace _ id», «span _ id», «correlation _ id», «tenant».
• Le metriche coprono i segnali d'oro e i flussi di business.
• SLO descritto, ci sono error-budget e alert sul burn rate.
• Tail-sampling è abilitato per errori di pagamento e latitanza elevata.
• I file ILM/Retensioni e WORM sono configurati per i logi di controllo.
• RBAC per la telemetria, controllo dell'accesso.
• Dashboard su Payments/Game Core/Player Journey/Infra.
• I runbook sono collegati a ogni alert critico.
• Postmortem e action items - in backlog con i proprietari.

Allegato A: attributi OpenTelemetry (raccomandazione)

`service. name`, `service. version`, `deployment. environment`

`cloud. region`, `k8s. pod. name`, `k8s. container. name`

`tenant`, `brand`, `market`, `ab_test`, `user_segment`

`payment. method`, `psp`, `game. provider`, `game. id`

Allegato B: esempi di metriche per SLO

`payment_success_ratio`, `withdrawal_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`

Applicazione C: prescrizioni rapide per le indagini

«Cresce 'payment _ error _ rate'» per confrontare PSP/regione/metodo, controllare i trailer tail, vedere il rilascio dell'adattatore.
«p99 spin» per tracciare il , controllare il provider/canale, i limiti dei thread pool, i retrai di rete.
«Kafka lag» dei consumatori health, dei produttori retrai, backpressure, dei sinks lenti/database.