API de análise e métricas de desempenho

1) Por que é necessário

• provar a execução de SLO e SLA,
• gerenciamento da largura de banda e da economia dos pedidos,
• localizar rapidamente a degradação (p99-caudas, picos 5xx),
• priorizar a otimização em relação ao impacto empresarial.

Objetivo: um único modelo de observabilidade, onde cada solicitação é monitorada de perímetro a BD com identificadores comuns e SLI compatíveis.

2) Taxonomia métricas

Técnico: RPS, latência (p50/p95/p99), error rate (4xx/5xx), saturação (CPU, memory, arquivos-desc), queue time.
Alimentos: operações bem sucedidas/min, conversão de passo (200/total), rate-limited (429), retais, segmentos personalizados.
Custo: vale/request (CPU-ms + egress + solicitações de BD), custo de fici/endpoint, $/tenante, $/1k chamadas.

3) «Sinais de ouro»: RED e USE

• Rate - consultas/segundos (por endpoint/tenante/plano).
• Errors - 4xx/5xx/429 participações e absolutos.
• Duration - p50/p95/p99 end-to-end e por estágio (ingress → app → DB → terceiros).

• Utilization - Carregar CPU/IO/canal.
• Saturation - filas (run-queue, backlog, DB wait).
• Errors - erros de driver/timeout.

4) Definições básicas e fórmulas

Availability SLI: `1 − (5xx + gateway_timeout) / all_requests`.
Sucess SLI: '2xx/( all - 429 _ shadow)' (excluindo bloqueios «shadow»).
Apdex: `(|T≤T| + 0. 5·|T≤4T| )/all ', onde' T 'é o limite «bom» alvo.
Tail amplificação: 'p99 _ total - max (p99 _ estágio _ i)' - contribuição de filas/composição.
Error budget (mês) a 99. 9%: 'orçamento = 0. 1% tempo _ período '.

Recomendados bins percentáveis histogramas latency: '[5ms, 10ms, 25ms, 50ms, 100ms, 250ms, 500ms, 1s, 2. 5s, 5s]`.

5) SLI/SLO e alerting por burn-rate

• Disponibilidade: ≥ 99. 9 %/30 dias.
• p95 latência 'GET/wallet/balance' <150 ms; 'POST/payments' <400 ms.
• Erros '5xx' <0. 2%. '429' (sólidos) <1% do tráfego total.

• 2% do orçamento para 1 hora ou 5% para 6 horas → para o engenheiro.
• 10% por 24 horas → priorização da RCA.

6) Conjunto de métricas (o que é obrigatório)

• `http_requests_total{route,method,status,tenant,plan}`
• 'http _ request _ duration _ secunds _ bucket
• `retries_total{reason}`, `rate_limited_total{key,policy}`
• Tamanho do corpo: 'request _ bytes', 'response _ bytes'

• `db_client_requests_total{op,table}`, `db_latency_seconds_bucket{op}`
• 'cache _ ops _ total\op', hit-rate do cachê de chamadas externas: 'outbound _ calls _ total\provider, op\', latency/erros/tempo de fila/pula: comprimento/atrasos, USE ativos de recursos: CPU, RSS, FD, GC pausas

Editoras de negócios: «tenant _ id», «region», «kyc _ level», «plan», «feição _ flag».

7) Rastreamento e correlação (OpenTelemetry)

W3C Trace-Context ('traceparent', 'tracestate') em todos os hopes.
Span-s em estágios: ingress → authZ → app handler → DB/Redis → PSP/exterior.
Atributes/editoras: 'http. route`, `enduser. id`, `tenant. id`, `idempotency. key`, `risk. score`.
Excemplars: Vincule os pontos em gráficos latency/erro a trace-id específicos.

• head-based 1-10% para caminhos «normais»,
• tail-based para as caudas (pegar lentos/errados),
• adaptativo para picos e incidentes.
• Baggage: transferência 'tenant '/' risk' para cortes sem marcação de cada evento.

8) Logs: estrutura e privacidade

JSON estruturado; campos obrigatórios: 'ts', 'trace _ id', 'span _ id', 'road', 'status', 'latency _ ms', 'tenant', 'user _ id _ hash'.
Política PII: disfarce o PAN/PII; proíba segredos/tokens.
Sampling logs: alta para 4xx/5xx/429 e «longas» consultas.

9) Mapa de dashboards (conjunto mínimo)

1. Exec-Summary: RPS, Availability, Erro-rate, p95/p99 latency, 429 participações, burn-rate orçamento.
2. Per-Road: top endoints RPS/erros/cauda; comparação de versões (canário).
3. Per-Tenant/Place: líderes de carga/custo/erro.
4. Dependency Health: DB, cachê, PSP/externo - latency, erros, saturation.
5. Capacity: CPU/RAM/FD, filas, conexion pool, GC, limites de contêineres.
6. Segurança/Abuse: 401/403, 429/políticas, corte geo/ASN, picos de retrações.

10) Alertas (liminares e tendências)

'error _ rate <rota 03'> 2% (5 minutos) e RPS> N → pager.
'p99 _ latency <critical a.'> limiar de destino (10 minutos).
'burn _ rate' sobre o orçamento (consulte parágrafo 5).
DB 'timeouts '/' deadlocks' ou 'queue _ time'> 'X mc'.
Provedores externos: 'outbound _ 5xx _ rate <provider 03'> 1% + dependentes SLO.

11) Planejamento de capacidade e desempenho

A Lei Little é 'L = £ W' (comprimento médio da fila = tráfego x tempo médio).
O p95 alvo é 'ingress + app + DB + external + queue'.
Concurrency budet: Registramos o máximo de operações simultâneas de write.
Budet-métrica: «ms CPU para consulta»; Temos uma reserva de 30% a 50% para o pico.
Interação com rate-limit: Mede a proporção de solicitações junto ao teto da quota e os efeitos sobre a latência.

12) Verificações de carga e sintética

Tipos: carga básica, burst x 10, «estágios», plateias de longo prazo, stress/chaos (matar noodles, atrasos na rede), sintético em cenários críticos de clientes.
Perfil: CPU/alloc/lock-content, N + 1 (SQL/HTTP), códigos lentos.
Controle de regressão: comparação p95/p99/erros antes/depois do lançamento (canário).

13) Custo (Costa-Observabilidade)

Métricas de custo: 'cpu _ ms', 'egress _ bytes', 'db _ calls', '$ per 1k requests'.
Alocação em endpoint/tenante/ficch: tags de billing do orquestrador + métricas de carga → relatório sobre a economia unit da API.
Algoritmo de otimização: Selecionamos os endpoints TOP pela obra 'traffic x cost x (p95 - alvo)'.

14) Para-tenente analista e «justiça»

Todas as métricas-chave estão com a editora 'tenant _ id/place'.
Proporção de clientes «pesados» na cauda p99; limites/quotas individuais e orçamentos de retrações.
Sheiring justo, quando sobrecarregados, reduzimos a proporção de aluguéis.

15) Especificidades do iGaming/Finanças

Cortes por 'kyc _ level', 'risk _ tier', 'payment _ method'.
SLI para caminhos «em dinheiro» («POST/deposits», «POST/withdrawals»): abaixo alvo p95, orçamentos individuais de erros.
Métricas Time-to-Wallet (TTW), proporção de bloqueios automáticos com antifrode, conversão de pagamento.
Auditoria: Registros imutáveis para ações financeiras e soluções de antifrode.

16) Ferramentas: práticas de implementação

• `api_http_requests_total` (counter)
• `api_http_request_duration_seconds` (histogram)
• `api_outbound_requests_total`, `api_db_query_duration_seconds`
• `api_rate_limited_total`, `api_retry_total{reason}`

Лейблы: `route`, `method`, `status_class`, `tenant`, `region`, `version`, `canary`, `provider`, `db_table`.
Cardinalice: evite valores livres (user _ id), use «baquetes »/hash.
Exemplars: ligue a histogramas p95/p99 → clique sobre trace.

17) Antipattern

Média em vez de percêncilos; Não se dividem em classes estatais.
«Rota »/« path» (ID dinâmico «acoplado» nas editoras).
Editoras de alta vitalidade (raw user _ id, IP).
Nenhuma contabilidade separada de provedores externos (PSP/3rd-party).
Alertas de ruído (uma única e uma porta).
p99 sem contar com queue time (mascara a degradação real).

18) Lista de controle pró-prontidão

• Definidos por SLI/SLO e erro-boodget, alinhados com o negócio.
• Histogramas latency e estatais unificados; p95/p99 em dashboards.
• Traçado completo (OTel), correlação logs/métricas/trailers.
• Alertas burn-rate (duas janelas), liminares p99 e error-rate.
• Para-tenente/para-planear cortes e relatórios de custo.
• Dashboard: Exec, Per-Road, Dependencies, Capacity, Abuse.
• Cenários de carga (burst/platô/stress), perfilação.
• Políticas de retrações com jitter; contabilizar o impacto dos retrações no RPS.
• Documentação SLA/SLO para associados e clientes públicos.
• Retensamento/camuflagem de logs, proteção PII.

19) TL; DR

Construa a observabilidade em torno de SLI/SLO e error-budget, mede RED/USE, recolha os histogramas latency com p95/p99 e «queue time», espalhe um trace-id do perímetro ao BD, use tail/adaptativo-sampling, mantenha o per-tenant/corte de pé e burn-rate-alerting de duas janelas. Planeje a capacidade segundo as leis de fila e os efeitos sobre as métricas de negócios; antipattern - média em vez de percenteis, alta cardealidade e dependências externas não contabilizadas.