GH GambleHub

Operações e Gerenciamento de → Métricas de desempenho

Métricas de desempenho

1) Por que necessita de métricas de desempenho

O desempenho é a capacidade do sistema de fornecer SLO de destino em tempo de resposta e largura de banda a um custo determinado. Sem métricas, é impossível:
  • detetar degradação antes dos incidentes,
  • prever capacidade e orçamento,
  • comparar soluções alternativas (BB vs, gRPC vs REST),
  • controlar as regravações após os lançamentos.

Princípios: dicionário único de métricas, agregação de percalços (p50/p90/p95/p99), contabilidade separada de caminhos quentes e frios, contexto (versão, região, provedor, dispositivo).

2) Taxonomia métricas

2. 1 Marcos SRE básicos

Quatro sinais de ouro: Latency, Traffic, Errors, Saturation.
RED (para microsserviços): Rate, Errors, Duration.
USE (para ferro): Utilization, Saturation, Errors.

2. Níveis 2

Infraestrutura: CPU, RAM, disco, rede, contêineres, nódulos.
Plataforma/Serviços: API-endpoint, filas, cachês, BD, pneus de evento.
Experiência do cliente: Web Vitals, SDK móvel, streaming, CDN.
Plataforma de dados ETL/ELT, striptease, vitrines, BI atrasos.
Flow críticos de negócios autorizados, KYC, depósitos/pagamentos, rounds de game.

3) Catálogo de métricas-chave e fórmulas

3. 1 API e microsserviços

RPS (Requests per second).
Latency p50/p95/p99 (ms) - de preferência «end-to-end» e «backend-only».
Error Rate (%) = 5xx + 4xx validadas/todas as solicitações.
Saturation: extensão média da fila de workers, «in-flight» consultas.
Cold Start Rate (para FaaS).
Throttling/Dropped Requests.

SLO exemplo: p95 latency ≤ 250 ms com RPS de até 2k na região do EU-East; erros ≤ 0. 5%.

3. 2 Bancos de dados

QPS/Transactions/s, avg/median query time, p95 query time.
Lock Waits / Deadlocks, Row/Index Hit Ratio, Buffer Cache Miss%.
RepLag (replicação), Checkpoint/Flush time, Autoacuum lag.
Hot Keys/Skew - chave top N de carga.

A fórmula «Solicitações de núcleo» é QPS/ vCPU_core_count → um sinal de charding.

3. 3 Dinheiro e CDN

Hit Ratio (%), Evictions/s, Latency p95, Item Size percentiles.
Origin Offload (%) для CDN, TTFB, Stale-while-revalidate hit%.

3. 4 Filas/striptease

Ingresss/egress msg/s, Consumer Lag (mensagens/hora), Rebalance rate.
Processing Time p95, DLQ Rate.

3. 5 Infraestrutura/contêineres

CPU Utilization %, CPU Throttle %, Run Queue length.
Memory RSS/Working Set, OOM kills, Page Faults.
Disk IOPS/Latency/Throughput, Network RTT/ retransmits.
Node Saturation: pods pending, pressure (CPU/Memory/IO).

3. 6 Clientes Web (UX)

Core Web Vitals: LCP, INP, CLS.
TTFB, FCP, TTI, Resource Timing (DNS, TLS, TTFB, download).
Error Rate (JS), Long Tasks, SPA route change time.
CDN Geo-Latency.

3. 7 Cliente móvel

App Start time (cold/warm), ANR rate, Crash-free sessions %.
Network round-trips/session, Payload size, Battery drain/session.
Offline success rate (operações cajadas).

3. 8 Plataforma-data e relatórios

Freshness Lag (T-now → витрина), Throughput rows/s, Job Success %.
Costa por TB processado, Skew por partituras, Late events%.
BI Time-to-Render p95 para dashboards-chave.

3. 9 Flow crítico de domínios (iGaming como exemplo)

Auth p95, KYC TTV (Time-to-Verify), Deposit/Withdrawal p95.
Game Round Duration p95, RNG call latency, Provider RTT p95.
Payment PSP success rate, Chargeback investigation SLA.

4) Normalização, marcação e atribuição

Percentili contra média: p50/p90/p95/p99 - média suaviza dores de pico.
Cortes: versão do aplicativo, região, provedor, canal de rede (4G/Wi-Fi), dispositivo.
Correlação: Associamos «backend-only» e «real-user» a métricas para as cadeias de causa e efeito.
Excemplars/Pistas: Associamos os percalços extremos aos traçados.

5) Liminares e alertas (malha padrão)

Latency p95 (core API): warning> 250 ms, critical> 400 ms 5 min consecutivas.
Error rate: warning > 0. 5%, critical> 2% (endpoint, não global).
DB RepLag: warning > 2 s, critical > 10 s.
Kafka consumer lag (time): warning > 30 s, critical > 2 min.
Web LCP (p75): warning > 2. 5 s, critical > 4 s.
Mobile ANR: warning > 0. 5%, critical > 1%.
ETL Freshness: warning > +15 min, critical > +60 min от SLA.

Usamos liminares estáticos + adaptativos (sazonalidade, modelos diurnos), dedução e agrupamento de alertas de serviços/lançamentos.

6) Testes de desempenho

Tipos: baseline, stress, longo (soak), caos (degrade links/PSP).
Perfis de carga: em trailers reais (distribuição-based), «burst», picos regionais.
Metas: atingir o SLO em operações RPS e mix, validar backpressure.
Métricas de perfume: Throughput, Erro%, p95 latency, pares GC, CPU throttle, queue lag, cost/run.

Regra de regressão: o lançamento é considerado um sucesso se o p95 não for piorado> 10% em um perfil igual, e o valor da consulta (CPU-ms/consulta) não subiu> 15%.

7) Planejamento de capacidade e custo/desempenho

Modelo Demand: RPS por relógio x média de trabalho/consulta (CPU-ms, IO-ops).
Headroom: 30-50% de reserva para caminhos críticos, auto-escaling P95.
Cost KPIs: Cost per 1k requests, Cost per GB served, $ per 1 p. p. Melhorias LCP.
Armazenamento em dinheiro/desnormalização: considerar «cachê ROY» = (poupança de CPU-ms - custo de cachê).
Regiões quentes e frias: offload em CDN/edge, replicação «apenas leitura».

8) Práticas de observabilidade e perfilagem

Traçados: trace-ID distribuídos através de todos os hop's; semente inteligente (tail-based).
Métricas: Prometheus/OpenTelemetry, uma única notação de nomes e editoras.
Logi: com correlação trace/span, budget para ruído logístico, edição PII.
Perfiladores CPU/Heap/Alloc/Lock profiles, perfilação contínua (eBPF).
Instâncias-amostra: Associamos p99 picos a span/SQL/PSP-call específicos.

9) Métricas de lançamentos e comandos (para a totalidade)

DORA: Deployment Frequency, Lead Time, Change Failure Rate, MTTR.
SPACE: satisfação, desempenho, atividade, comunicação, eficiência.
Estas métricas não são sobre ferro, mas afetam diretamente a sustentabilidade do desempenho.

10) Anti-pattern

Perseguir média: ignorar p95/p99.
«Global» error rate: esconde endpoentos dolorosos.
Sem atribuição de versão, não é possível capturar a regressão do cliente.
Alert-spam, liminares sem histerese ou correção sazonal.
Otimização às cegas: falta de perfis e traçados.
Mistura de UX e backend latency: conclusões erradas sobre a experiência do cliente.

11) Folhas de cheque

Padrão único de métricas

  • Dicionário de métricas com fórmulas, unidades, donos
  • Percalços obrigatórios p50/p90/p95/p99
  • Correlação Trace e Logo-Correlação
  • Tags: região, versão, provedor, dispositivo, canal de rede
  • Liminares com histerese e dedução

Antes do lançamento

  • Basline p95/p99 em estilo e venda
  • Tráfego canário + comparação de métricas A/B
  • Bandeira fichada com retração rápida
  • Plano de observabilidade (observabilidade runbook)

Regularmente

  • Reviver o top N mais lento de consultas/SQL
  • Auditoria de políticas em dinheiro e TTL
  • Verificação de Freshness e Replicações de Base de Dados
  • Testes de degradação de provedores externos (PSP, KYC)

12) Mini playbooks (exemplo)

Degradação p95/api/payments

1. Cruze o erro% e os temporizadores PSP externos.
2. Verificar as filas de consumo de colleback.
3. Ver trace exemplos p99: espaço estreito SQL/HTTP?
4. Ativar o cachê de guias/limites, reduzir N + 1.
5. Orçamento: elevar temporariamente os recursos do Worker em 20%, incluir a autoescola.
6. Post-fix: índice por (psp _ id, status, created _ at), retrai-jitter.

Crescimento do RepLag na base de dados

1. Verificar pedidos pesados e transações longas.
2. Aumentar o paralelismo de replicação, assinar checkpoint.
3. As leituras Offload são apenas de leitura em dinheiro/réplica.
4. Nas janelas de pico, denom parcial + batches.

13) Exemplos de fórmulas/SQL (simplificado)

Error Rate por endpoint

sql
SELECT endpoint,
100. 0 SUM(CASE WHEN status >= 500 THEN 1 ELSE 0 END) / COUNT() AS error_pct
FROM http_logs
WHERE ts >= now() - interval '5 minutes'
GROUP BY 1
HAVING COUNT() > 500;

Latency p95 (TDigest/Approx)

sql
SELECT endpoint, approx_percentile(latency_ms, 0. 95) AS p95_ms
FROM http_metrics
WHERE ts >= date_trunc('hour', now())
GROUP BY 1;

Consumer Lag (tempo)

sql
SELECT topic, consumer_group,
max(produced_ts) - max(consumed_ts) AS lag_interval
FROM stream_offsets
GROUP BY 1,2;

Web LCP p75

sql
SELECT approx_percentile(lcp_ms, 0. 75) AS lcp_p75
FROM web_vitals
WHERE country = 'UA' AND device IN ('mobile','tablet')
AND ts >= current_date;

14) Incorporação em dashboards e relatórios

Cartões KPI: p95 latency, erro%, RPS, saturação com tendências WoW/DoD.
Top N «pior» endpoint/SQL/recursos, clicabável drill-down → trace.
A correlação de versões do cliente é «versão p95 LCP/INP conversão».
Mapa do Mundo: geo-latency (CDN), PSP latency por região.
Painel SLO: proporção de tempo no SLO, saída do SLO, «orçamento de erro».

15) Resultado

As métricas de desempenho são uma disciplina de sistema: dicionário unificado, percentis, atribuição, boa observabilidade e SLO rigoroso. Combinando tecnologia (laticínio, laje, kesh hits) e sinais alimentares (tempo KYC, depósito p95, LCP), você controla a qualidade da experiência e o custo de entrega - previsível e escalável.

Contact

Entrar em contacto

Contacte-nos para qualquer questão ou necessidade de apoio.Estamos sempre prontos para ajudar!

Iniciar integração

O Email é obrigatório. Telegram ou WhatsApp — opcionais.

O seu nome opcional
Email opcional
Assunto opcional
Mensagem opcional
Telegram opcional
@
Se indicar Telegram — responderemos também por lá.
WhatsApp opcional
Formato: +indicativo e número (ex.: +351XXXXXXXXX).

Ao clicar, concorda com o tratamento dos seus dados.