Monitoramento da infraestrutura

Monitoramento da infraestrutura

1) Alvos e moldura

• Alerta para falhas antes do usuário (detecção precoce).
• Fazer diagnóstico de causa primária (from symtom to causa).
• Suporte SLO-gating lançamentos e reversões automáticas.
• Alimentar análise pós-incidente (evidence as data).

Princípios de referência: Observável by design, menos ruído - mais sinais, automação de reações, um único painel de verdade.

2) Tríade de observabilidade

Métricas (timeséries): velocidade/demanda/erro/saturação (USE/RED).
Logi: detalhamento de evento com contexto; não contêm segredos/PII.
Trailers, tratamentos distribuídos com ligações de causa e efeito.

• Perfil (CPU/heap/lock/io) eBPF para nível do sistema.
• Eventos/auditorias (K8s Events, alterações de configurs/segredos).

3) SLI/SLO/SLA - linguagem de qualidade

SLI (indicador): 'availability', 'erro _ rate', 'p95 _ latency', 'queue _ lag'.
SLO (alvo): "solicitações bem-sucedidas ≥ 99. 9% em 30 dias".
Erro Budet: desvio válido; usado para lançamentos de auto-pé.

yaml service: "api-gateway"
slis:
- name: success_rate query_good: sum(rate(http_requests_total{status!~"5.."}[5m]))
query_total: sum(rate(http_requests_total[5m]))
slo: 99. 9 window: 30d

4) Mapa das camadas de monitoramento

1. Hosts/VM/nós: CPU/Load/Steal, RAM/Swap, Disk IOPS/Latency, Filesystem.
2. Rede/LB/DNS: RPT, pacotes/drop, backlog, SYN/Timeout, health-protes.
3. Kubernetes/Orquestrador: servidor API, etcd, controladores, scheduler; sub/nós, pending/evicted, throttling, kube-events.
4. Serviços/contêineres: RED (Rate/Errors/Duration), readiness/liveness.
5. Banco de dados/cachês: QPS, lock wait, replication lag, buffer hit, slow queries.
6. Filas/pneus: consumer lag, requeue/dead-letter, throughput.
7. Armazenamento/nuvem: S3/Blob erros e latency, 429/503 dos provedores.
8. Limites do perímetro: WAF/Rate Limits, 4xx/5xx rotas, CDN.
9. Sintético: verificação HTTP de cenários (depósito/saída), TLS/certificados.
10. Economia/capacidade: per service, utilization, headroom.

5) Whitebox и Blackbox

Whitebox: exportadores/SDK dentro de serviços (Prometheus, OpenTelemetry).
Blackbox: amostras externas de diferentes regiões (availability, latency, TLS expedy).
Combinem «sinal lá fora» + «diagnóstico lá dentro».

yaml modules:
https_2xx:
prober: http http:
method: GET preferred_ip_protocol: "ip4"

6) Kubernetes: sinais-chave

Кластер: `apiserver_request_total`, `etcd_server_has_leader`, etcd fsync.
Узлы: `container_cpu_cfs_throttled_seconds_total`, `node_pressure`.
Pos: Pending/CrashLoopBackOff, OMKilled, restritos.
Planos/limites: Requests vs Limits, PodDisruptionBudget, HPA/VPA.
Rede: NetworkPolicy drop, connack exhaustion.

Дашборды: «Cluster health», «Workload saturation», «Top erroring services».

7) BD e filas

PostgreSQL/MySQL: replication lag, deadlocks, slow query %, checkpoint I/O.
Redis/Memcached: hit ratio, evictions, rejected connections.
Kafka/RabbitMQ: consumer lag, unacked, requeue, broker ISR, disk usage.

8) Métricas RED/USE e correlações de negócios

RED: `rate` (RPS), `errors` (4xx/5xx), `duration` (p95/p99).
USE (para recursos): Utilization, Saturation, Errors.
Vincule-se ao produto: depósitos/pagamentos de sucesso, bandeiras de frod, conversão são «guardas» no lançamento canário.

9) Estrutura de alerting

Tier-1 (page): incidentes que afetam o SLO (disponibilidade, 5xx, latência, falha de componentes críticos de cluster).
Tier-2 (tíquete): degradação da capacidade, aumento de erros sem afetar o SLO.
Tier-3: tendências, capacidade preditiva, certificados vencidos.

As regras de escalação são: tempo de silêncio/compressão de duplicado, rotação on-call, «follow-the-sun».

yaml route:
group_by: ["service","severity"]
receiver: "pager"
routes:
- match: { severity: "critical" }
receiver: "pager"
- match: { severity: "warning" }
receiver: "tickets"

10) Exemplos de regras do Prometheus

10. 1 Erros 5xx com limiar SLO

yaml groups:
- name: api rules:
- alert: HighErrorRate expr:
sum(rate(http_requests_total{status=~"5.."}[5m])) /
sum(rate(http_requests_total[5m])) > 0. 005 for: 10m labels: { severity: "critical", service: "api-gateway" }
annotations:
summary: "5xx > 0. 5% 10m"
runbook: "https://runbooks/api-gateway/5xx"

10. 2 Queima de erro-boodget (multi-window burn)

yaml
- alert: ErrorBudgetBurn expr:
(1 - (
sum(rate(http_requests_total{status!~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
)) > (1 - 0. 999) 14 for: 5m labels: { severity: "critical", slo: "99. 9" }
annotations: { summary: "Fast burn >14x for 5m" }

10. 3 Saturação do sistema (CPU Throttling)

yaml
- alert: CPUThrottlingHigh expr: rate(container_cpu_cfs_throttled_seconds_total[5m]) > 0. 1 for: 10m labels: { severity: "warning" }
annotations: { summary: "CPU throttling >10%" }

11) Logs: coleta, normalização, retenção

Padrão: logs JSON: 'ts', 'level', 'service', 'trace _ id', 'user/tenant'.
Pipline: agente (Fluent Bit/Vector) → tampão → índice/armazenamento.
Redação: camuflando PII/segredos na borda.
Retenschn: classe rápida de armazenamento (7 a 14 dias), arquivo «frio» (30 a 180 dias).
Semântica: error budgets/deprekates - canais individuais.

12) Trailers e OpenTelemetry

Use os pontos de entrada (gateway), kliyent→servis chamadas, BD/cachê/fila.
Vincule as métricas a atributos de trade (Exemplars) para navegação rápida.
OTel Colector como gateway central: filtragem, sempling, exportação para becendes selecionados.

yaml receivers: { otlp: { protocols: { http: {}, grpc: {} } } }
processors: { batch: {}, tail_sampling: { policies: [ { name: errors, type: status_code, status_codes: [ERROR] } ] } }
exporters: { prometheus: {}, otlp: { endpoint: "traces. sink:4317" } }
service:
pipelines:
metrics: { receivers: [otlp], processors: [batch], exporters: [prometheus] }
traces: { receivers: [otlp], processors: [tail_sampling,batch], exporters: [otlp] }

13) Sintéticos e verificações externas

Cenários de negócios HTTP (login, depósito, conclusão, compra).
TLS/Domain: prazo de certificados/CAA/DNS health.
Regionalidade: amostras de países-chave/provedores (rotação/listras de bloco).
O sintético deve ser alterado se o usuário não estiver disponível, mesmo com telemetria interna verde.

14) Perfilação e eBPF

Continuous profiling: detecção de funções quentes, bloqueios.
eBPF: Eventos do sistema (syscalls, TCP retransmits), em venda com overhead mínimo.
Alertas de perfil sem stininining (tíquetes), e para regravações após o lançamento, como sinal de retração.

15) Dashboards e «painel da verdade»

1. Platformm Overview: SLI/SLO para serviços essenciais, erro-boodget, alertas.

2. API RED: RPS/ERRORS/DURATION sobre rotas.

3. K8s Cluster: control-plane, узлы, capacity headroom.

4. DB/Cache: lag/locks/slow query %, hit ratio.

5. Queues: backlog/lag, falha/repetição.

6. Per-release: comparação de métricas antes/depois (janelas canárias).

7. FinOps: cost per namespace/service, idle/oversized ресурсы.

16) Incidentes, alert-barulho e escalada

Deduplicação: agrupamento por serviço/razão, supressão de cascatas.
Silêncio/maintenance: lançamentos/migrações não devem «pintar» tudo vermelho.
Runbooks: cada alerta crítica com passos de diagnóstico e «botão» de reversão.
Postmortem: Timeline, o que aprendeu, que sinais adicionaram/limparam.

17) Segurança no monitoramento

RBAC para leitura/edição de regras/datasorso.
Segredos: Tocas de Exportadores/Agentes - através do Secret Gerente.
Isolamento: métricas de clientes/tenentes - em espaços/leibes individuais.
Integridade: assinatura de agentes/bildes, configs através de GitOps (merj-review).

18) Finanças e capacidade (FinOps)

Quotas e orçamentos; Alertas de crescimento anormal.
Right-sizing: análise de solicitações/limites, reciclagem de CPU/RAM, instruções spot para tarefas não críticas.
«Costa per request/tenant» como KPI eficiência.

19) Anti-pattern

Apenas métricas de infraestrutura sem SLI personalizado.
100 + alertas «sobre tudo» → cegueira on-call.
Logi como a única fonte (sem métricas e trailing).
Dashboards mutáveis sem versionização/revezamento.
A falta de sintéticos é «tudo verde», mas a frente não está disponível.
Não há ligação com o lançamento, não se pode responder «o que mudou no momento X».

20) Folha de cheque de implementação (0-60 dias)

0-15 dias

Definir SLI/SLO para 3-5 serviços essenciais.
Incluir exportadores/agentes básicos, normalizar logs JSON.
Ajustar alertas Tier-1 (availability, 5xx, p95).

16 a 30 dias

Adicionar sintéticos em cenários críticos.
Incluir trailers (OTel) em serviços de entrada/crítica.
Dashboards «Per-release» e «error-budget burn».

31 a 60 dias

Cobrir BD/fila/dinheiro com sinais avançados.
Implantar eBPF/perfilação para serviços high-CPU.
GitOps para regras/dashboards/alertas, limpeza regular do ruído.

21) Métricas de maturidade

A cobertura de SLO de serviços essenciais ≥ 95%.
MTTA/MTTR (alvo: min/dezenas de minutos).
Proporção de alertas Tier-1 fechadas por ação automática ou reversão rápida.
Relação de alertas «úteis «/» ruidosos »> 3:1.
Revestimento sintético de todas as vias «em dinheiro» = 100%.

22) Aplicativos: mini-modelos

Prometheus - disponibilidade por classe

yaml
- record: job:http:availability:ratio_rate5m expr: sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Grafana - dica para canários

expr: histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket{version=~"stable    canary"}[5m])) by (le,version))

Alertmanager - serviço e silêncio

yaml receivers:
- name: pager slack_configs:
- channel: "#oncall"
send_resolved: true inhibit_rules:
- source_match: { severity: "critical" }
target_match: { severity: "warning" }
equal: ["service"]

23) Conclusão

O monitoramento não é um conjunto de gráficos, mas sim um sistema operacional SRE: SLI/SLO como contrato de qualidade, métricas/trailers/logs como fontes de verdade, alertas como sinal controlado, sintético como «voz do usuário», GitOps como disciplina de mudança. Construa um único caminho, desde o hóspede até a API, encaixe-o em lançamentos e retrocessos - e a plataforma será previsível, rápida e econômica.