Observabilidade e telemetria

(Secção Tecnologia e Infraestrutura)

Resumo curto

A observabilidade é a capacidade de responder a «porque é que funciona assim?» sem o lançamento de novos bilhetes. Em iGaming, isso é crítico: torneios de pico, picos de pagamento, multiregionalidade e exigências de gambling responsável/PII. Base - métricas, logs, traçados combinados por identificadores e padrões gerais (OpenTelemetry), com contratos SLO, alertação de barulho e controle de custo.

1) Esqueleto de observabilidade: de que consiste ele

Métricas (números de horário): RED/USE, Business KPI, SLI. Armazenados no TSDB.
Logs (eventos em texto/JSON): auditoria, erros, factos de negócios, segurança.
Traçados (spen): caminho de consulta através de serviços, latências, motivos de atrasos.
Profiling: CPU/memória/eBPF stream, heap/lock-contensno.
RUM e sintético: usuários reais (web/app) + robô verificação.
Catálogo de telemetria: esquemas, políticas PII, prazo de armazenamento, marcas de valor.

2) Taxonomia de sinais e princípios

RED для API: Rate, Errors, Duration.
USE para infraestrutura: Usilization, Saturation, Errors (CPU, discos, rede, filas).
SLI/SLO: Indicadores mensuráveis (por exemplo, pedidos de sucesso/todos, p95 latency), objetivos de disponibilidade (por exemplo, "99. 9% em 30 dias"), orçamento de erros → desencadeadores de processos.
High-cardinality com inteligência: as editoras devem ser úteis em cortes (região/tenante/provedor), mas não explodir TSDB.

3) Padrões e correlação de passagem

OpenTelemetry (OTel): um único SDK/protocolo para métricas, logs e traçados.
Identificadores: 'trace _ id', 'span _ id', 'correlation _ id', 'player _ id', 'payment _ road'.
ID fluído: gateway de entrada → todos os microsserviços → pagamentos/PSP → filas/jobs → logs/métricas/span.

Exemplo: cabeçalhos de correlação

traceparent: 00-<trace_id>-<span_id>-01 x-request-id: <correlation_id>

4) Métricas: o que e como medimos

Nomeações/editoras

`service="payments-api"`, `env="prod"`, `region="eu-west"`, `tenant`, `provider="pspX"`.

Exemplos do Prometheus

prometheus
RED http_requests_total{service="api",route="/deposit",method="POST",status="200"}
http_request_duration_seconds_bucket{service="api",le="0. 25",route="/deposit"} 1234 http_request_errors_total{service="api",route="/deposit"}

USE cpu_utilization_ratio{node="n1"} 0. 71 queue_depth{queue="withdrawals"} 128

Бизнес payments_success_total{psp="X",currency="EUR"} 4521 payment_conversion_ratio{route="pspX"} 0. 948

Histogramas e exemplars

Guarde os histogramas de latência (native-historograms/hcuckets) e junte o excemprar com 'trace _ id' para saltar de 'baquete lento' para uma pista específica.

5) Logs: estruturado e seguro

Apenas JSON (nada de free-forma na venda).
Поля: `timestamp`, `severity`, `service`, `trace_id`, `correlation_id`, `player_id_hash`, `event`, `amount`, `currency`, `ip_hash`.
Camuflagem/hash PII, índice/retenção individual para sensível.
Pipline logs: parsing → normalização → enriquecimento (geo/ASN) → edição PII → indexação.

Exemplo de evento JSON

json
{
"ts":"2025-11-05T10:42:31Z",
"sev":"ERROR",
"service":"payments-api",
"event":"psp_timeout",
"trace_id":"9c5e...e2",
"route":"pspX",
"duration_ms": 3100,
"attempt":2,
"player_id_hash":"p:1b7f...",
"pii_redacted":true
}

6) Traçados: onde o tempo se perde

Span: solicitação de entrada, chamadas de provedor (PSP/Games Provers), BD/dinheiro, RPC entre servidores.
Atributos: 'db. system`, `net. peer. name`, `messaging. system`, `psp. route`, `game. provider`.

• head-based (provável) para o volume,
• tail-based (termos: erros, p95 +, segmento VIP),
• guaranteed-keep para críticos de pagamento/PII.

7) Observabilidade de frente e mobil

RUM: TTFB, FCP/LCP/CLS/INP, erros de JS, rede e routing SPA.
Reportes de crash: simbolização, desobstrução, versão de bild, dispositivo/OS.
Sintético: cenários de entrada/depósito/taxa; verificações geoespaciais.

8) SLO, SLI e orçamento de erros

Exemplo de SLO (pseudo-YAML)

yaml service: payments-api sli:
- name: availability expr: sum(rate(http_requests_total{status=~"2..    3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
- name: latency_p95 expr: histogram_quantile(0. 95, rate(http_request_duration_seconds_bucket[5m]))
targets:
availability: "99. 9%/30d"
latency_p95: "<=250ms/30d"
error_budget_policy:
fast_burn: 5% for 1h -> page, freeze deploy slow_burn: 20% for 24h -> incident, improvement plan

Alerting para erros de orçamento, não para cada métrica.
Procedimentos Freeze para combustão de orçamento - limitar lançamentos/canários.

9) Alerting sem ruídos

Multi-window, multi-burn regras: janela curta/longa.
Deduplicação/rotinagem por serviços/regiões/criticidade em on-call.
Runbook URL e layout automático de contexto (últimos depósitos, alterações de configs, gráficos de dependência).
Relógio calmo e supressão durante o trabalho de rotina.

Exemplo de regra (ideia PromQL)

promql alert: PaymentsSLOFastBurn expr: slo_error_rate_5m > 2 slo_budget_rate for: 15m labels: { severity="page", service="payments-api" }
annotations:
summary: "SLO fast burn"
runbook: "https://runbooks/payments/slo"

10) Profiling e eBPF

eBPF/profilers: flame-gráficos CPU/alloc, I/O-latência, drop de rede, anomalias syscall.
Útil para as estreitas p99, «jitter» e raras dependências.

11) Observabilidade de negócios (produt & risk)

Finanças/monetização: conversão de depósitos, TTW (time-to-wallet), auto-rotação ./setl, cancelamentos/charjbacks.
Actividade de jogo: Retenshn/strik, participação das apostas ao vivo, «pegajosidade» dos provedores.
Antifrod/abuse: velocidade de ação, correspondência de dispositivos/IP, correlação.
Indicadores RG: sessões longas, «dogão», bifes crescentes.
As métricas de negócios são correlacionadas com as métricas e lançamentos (annotation events).

12) Segurança, PII e conformidade

Dados-zonas: tags de dataset/logs ('pii = true', 'region = EU').
Disfarçar antes da indexação, com o pseudônimo de ID.
Armazenamento WORM para auditoria; Acesso de papel ao login.
Prazo de armazenamento diferente para técnico/auditoria/negócio.
A proibição de segredos crus nos logs; Checagem de scan na CI.

13) Gerenciamento de custo (FinOps)

Limite de cardinalidade: cuidado com 'user _ id', 'direction _ id'.
Particionamento/retensão: quente (7-14 dias), quente (30-90), frio (arquivo).
Sampling Trek (tail-based) e downsampling métricas.
Billing «team», «service», «tenant»: relatórios «quem queima a observabilidade».

14) Instrumental (stack de arbitragem)

Métricas: Prometheus/lake para métricas, dashboards Grafana.
Logi: Loki/ELK; originação de regras, reducção/parsing.
Trailers: Tempo/Jaeger/OTel coletores; exemplars links de métricas.
Sintético: Blackbox exportador, robôs de navegador.
Alerting: Alertmanager/integração de bate-papo, on-call rotation.
Profiling: eBPF/continuous profiling.

15) Exemplos: implementar rapidamente a base

python from prometheus_client import Counter, Histogram, start_http_server reqs = Counter('http_requests_total','', ['route','method','status'])
lat = Histogram('http_request_duration_seconds','', ['route'])
def handle(req):
with lat. labels(route=req. route). time():
status = app(req)
reqs. labels(route=req. route,method=req. method,status=str(status)). inc()

go tid:= ctx. Value("trace_id")
logger = logger. With("trace_id", tid)
logger. Info("deposit-accepted", "amount", amt, "route", route)

prometheus http_request_duration_seconds_bucket{..., le="0. 25"} 1023 # exemplar: trace_id=9c5e...

16) Processos e operacionalização

Um único dicionário de métricas/editoras (naming-guide) e um modelo de dashboards.
Release-anotações em gráficos.
Incidentes: cartão, timeline, RCA sem acusações, action items.
Alarmes de treinamento («game-day»): Simulações de baixas, atrasos de PSP, superaquecimento do cachê.
Runbooks: instruções passo a passo e links automáticos de alertas.

17) Folha de cheque da maturidade

1. OTEL SDK/coletor → uma única exportação de métricas/logs/trailers.
2. RED/USE cobre todos os serviços + SLI/SLO em API chave.
3. Correlação 'trace _ id' ⇄ logs ⇄ métricas (exemplars, jump-links).
4. Alertas de orçamento de erros com multi-burn e links de runabook.
5. RUM + sintético para «depósito/taxa/retirada».
6. Profiling (eBPF) na lista branca.
7. Políticas PII: camuflagem, áreas, acesso, prazo de armazenamento.
8. Relatório financeiro do custo da telemetria (tags 'team/service').
9. «Pronto para carga de pico»: plano de teste, camadas aquecidas, modelos alert.
10. RCA regular e revisão SLO/liminares.

18) Antipattern

Logs «lençóis» sem estrutura e «trace _ id».
As alertas de cada métrica → alert Faetig.
Histogramas sem baquetas corretas → p95 planas.
A vitalidade ilimitada das editoras → uma explosão de valor.
A falta de RUM/sintético é «tudo ok» e o usuário não.
Mistura de PII com técnicos, retoma indefinida.
O isolamento da telemetria do KPI é «latência em queda, receita também».

Resumo

A forte observabilidade é uma linguagem comum entre o produto, SRE, segurança e pagamentos. Juntando métricas, logs, pistas sob OTel, introduzindo o SLO com um orçamento de erros, tornando o alerting inteligente e o custo gerenciável, você recebe um sistema que antes notava problemas, restaurando mais rapidamente e passando previsivelmente por picos de tráfego e cargas de torneios.