Monitoramento e logagem

1) Por que isso é importante em iGaming

Dinheiro em tempo real: recebimento de depósitos, pagamentos instantâneos, apostas e ganhos, torneios - tudo sensível a atrasos e falhas.
Regulação e auditoria: precisa de rastreabilidade completa (KYC/AML, pagamentos, limites de jogo responsável).
Complexa arquitetura distribuída: passarelas API, orquestração de pagamentos, EDA/Kafka, serviços de provedores, clientes móveis, frentes, pneus BI.
O objetivo é reduzir o MTTD/MTTR, manter o SLO a dourados e fornecer forensagem de incidentes.

2) Conceitos básicos de observabilidade

Logi: Eventos detalhados (estruturados por JSON), aptos para investigação e auditoria.
Métricas: unidades no tempo (TSDB), adequadas para SLO/alertas.
Trailers: cadeias de causa e efeito de solicitação (trace/span) através de serviços/corretores/BD.
Eventos de domínio (BetPlaced, DepositApproved) - a ponte entre as métricas de negócios e a técnica.

3) «Dourados» e SLI/SLO para iGaming

Latency: P95/P99 sobre fluxos críticos (autorização, depósito, taxa, início da sessão, spin).
Traffic: RPS de API, TPS de pagamento, EPS de evento.
Errors: 5xx/4xx, decline-rate, failed-withdrawals, erros dos provedores.
Saturation: CPU, memory, IO, Kafka lag, DB connections, thread-pools.

• SLI: `1 - (failed_payments / total_payments)`
• SLO: 99. 7% de autorizações de cartões bem sucedidas em 30 dias (error budget 0. 3%).

4) Arquitetura de coleta e processamento

1. Injecto: Agentes (OTel Colector/Fluent Bit), SDK no aplicativo, RUM/sintético.
2. Rotação: corretor/pneu de telemetria (OTLP/HTTP/GRPC), filtros e camuflagem PII.

• Métricas: TSDB (agregações, downsampling).
• Logs: hot (indexáveis )/warm (menos indexáveis )/cold (armazenamento de objetos, WORM).
• Trailers: time-indexed armazenamento com retoques e tail-sampling.
• 4. Analistas/alertas: regras (PromQL/LogQL/SQL), correlação com tracamias e lançamentos.
• 5. Dashboards: vistas técnicas + negócios (pagamentos, RNG/provedores, motor de torneio).

5) Padrão de logs (JSON) e eventos taxonomia

É recomendado um regulamento JSON rigoroso, chaves e níveis unificados.

Уровни: `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"
}
}

• Camuflando PAN/BIN (armazenando apenas campos de política válidos), email/telefone - hash/token.
• O IP é truncado até/24, GeoIP armazenado separadamente.
• Proibindo o texto livre em 'extra' para a entrada personalizada sem saneamento.

6) Correlação: trace _ id, correlation _ id, idempotency _ key

Adicione «trace _ id» (de OTEL), «span _ id», «correlation _ id» (trace _ id), «idempotency _ key» (de solicitação de pagamento) a cada logo e métrica.
Transferir baggage (tenant/brand, market, A/B-versão) para construir cortes.

7) Métricas: técnicas e negócios

Técnico: RPS, p95 latency, error rate, saturação, GC, pool usage, Kafka consumer lag.
Negócios: CR registratsii→depozit, autorizações bem sucedidas, cancelamentos de pagamentos, NGR/GGR, ARPU, anomalias RTP, drop-off na etapa KYC, proporção de limites responsáveis.

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

8) Tracing e OpenTelemetry

Ferramenta gateway, orquestrador de pagamento, núcleo de jogo, notificações, KYC/AML, integração com provedores.
Head-sampling para fluxo total + tail-sampling (elevado) para erros/spans latentes e pagamentos.
«Traceparent »/« tracestate», Kafka headers, gRPC metadata.
Anotamos com os eventos de domínio «BetPlaced», «WithdrawalRequested».

9) Alerting sem ruídos

Liminares múltiplos (warning/critical), supressão de flapping, dedução, slots de tempo.
Correlação: Associamos «crescimento 5xx» + «Kafka lag» + «p95 latency PSP» → um incidente.
Alertas SLO-based: desperdiçamos o erro-boodget - escalamos.
Alerts-as-Código (GitOps), revezamento e testes de regras.

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) Pesquisa por logs (exemplo LogQL)

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

O objetivo é afastar rapidamente o barulho e destacar as falhas «caras» na região alvo.

11) Dashboards: o que é obrigatório

Payments Health: sucesso/rejeição por PSP, latency por método, mapa de regiões, provedores SLA.
Game Core: RPS de provedores, p95 costas, errador ratio SDK, anomalias RTP de slot.
Player Journal: registratsiya→KUS→depozit→igra→vyvod (vórtice de conversão, tempo entre os passos).
Infra: Kafka lag, conexões DB, cachê hit ratio, cluster Kubernetes (grade de pod/nó).

12) Armazenamento, retenção e custo (FinOps)

A cardinalidade está sob controle: evitar métricas com editoras altamente variáveis (user _ id).
Reticências: métricas hot 30-90 dn., downsampling até 13 m.; logi hot 7-14 dias, warm 30-90 dias, cold 1-3 anos (considerando a regulação).
WORM/imutability para logs de auditoria, Object Lock.
Compactação/particionamento e políticas ILM; índices individuais para a auditoria/PII-safe.
Sampling logs em INFO/DEBUG; ERROR/AUDIT - Completos.

13) Segurança e complacência

PII/PCI: toquenização, hasteamento, camuflagem; Minimizar os dados.
RBAC/ABAC: acesso a logs/trens - por papel, divisão de tentes.
Segredos e chaves: não logar credentals/tokens; detectores de segredos em CI.
Trailer de auditoria: entradas de adminca, alterações de limites/pagamentos, ajustes manuais de balanço - apenas no índice de AUDITs, invariavelmente.
Legal-hold - mecanismo de congelamento de retenções nas investigações.

14) Qualidade dos dados da telemetria

Schema Registry para logs/iventes (versionização, compatibilidade).
Marcação de campo unificada (snake _ case, unidades).
Validação na injeta (drope de eventos sujos, métricas sobre casamento).
Backpressure e proteção contra «tempestades de logs».

15) Processos SRE, oncall e runbooks

Matriz oncall e escalação; Quiet Hours e rotações.
Os runbooks estão ligados a alertas (passos de diagnóstico, receitas SQL/LogQL, fichiflags para degradação).
Postmortem sem punições, action items com proprietários e deadline.
Indicadores de comando: MTTD/MTTR, porcentagem de alertas ruidosas, revestimento de runbooks.

16) RUM e sintético

RUM: WebVitals (LCP, CLS, INP), erros de frente, impressões digitais, regiões/provedores.
Sintéticos: cenários «registratsiya→depozit→spin→vyvod» de diferentes regiões; localização privada para caminhos internos (adminca/back office).

17) Práticas de lançamentos, experiências e fichiflags

Trailers Linkem com versões de lançamentos (commit/artefact).
A/B-tags em baggage → dashboard «influência da experiência em SLI».
Canary/Blue-Green: painéis individuais para canarinhos, erro-budget burn rate.

18) Detecção de anomalias e sinais anti-frod

Desencadeadores estatísticos (seasonality-aware) em decline-rate/chargeback-risk/saliência de novos cartões.
Correlações: «Aumento de depósitos indevidos + novo lançamento do adaptador PSP».
Regras de streaming (Kafka → Flink) para reações near-real-time.

19) Mapa de tráfego de implementação (por etapas)

Fase 0 - Base: Logs JSON, campos coreanos unificados, métricas básicas de serviços, dashboards compartilhados, primeiros alerts.
Etapa 1 - Tracing: ferramentas oTEL, head + tail sampling, associação com logs.
Fase 2 - Negócios-SLI/SLO: pagamentos/conclusões/métricas de jogo, alertas de SLO, processos errantes.
Fase 3 - Maturidade: Alerts-as-Código, ILM, reticências separadas, anomalia-detecção, para-serviço de runbooks, práticas SRE em CI/CD.

20) Folha de cheque para ciúmes

• Logs apenas JSON, chaves unificadas, camuflagem PII.
• Em cada evento: 'trace _ id', 'span _ id', 'correlation _ id', 'tenant'.
• As métricas cobrem sinais de ouro e fluxos de negócios.
• SLO são descritos, há um erro-budget e alertas no burn rate.
• O tail-sampling está incluído para erros de pagamento e latência alta.
• O ILM/Reticências e o WORM estão configurados para os logs de auditoria.
• RBAC para telemetria, auditoria de acesso.
• Dashboard por Payments/Game Core/Player Journal/Infra.
• Os runbooks estão ligados a cada alerte crítico.
• Pós-mortem e action items - em um backlog com proprietários.

Anexo A: atributos de OpenTelemetry (recomendação)

`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`

Anexo B: exemplos de métricas para 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`

Aplicativo C: receita rápida de investigação

«Cresce 'payment _ erro _ rate'» → comparar PSP/região/método, verificar trailers tail, ver o lançamento do adaptador.
«p99 spins ↑» → rastrear front→geytvey→provayder, verificar provedores/canais, limites de thread-pool, retais de rede.
«Kafka lag» health consumers, retais produtores, backpressure, sinks lentos/BD.