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.