Skip to content

Monitorando a validade do teste

Status do escopo (pós-congelamento de escopo 2026-05-10) — Ver ARCHITECTURE.md para os 37 MÓDULOs canônicos + 7 Test Kinds + arquitetura de safety DOM/CPOS/PIE-PA. ADRs 0014, 0019-0025 cobrem adições pós-Freeze.

Objetivo deste documento: em segundos, não horas, um operador deve conseguir responder "a medição de NGFW que acabei de coletar é realmente significativa, ou foi a infraestrutura de teste que foi o gargalo?"

O cluster existe pra carregar um Next-Generation Firewall e medir quanto da degradação de taxa/latência é o custo de descriptografia TLS do NGFW. Isso só é verdade se a infraestrutura geradora de carga (hosts UCS, kernel Linux, webservers Caddy, frotas browser-engine + synthetic-load, trunk Nexus 9000, NFS in-cluster) mantiver folga durante o teste. Se o host ou a frota saturar primeiro, todo número de NGFW que o dashboard imprime está errado.

Esta página descreve as métricas, alertas e dashboard Grafana que existem pra tornar essa condição óbvia.

Os quatro sinais

Sinal Limiar "teste invalidado" Onde aparece
TestBedInfrastructureBottleneck persona p99 > 1s e CPU de algum host > 85%, ou alguma HPA em maxReplicas Painel stat "Test bed status" do Grafana fica vermelho. Alerta Prometheus dispara severity=critical.
HostUDPBufferOverflow UDP RcvbufErrors > 0 por 2 min em qualquer host Toda medição de HTTP/3 envolvendo esse host é inválida (kernel descartou pacotes QUIC).
HostConntrackNearFull Tabela conntrack > 80% cheia Todas as medições envolvendo esse host são inválidas (kernel vai derrubar pacotes em breve).
HostNetworkPacketDrops > 100 pacotes/s descartados em NIC real Números de RTT e throughput desse host estão errados.

Qualquer um desses alertas disparando invalida o run em andamento. Pare o teste, corrija a causa, re-execute.

O que olhar primeiro

Abra o dashboard Grafana Test-Bed Infrastructure Health (UID ai-forse-infra-health). Linha de cima, quatro stat panels grandes:

Painel Verde significa Vermelho significa
Test bed status latência persona estável E CPU host < 85% E nenhuma HPA fixada Run suspeito. Investigar os próximos 3 painéis.
Hosts with tuning missing Todos rodaram host-tuning.sh apply Pelo menos um host está com sysctls default (conntrack 262K, portas 28K) — esse host vai saturar primeiro.
HPAs at maxReplicas Nenhuma fixada Frota em plena capacidade; o test bed é o limite, não o NGFW.
OOMKills (15m) Zero Pelo menos um container bateu no limit de memória. Se foi um Caddy persona, run inválido.

Tudo verde e painel de alertas vazio = medições NGFW são honestas, pode continuar.

Algo vermelho — as linhas abaixo dos stat panels mostram onde olhar: - Per-host CPU saturation — gráfico por nó, threshold vermelho em 90% - Memory + conntrack pressure — mesmo breakdown por nó - Network drops / UDP overflow / TCP retransmits — três gráficos lado a lado; não-zero em qualquer um é ruim - Pod CPU throttle + restarts — confirma qual container é a real restrição - Sysctl effective values — tabela, identifica qual host não recebeu tuning

O que é monitorado, e como

Três novos componentes vêm com esta stack:

  1. node_exporter (k8s/dut/90-node-exporter.yaml) — um DaemonSet que roda em todo nó UCS e exporta métricas kernel em :9100 pela OOBI. Sem ele, zero visibilidade de host.
  2. kube-state-metrics (k8s/dut/91-kube-state-metrics.yaml) — Deployment que expõe estado de objetos K8s (restart counts, motivos de OOMKill, réplicas HPA, etc.) como métricas Prometheus. Sem isso, metade dos alertas existentes não dispara.
  3. PrometheusRule web-agent-cluster-infra-health (k8s/dut/92-infra-prometheus-rules.yaml) — 14 alertas em 3 grupos (host, pod, "test validity") + 7 recording rules pré-agregando os joins pesados pra avaliação ficar rápida no intervalo de 30s.

A ConfigMap do dashboard fica em platform/observability/dashboards/infra-health-cm.yaml — Grafana pega via label grafana_dashboard: "1" desde que o sidecar padrão de dashboard esteja rodando.

Confirmando que o tuning está ativo

Duas verificações complementares:

# Por host, do workstation do operador (exemplo k3s)
sudo scripts/host-tuning.sh status

# Cluster-wide, via Prometheus
sum(node_nf_conntrack_entries_limit) by (instance) > 1000000

Ambos devem mostrar todo host no valor tunado (2 097 152 para conntrack). Se um host está no default kernel (~262K), o alerta TestBedSysctlMissing dispara automaticamente — não precisa lembrar de olhar.

Interpretando alertas durante um run

Um teste típico de capacidade NGFW produz os seguintes sinais quando o NGFW é o gargalo (objetivo):

  • p99 da persona sobe suavemente com VU count
  • CPU da persona sobe mas permanece abaixo de 70%
  • CPU do host < 50%, conntrack < 30% cheio
  • Nenhuma HPA em max
  • Zero disparos de TestBedInfrastructureBottleneck

Os mesmos sinais quando o test bed é o gargalo (modo de falha):

  • p99 da persona sobe abruptamente em VU count baixo
  • Um único host (ou frota) bate no teto antes da CPU do Caddy persona
  • TestBedInfrastructureBottleneck dispara em até 3 min do início
  • HPAMaxedOut dispara
  • Frequentemente coincide com HostUDPBufferOverflow ou HostConntrackNearFull

Os alertas foram projetados pra tornar o segundo caso impossível de não notar.

Cobertura estendida em PR-V

PR-U (#167) entregou a base host + pod. PR-V fecha os gaps que sobraram:

Novo ServiceMonitor / Probe / Regra O que você passa a ver / alertar
Probe snmp-nexus9000 + snmp-ngfw-dut (k8s/dut/61-snmp-probes.yaml) Métricas do NGFW (SUT) e do trunk Nexus 9000 efetivamente coletadas — sem isso o projeto era cego pros próprios dispositivos que existe pra medir.
ServiceMonitor kubelet + cAdvisor (k8s/dut/93-kubelet-cadvisor.yaml) container_cpu_*, container_memory_*, container_network_*, container_fs_* — uso real de recurso por container. Os painéis "Top 20 by CPU/RSS" do dashboard precisam disso.
ServiceMonitor reloader (k8s/87-stakater-reloader.yaml) reloader_reload_executed_total — falhas silenciosas de rotação de cert.
PrometheusRule extended-health (k8s/dut/94-extended-prometheus-rules.yaml) 16 alertas novos em 7 grupos (NIC, disco, pressão de sistema, cobertura, NFS, SNMP, reloader).

Os 16 alertas novos (extended set)

Grupo Alertas
NIC NICLinkDown, NICCarrierFlapping, NICRingBufferOverflow
Disco DiskIOLatencyHigh, DiskNearFull
Sistema LoadAverageHigh, FileDescriptorExhaustion, NTPClockSkew
Cobertura NodeTuningDaemonSetIncomplete, NodeExporterCoverageIncomplete, CNIDHCPDaemonIncomplete
NFS NFSClientOperationFailures, NFSClientHighLatency
SNMP SNMPProbeFailure, SNMPProbeSlow
Reloader ReloaderRolloutFailure

Total de alertas + painéis após PR-V

Antes PR-U Após PR-U Após PR-V
Alertas host + pod 0 15 31
Alertas compostos test-validity 0 3 3
Linhas no dashboard Grafana 5 (só persona) 6 10
ServiceMonitors 1 3 6
Probes (SNMP) 0 0 2

Painéis novos (Test-Bed Infrastructure Health)

  • NGFW + Nexus SNMP probes up — stat único que fica vermelho quando SUT ou trunk fica invisível
  • SNMP probe duration — timeseries por dispositivo; alerta em 25s (timeout = 30s)
  • NIC link state — 1/0 por NIC real, cai pra 0 instantaneamente em falha de cabo / SFP
  • Disk I/O busy % — por device, > 50% sustentado = gargalo no servidor NFS
  • File descriptors used % — sinaliza exaustão de FDs antes de quebrar pods
  • Top 20 containers by CPU / RSS — cAdvisor; identifica o container mais pesado vs seu limit
  • NFS RPC error rate / latency — visão slot-side da entrega de cloned-sites

Veja também

A regra de infra-health complementa essas — nenhuma duplica, todas são necessárias.