Skip to content

Monitoreando la validez de la prueba

Estado del alcance (post-congelación de alcance 2026-05-10) — Ver ARCHITECTURE.md para los 37 MÓDULOs canónicos + 7 Test Kinds + arquitectura de safety DOM/CPOS/PIE-PA. ADRs 0014, 0019-0025 cubren adiciones post-Freeze.

Objetivo de este documento: en segundos, no horas, un operador debe poder responder "la medición del NGFW que acabo de recolectar es realmente significativa, o la infraestructura de prueba fue el cuello de botella?"

El cluster existe para cargar un Next-Generation Firewall y medir cuánto de la degradación de tasa/latencia es el costo de descifrado TLS del NGFW. Eso solo es verdad si la infraestructura generadora de carga (hosts UCS, kernel Linux, webservers Caddy, flotas browser-engine + synthetic-load, trunk Nexus 9000, NFS in-cluster) mantiene holgura durante la prueba. Si el host o la flota se satura primero, todo número de NGFW que el dashboard imprime está mal.

Esta página describe las métricas, alertas y dashboard Grafana que existen para hacer esa condición obvia.

Las cuatro señales

Señal Umbral "prueba invalidada" Dónde aparece
TestBedInfrastructureBottleneck persona p99 > 1s y CPU de algún host > 85%, o alguna HPA en maxReplicas Panel stat "Test bed status" del Grafana se vuelve rojo. Alerta Prometheus dispara severity=critical.
HostUDPBufferOverflow UDP RcvbufErrors > 0 por 2 min en cualquier host Toda medición de HTTP/3 que involucre ese host es inválida (kernel descartó paquetes QUIC).
HostConntrackNearFull Tabla conntrack > 80% llena Todas las mediciones que involucren ese host son inválidas (kernel pronto descartará paquetes).
HostNetworkPacketDrops > 100 paquetes/s descartados en NIC real Números de RTT y throughput de ese host están mal.

Cualquiera de esas alertas disparando invalida la corrida en curso. Detén la prueba, corrige la causa, re-ejecuta.

Qué mirar primero

Abre el dashboard Grafana Test-Bed Infrastructure Health (UID ai-forse-infra-health). Fila superior, cuatro stat panels grandes:

Panel Verde significa Rojo significa
Test bed status latencia persona estable Y CPU host < 85% Y ninguna HPA fija Corrida sospechosa. Investigar los próximos 3 paneles.
Hosts with tuning missing Todos ejecutaron host-tuning.sh apply Al menos un host está con sysctls default (conntrack 262K, puertos 28K) — ese host saturará primero.
HPAs at maxReplicas Ninguna fija Flota a plena capacidad; el test bed es el límite, no el NGFW.
OOMKills (15m) Cero Al menos un contenedor golpeó su límite de memoria. Si fue un Caddy persona, corrida inválida.

Todo verde y panel de alertas vacío = mediciones NGFW son honestas, sigue.

Algo en rojo — las filas debajo de los stat panels muestran dónde mirar: - Per-host CPU saturation — gráfico por nodo, umbral rojo en 90% - Memory + conntrack pressure — mismo breakdown por nodo - Network drops / UDP overflow / TCP retransmits — tres gráficos lado a lado; no-cero en cualquiera es malo - Pod CPU throttle + restarts — confirma cuál contenedor es la restricción real - Sysctl effective values — tabla, identifica cuál host no recibió tuning

Qué se monitorea, y cómo

Tres nuevos componentes vienen con esta stack:

  1. node_exporter (k8s/dut/90-node-exporter.yaml) — un DaemonSet que corre en todo nodo UCS y exporta métricas kernel en :9100 por la OOBI. Sin él, cero visibilidad de host.
  2. kube-state-metrics (k8s/dut/91-kube-state-metrics.yaml) — Deployment que expone estado de objetos K8s (restart counts, motivos de OOMKill, réplicas HPA, etc.) como métricas Prometheus. Sin esto, la mitad de las alertas existentes no dispara.
  3. PrometheusRule web-agent-cluster-infra-health (k8s/dut/92-infra-prometheus-rules.yaml) — 14 alertas en 3 grupos (host, pod, "test validity") + 7 recording rules pre-agregando los joins pesados para que la evaluación sea rápida con intervalo de 30s.

La ConfigMap del dashboard está en platform/observability/dashboards/infra-health-cm.yaml — Grafana lo toma vía label grafana_dashboard: "1" siempre que el sidecar estándar de dashboard esté corriendo.

Confirmando que el tuning está activo

Dos verificaciones complementarias:

# Por host, desde el workstation del operador (ejemplo k3s)
sudo scripts/host-tuning.sh status

# A nivel cluster, vía Prometheus
sum(node_nf_conntrack_entries_limit) by (instance) > 1000000

Ambos deben mostrar cada host en el valor tuneado (2 097 152 para conntrack). Si un host está en el default kernel (~262K), la alerta TestBedSysctlMissing dispara automáticamente — no hay que recordar mirar.

Interpretando alertas durante una corrida

Una prueba típica de capacidad NGFW produce las siguientes señales cuando el NGFW es el cuello de botella (objetivo):

  • p99 de la persona sube suavemente con VU count
  • CPU de la persona sube pero permanece bajo 70%
  • CPU del host < 50%, conntrack < 30% lleno
  • Ninguna HPA en max
  • Cero disparos de TestBedInfrastructureBottleneck

Las mismas señales cuando el test bed es el cuello de botella (modo de falla):

  • p99 de la persona sube abruptamente en VU count bajo
  • Un único host (o flota) golpea el techo antes que la CPU del Caddy persona
  • TestBedInfrastructureBottleneck dispara en hasta 3 min del inicio
  • HPAMaxedOut dispara
  • Frecuentemente coincide con HostUDPBufferOverflow o HostConntrackNearFull

Las alertas fueron diseñadas para hacer el segundo caso imposible de no notar.

Cobertura extendida en PR-V

PR-U (#167) entregó la base host + pod. PR-V cierra los gaps que quedaron:

Nuevo ServiceMonitor / Probe / Regla Lo que pasas a ver / alertar
Probe snmp-nexus9000 + snmp-ngfw-dut (k8s/dut/61-snmp-probes.yaml) Métricas del NGFW (SUT) y del trunk Nexus 9000 efectivamente recolectadas — sin esto el proyecto estaba ciego frente a los propios dispositivos que existe para medir.
ServiceMonitor kubelet + cAdvisor (k8s/dut/93-kubelet-cadvisor.yaml) container_cpu_*, container_memory_*, container_network_*, container_fs_* — uso real de recursos por contenedor. Los paneles "Top 20 by CPU/RSS" del dashboard lo requieren.
ServiceMonitor reloader (k8s/87-stakater-reloader.yaml) reloader_reload_executed_total — fallos silenciosos de rotación de cert.
PrometheusRule extended-health (k8s/dut/94-extended-prometheus-rules.yaml) 16 alertas nuevas en 7 grupos (NIC, disco, presión de sistema, cobertura, NFS, SNMP, reloader).

Las 16 alertas nuevas (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 + paneles tras PR-V

Antes de PR-U Tras PR-U Tras PR-V
Alertas host + pod 0 15 31
Alertas compuestas test-validity 0 3 3
Filas del dashboard Grafana 5 (sólo persona) 6 10
ServiceMonitors 1 3 6
Probes (SNMP) 0 0 2

Paneles nuevos (Test-Bed Infrastructure Health)

  • NGFW + Nexus SNMP probes up — stat único que se pone rojo cuando el SUT o el trunk se vuelve invisible
  • SNMP probe duration — timeseries por dispositivo; alerta a 25s (timeout = 30s)
  • NIC link state — 1/0 por NIC real, cae a 0 al instante en fallo de cable / SFP
  • Disk I/O busy % — por device, > 50% sostenido = cuello de botella en el servidor NFS
  • File descriptors used % — señala agotamiento de FDs antes de tumbar pods
  • Top 20 containers by CPU / RSS — cAdvisor; identifica el contenedor más pesado vs su limit
  • NFS RPC error rate / latency — vista slot-side de la entrega de cloned-sites

Véase también

La regla de infra-health complementa esas — ninguna duplica, todas son necesarias.