Operações e Gerenciamento de → da Alerta

Alertas de capacidade de sistema

1) Por que é necessário

Alertas de recipiente alertam para a aproximação dos limites técnicos muito antes do incidente, "estamos a 80% do teto. Para os negócios de alimentos, é diretamente sobre o dinheiro: apostas/depósitos perdidas, sessões de drop, atrasos de jogos ao vivo e recusas de provedores = receita perdida, reputação, multas e reembolsos.

• Previsivelmente suportar as cargas de pico (Ivents, torneios, striptease, grandes campanhas).
• Incluir skailing automático na hora e planejar capacity uplift.
• Reduzir o barulho e acordar «caso» quando o SLO/dinheiro corre risco.
• Dar recomendações precisas aos engenheiros através do runbook.

2) Conceitos básicos

Capacidade (Capacity): largura de banda mais sustentável possível (RPS/TPS, conectórios, IOPS, throughput).
Headroom: reserva entre a carga atual e os limites.
SLO/SLA: metas de disponibilidade/tempo de resposta; Os alerts devem ser «SLO-aware».
Burn-rate: velocidade de «queima» do orçamento SLO erros/latência.
High/Low Watermark: níveis superiores/inferiores para ativação e recuperação automática.

3) Arquitetura de sinais e fontes de dados

Telemetria: métricas (Prometheus/OTel), logs (ELK/ClickHouse), traçados (OTel/Jaeger).
Abordagem de camadas: alertas por camadas (Edge → API → serviços de negócios → filas/striptease → BD/cachês → armazenamento de arquivos/objetos → provedores externos).
Contexto: ficheflags, lançamentos, campanhas de marketing, torneios, geo.
Acidente de pneu: Alertmanager/PagerDuty/Opsgenie/Slack; referência ao runbook e à matriz de escalações.

4) Métricas-chave por camadas (o que monitor e porquê)

Edge / L7

RPS, 95-/99-Percentil latency, Error rate (5xx/4xx), open connections.
Rate-limits/quotas, drops на CDN/WAF/Firewall.

API-шлюз / Backend-for-Frontend

Saturation por worker/pool, fila de pedidos, timeouts para downstream.
Proporção de degradação (fallbacks, circuito-breakers).

Filas/Streaming (Kafka/Rabbit/Pulsar)

Lag/consumer delay, backlog growth rate, throughput (msg/s, MB/s).
Partition skew, rebalancing churn, ISR (para Kafka), retrai/avô leitor.

Workers de asincrona

Tempo de espera das tarefas, comprimento da fila, percentual de tarefas SLA vencidas.
Saturation CPU/Memory/FD junto aos poóis.

Cachês (Redis/Memcached)

Hit ratio, latency, evictions, used memory, clientes conectados/ops/s.
Clusters: slots/réplicas, failover events.

БД (PostgreSQL/MySQL/ClickHouse)

Active connections vs max, lock waits, replication lag, buffer/cache hit.
IOPS, read/write latency, checkpoint/flush, bloat/fragmentation.

Armazenamento de objetos/arquivos

PUT/GET latency, 4xx/5xx, egress, consultas/segundos, limites do provedor.

Provedores externos (pagamentos/CUs/provedores de jogos)

TPS limites, janelas QPS, errador rate/timeout, fila de retrações, "cost per call'.

Infraestrutura

CPU/Memory/FD/IOPS/Network saturation em nódulos/pod/ASG.
HPA/VPA eventos, pending pods, contêiner OOM/Throttling.

5) Tipos de alertas de capacidade

1. Liminares estáticos

Simples e compreensíveis: 'db _ connections> 80% max'. Bom como «sinal-farol».

2. Liminares adaptáveis (dinâmicos)

Baseado na sazonalidade e na tendência (rolling windows, descomposição STL). Permitem capturar «incomum alto para esta hora/dia da semana».

3. Orientados SLO (burn-rate)

Ativa-se quando a velocidade de travessia de error-budget põe o SLO no horizonte X-relógio.

4. Prévia (forecast-alerts)

«Em 20 minutos, com a tendência atual, a fila chegará a 90%». Usam uma previsão linear/Robust/Prophet semelhante em janelas curtas.

5. Composto (multi-sinal)

A combinação "queue _ lag ↑ '+' consumer _ cpu 85% '+' autoscaling at max '→" precisa de uma intervenção manual ".

6) Políticas de liminares e anti-ruído

• Para cima, alerta 70-75%, Crita 85-90%. Para baixo, histerese 5-10 p.p. Para não estourar o limite.

• 'for: 5m' para criaturas, 'for: 10-15m' para avisos. Modo Night, rodar não-rítico num bate-papo sem paging.

• Agrupar por serviço/cluster/geo para não gerar cartões de incidentes.

• Se o provedor KYC for ativo e os erros de API, a consequência é o pagim do dono da integração, e não de todos os consumidores.

• Durante o período de promoção, aumentar os limites de ruído para o «crescimento esperado», mas deixar as alertas SLO intactas.

7) Exemplos de regras (pseudo-Prometheus)

ALERT PostgresConnectionsHigh
IF (pg_stat_activity_active / pg_max_connections) > 0. 85
FOR 5m
LABELS {severity="critical", team="core-db"}
ANNOTATIONS {summary="Postgres connections >85%"}

ALERT StreamBacklogAtRisk
IF (kafka_consumer_lag > 5_000_000 AND rate(kafka_consumer_lag[5m]) > 50_000)
AND (hpa_desired_replicas == hpa_max_replicas)
FOR 10m
LABELS {severity="critical", team="streaming"}

ALERT ApiLatencySLOBurn
IF slo_latency_budget_burnrate{le="300ms"} > 4
FOR 15m
LABELS {severity="page", team="api"}
ANNOTATIONS {runbook="wiki://runbooks/api-latency"}

ALERT RedisEvictions
IF rate(redis_evicted_keys_total[5m]) > 0
AND (redis_used_memory / redis_maxmemory) > 0. 8
FOR 5m
LABELS {severity="warning", team="caching"}

ALERT PSPThroughputLimitNear
IF increase(psp_calls_total[10m]) > 0. 9 psp_rate_limit_window
FOR 5m
LABELS {severity="warning", team="payments", provider="PSP-X"}

8) Abordagem SLO e prioridade de negócios

Alertas de capacidade devem se referir a risk to SLO (jogos específicos/geo/métricas GGR, conversão de depósito).
Nível: alertas para o serviço on-call; Crit - O software do dono do domínio; A queda SLO é um incidente maior e um canal de comando.
Ficheflags de degradação: redução automática da carga (read-only parcial, corte de fichas pesadas, redução da frequência de jackpot broadcasts, desativação de animações «pesadas» em jogos ao vivo).

9) Skeiling automático e triggers «certos»

HPA/VPA: Não apenas por CPU/Memory, mas também por métricas de negócios (RPS, queue lag, p99 latency).
Timing Warm-up: Considerem a partida fria e os limites do provedor (ASG spin-up, bilders de contêiner, aquecimento de dinheiro).
Guerrails: condições de parar quando os erros crescem de avalanche; protecção contra «skaylim».
Capacity-playbooks: onde e como adicionar shard/partitura/réplica, como redistribuir o tráfego por região.

10) Processo: do projeto à operação

1. Mapeamento de limites: recolha os limites «verdadeiros» bottleneck para cada camada (max conns, iOPS, TPS, cotas de provedores).
2. A escolha dos predadores métricos é que os sinais mais cedo indicam «lutar em N minutos».
3. Design de liminares: high/low + SLO-burn + composto.
4. Runbook para cada crete: etapas de diagnóstico («o que abrir», «quais comandos», «para onde escalar»), três opções: contorno rápido, zoom, degradação.
5. Testes: simulações de carga (chaos/game days), «lançamentos secos» de alertas, verificação anti-ruído.
6. Ciúmes e adoção: dono do sinal = proprietário do serviço. Sem dono, não há pagodinho.
7. Retrospectivas e sintonizações: análise semanal de falsos/omissos; métrica «MTTA (ack), MTTD, MTTR, Noise/Sinal ratio».

11) Anti-pattern

CPU> 90% ⇒ pânico: sem correlação com latency/queues pode ser normal.
Um limiar para todos: regiões/zonas de tempo diferentes - perfis de tráfego diferentes.
Alert sem runbook: Um programa sem ação clara esgota on-call.
Cegueira para provedores: quotas/limites externos são frequentemente os primeiros a «quebrar» cenários (PSP, KYC, antifrode, provedores de jogos).
Não há histerese, «pilhagem» na fronteira de 80 %/79%.

12) Características de iGaming/finplatford

Picos programados: horário nobre, finais de torneios, grandes jogos; aumentar as frases de destino e preencher os cachês.
Striptease e jackpots: saltos de emissoras → limites em corretores/websites.
Pagamentos e KYC: janelas de provedores, serviço antifrode; manter rotas de reserva e «modo grace» de depósitos.
Balanço geo: falhas locais do provedor - levar o tráfego para a região vizinha, onde há headroom.
Responsabilidade: Quando você corre o risco de perder apostas/jackpots - programar instantaneamente a equipe de domínio + alerta de negócios.

13) Dashboards (conjunto mínimo)

Capacity Overview: headroom por camadas, top 3 áreas de risco, burn-rate SLO.
Stream & Queues: lag, backlog growth, consumer saturation, HPA state.
DB & Cachê: conectórios, repl-lag, p95/p99 latency, hit ratio, evictions.
Providers: TPS/janelas/quotas, timeouts/errors, custo de chamadas.
Release/Função context: lançamentos/fichiflags ao lado de curvas.

14) Folha de cheque de implementação

• Lista de limites e proprietários «verdadeiros».
• Mapa dos predadores métricos + conexão entre camadas.
• Liminares estáticos + histerese.
• SLO-burn-alerts para caminhos críticos (depósito, aposta, lançamento de jogos ao vivo).
• Alertas prognósticas na fila/striam/conectórios.
• Supressão/maintenance da janela; anti-barulho político.
• Runbook 'e com comandos, gráficos, feijoadas de degradação.
• Análise semanal de falsos efeitos e sintonização.
• Contabilizar campanhas de marketing e calendários de eventos.

15) Exemplo de modelo de runbook (reduzido)

Sinal: 'StreamBacklogAtRisk'

Objetivo: Não permitir o crescimento de lag> 10 milhões e atraso no ganho> 5 min

1. Verificar 'hpa _ desired/max', throttle/oom no pod.

2. Ver 'rate (lag)', distribuir por partituras (skew).

3. Verificar o corretor (ISR, under-replicated, network).

• Aumentar o consumo-replicas para + N, levantar max-in-flight.
• Activar o pool prioritário para «topics críticos».
• Baixar temporariamente a frequência dos ganhos secundários/enrichment.
• Se 'ASG at max' - pedir uplift temporário à nuvem; paralelamente à degradação de funções pesadas.
• Retrocesso: voltar ao perfil «tráfego normal» depois de 'lag <1 milhão' 15 minutos.
• Escalação: Dono do cluster Kafka, seguido da plataforma SRE.

16) KPI e qualidade dos sinais

Coverage:% das vias críticas fechadas com alertas de recipiente.
Noise/Sinal: no máximo 1 falso page por on-call/semana.
MTTD/MTTR: Os incidentes de recipiente são detectados ≤5 min antes dos ataques SLO.
Proactive saves: para incidentes evitados (pós-mortem).

17) Início rápido (default conservador)

BD: aviso de 75% dos conectórios/IOPS/lat; creta 85%, histerese 8-10 p.p.
Cash: 'hit <0. 9 'E' evictions> 0 '> 5 min - aviso;' used _ mem> 85% '- creta.
Filas: 'lag' altura> 3gm média por 30d + 'hpa at max' - creta.
API: `p99 > SLO1. 3 '10 min - aviso;' burn-rate> 4 '15 min - creta.
Provedores: 'throughput> 90% da quota' - Aviso; 'timeouts> 5%' - Creta.

18) FAQ

Q: Por que não alongar apenas «CPU> 80%»?
A: Sem contexto latency/filas é um barulho. O CPU por si só não é um risco.

Q: As liminares adaptáveis são necessárias?
A: Sim, para a sazonalidade diária/semanal - reduz os falsos efeitos.

Q: Como considerar o marketing/iventes?
A: Calendário de campanhas de anotação em gráficos + ajustar temporariamente o anti-ruído, mas não tocar em alertas SLO.