Monitoraggio in tempo reale

(Sezione Operazioni e Gestione)

1) Perché il monitoraggio real-time

• visibilità immediata della disponibilità e dei ritardi (p50/p95/p99) delle rotte critiche
• Controllo dell'integrità degli eventi (web hook, pagamenti, RTP/limiti);
• sicurezza finanziaria (egress/costo 1k eventi, clearing/escrow);
• conformità alla compilazione (ricevute, igiene PII).

2) Tracciato architettonico

1. Producers: servizi, SDK, edge-nodi, provider di pagamenti/contenuti.

2. Gateway Ingest: ricevitori «metrics/trace/logs/events» con backpressure e quote.

3. Bus/streaming - broker con partitura (tenant/region/route), ritocco per replay.

4. Stream-processing: aggregazioni a finestre (T + 5s/T + 1m), deducibilità, normalizzazione del tempo, calcolo SLI.

5. Archivi: time-series (online), OLAP (cronologia), registri WORM (verifiche).

6. Analisi e alerting, regole SLO, rilevatori statistici, anomalie.

7. Dashboard e rune: UI per azioni (pausa/re-route/rollback/raise-limit).

• Data contracts per metriche/eventi (schemi, versioni, convalida).
• Outbox/CDC per la pubblicazione garantita degli eventi di dominio.
• Idempotency e il dedotto dì trace _ id/event _ id ".
• Clock sync: NTP/PTP, correzione «skew», cascate di tempo (event vs processing time).

3) Tipi di telemetria e semantico

Metrics (SLI): contatori/gage/istogrammi p-percentili.
Traces: passante «trace _ id/span _ id», collegamento RPC↔sobytiya↔vebkhuki.
Logs: strutturati, con'tenant _ id/region/variante '.
Business events: `PaymentAuthorized`, `WebhookDelivered`, `RTPWindowClosed`.
Receipts: ricevute/firme (per operazioni finanziarie/critiche).

4) Tempo e finestre

Viste tempo: event-time, ingest-time, processing-time.
Finestre: scorrevoli (5-30 c), nebblanti (1-5 min), ritardi idrici (watermark) per eventi tardivi.
Compatto: aggregare in un flusso (miniature di istogrammi) → memorizzare solo i bin perimetrali necessari.

5) Normalizzazione e qualità dei dati

Convalida di accesso: diagramma/intervalli/campi obbligatori; rifiutati in quarantena con etichetta di causa.
Deduplicazione per '(event _ id, producer, seq)'; memorizzare seen-cache nella memoria + KV.
Regolazione delle metriche: contro «doppio count» e «flatline» (i sensori non parlano).
Samplace: per high-QPS - adattivo, con margine di errore; Gli SLI critici sono pieni.

6) SLI/SLO (arbitro)

North Star: E2E Success Rate con target p95 per regione.

• Disponibilità per canale/regione.
• Latenza p50/p95/p99 su percorsi chiave.
• Error-rate/Retry-rate.
• Successo delle consegne Web (% delle ricevute confermate).
• Consistenza prezzi/tasse ('quete = = checkout', © 1 minore unit).
• Cost-SLI costo 1k eventi, egress/ingress per unità.

• Disponibilità ≥ 99. 95% in una finestra di 28 giorni.
• p95 vetrina da 120 ms, quete/checkout da 250 mc.
• I webhook hanno successo. Finestra 5 %/5-min.
• Δ quote↔checkout = 0 (±1 minor unit).
• Risposta al P1 da 10 min, MTTR da 60 min.

7) Alerting e rune (auto-action)

Livelli: P1 (rottura SLO/inattività), P2 (degrado), P3 (trend/rischi).
Rumore: Deadup per «trace _ id», correlazione tra catene causali.

• «PriceMismatch» → refresh directory, compressione «fx _ variante/tax _ rule _ variante», politica di compensazione;
• « »: ridefinizione dei worker, aumento del batch, priorità delle code;
• «RTP Draft» pausa promo, controllo della tabella dei pagamenti/versione, reimpostazione del profilo;
• Egress Surge consente di attivare la compressione/cash pinning/itinerario alternativo.
• Escalation: matrice 24 x 7, on-call rotazione, canali (chat/chiamata/SMS).

8) Dashboard (widget operativi)

Piattaforma di salute: disponibilità, p95/p99, errore-rate, burn-down budget.
Integrazioni/webhoop: successo, lega, prese/idampotenza, ricevute.
Checkout/prezzi - Variazioni di vitrina↔checkout, versione FX/Tax, guasti-valigetta.
RTP/limiti: Teor. vs observed RTP, l'attivazione dei limiti, l'esposizione.
FinOps: cost per 1k, egress/ingress, budget/cap-alert.
Sicurezza/Compliance: SoD, JIT, MFA, query PII, firma creta. operazioni.
Release/Flags - States Fich, regioni canarie, collegamento con incidenti.

9) Multiregion e multi-tenant

Partizionamento per tenant/region.
SLO/quote indipendenti per regione; limitazioni degli alert crocifissi (per evitare che un guasto locale «dipingesse» il mondo intero).
Zone dati attendibili: PII/Finanza - solo dove consentito; Nel comune dashbord - apparecchi/hash.

10) Sicurezza, privacy, prova

Autenticazione ingest: chiavi/mutual-TLS, rate-limits, firme pacchetti.
Riduzioni PII: token anziché primogenito, maschere/hash ID.
Ricevute (receipts): DSSE/firma per eventi finanziari/critici.
Registri WORM - Logi di verifica invariati, tagli Merkle.
Access Control: RBAC/ABAC/ReBAC, JIT per pannelli sensibili.

11) Anomalista e correlazione

Guardrails: soglie statiche SLI.
Statistiche: Shewhart/CUSUM/EWMA per i trend.
ML/segnali: stagionalità/canali/ASN/provider; l'influenza dei lanci/dei ficcoflag.
Correlazioni: collegare gli incidenti con le release, le modifiche alle configurazioni, i picchi di traffico, le promozioni.

12) Prestazioni e costi

Budget di telemetria: cap per QPS/volume; scartoffie di metriche chiacchierate.
Compressione/aggregazione: downsampling cronologia (1s→10s→1min), memorizzare gli sketch perentori.
Egress Control: cache/aggregazione locale, edge-pre-lavorazione.
Alert cost-aware - segnale se il costo/1k eventi o egress è fuori dal piano.

13) Integrazione e contratti API

"POST/ingest/metrics' (JSON/OTLP): autenticazione, quote, schema/versione.
«POST/ingest/events» (firmati): deadup/TTL/nonce.
`GET /kpis? filters = region, tennis, route '- apparecchi per UI.
«GET/traces/{ trace _ id}» è l'espansione della catena.
Вебхуки: `IncidentRaised`, `QuotaCapReached`, `PriceMismatch`, `WebhookLag`, `RTPDrift`.

14) Playbook incidenti (short-form)

P1 Dostupnost↓: cambiare routing, attivare i circuiti-breakers, ridurre i timeout dei clienti, il post di emergenza sullo stato.
P1 Quote≠Checkout: freeze promo/dinamica dei prezzi, forza-invalidità cache, confronto delle versioni FX/Tax, compensi.
P1 WebhookLag Aumenta i worker/competitività, le dimensioni batch, disattiva i webhoop non importanti.
P2 RTP Draft: pausa bonus, verifica tabelle di pagamento/versioni, estensione della finestra di sorveglianza, report.
P2 Egress Surge: compressione, edge-cache, spostamento parte del traffico, quote temporanee.

15) Metriche di qualità del monitoraggio stesso

Disponibilità UI/API ≥ 99. 9%.
Freshness: gruppo di aggiornamenti da 30 s per i pannelli operativi.
Completeness: ≥ 99. Il 5% delle fonti ha inviato i dati alla finestra.
Correctness: soluzione temporanea con riferimento ≤ 0. 1%.

MTTA/MTTR alert-pipline: P1 da 1/10 minuti

16) Assegno-foglio di implementazione

• Identificare North Star e il set SLI/SLO per regione/canale.
• Immettere data contracts e schemi per tutti i flussi di telemetria.
• Configura l'ingest con quote, backpressure e deduplicazione.
• Inverti pneumatico/strato e aggregazioni di finestre con watermarks.
• Costruisci time-series/OLAP/WORM e il collegamento con le ricevute.
• Prendere alert + run auto, matrice di escalation 24 x 7.
• Formare i dashboard secondo i ruoli:
• Includi minimizzazione PII, firme e RBAC/ABAC/ReBAC.
• Immettere metriche FinOps (cost/1k, egress, memorizzazione) e caps.
• Condurre il GameDay: la lega dei webhook, il rasincrone dei prezzi, il retro-burst, il rifiuto della regione.

17) Aggancio a iGaming/Fintech

RTP & Limits - Controllo RTP monitorato e limiti in minuti/ore, alert su «over/under pay».
Pagamenti/pagamenti: traccia completa di autorizzazioni, compensazioni e ricevute; SLA PSP.
Affiliati: spedizione di conversioni (webhook) e discussioni di escrow/compressione.
Promo: picchi di traffico, protezione delle code e prezzo egress; Guardrails per i bilanci.

18) FAQ

Il real-time è obbligatorio ovunque?
No, no. Tracciati hot - secondi/minuti (incidenti, pagamenti, webhoop). Economia/analisi - minuti/ore.

Come si combatte la falsa ansia?
Condizioni orientate SLO, aggregazione e deducibilità per «trace _ id», correlazione con le release, isteresi delle soglie.

Dobbiamo conservare tutti i cessi per sempre?
No, no. WORM - Solo per i flussi critici e di verifica il resto è downsampling/TTL.

Perché «quote≠checkout» si incontra?
Versione FX/Tax, disabilità della cache, arrotondamento. Trattata con versioni, strategie SWR e test di consistenza.

Riepilogo: Monitoraggio in tempo reale è una disciplina: contratti rigorosi dei dati, calcolo finestre, tempo normalizzato, collegamento con ricevute e alert SLO, più un pulsante di azione in ogni widget. Facendo ciò che è giusto, si riduce il MTTR, si tiene sotto controllo il budget e si scala l'ecosistema in modo sicuro su regioni e tenanti.