Grafana & Friends Taipei #2: de un war room de 800 personas en TSMC a un homelab de 6€/mes

Meetup en 5倍學院, Taipei. Tres charlas con un hilo común: recolectar métricas es lo fácil; lo difícil es saber que perdiste la señal en el momento en que la pierdes.

TSMC: el incidente que ninguna alerta vio

Chuck (TSMC) contó el caso “FAB99 X System Service Down”: dos caídas el mismo día (08:30 y 15:30), más de 10 minutos cada una, y un war room que llegó a tener ~800 personas — la mayor cifra registrada en el servicio.

Lo interesante es el desenlace. Network, K8s e Infra revisaron sus dashboards y no encontraron nada (“不是我的問題” — no es mi problema). El root cause final: una métrica del equipo de aplicación que no tenía alert rule configurada. El problema era invisible para todos porque nunca apareció en el radar de alertas.

Las lecciones que ellos mismos sacaron: el alerting funcionó para lo que estaba configurado y la respuesta cross-team fue rápida, pero había demasiado ruido y ninguna correlación entre sistemas — cada equipo mirando sus propios dashboards sin cruzar información.

Su roadmap para arreglarlo va de un SDK de observabilidad propio con Semantic Conventions de OTel hasta unificar metrics, logs y traces en ClickHouse como storage único, con un AI agent en Grafana para búsqueda en lenguaje natural, detección de anomalías (que habría detectado la métrica sin alerta) y root cause analysis cruzando señales por trace_id.

Un detalle técnico que me interesa por el stack Java: en Java el OTel Agent instrumenta automáticamente vía bytecode injection (JDBC, Redis, HTTP clients, “gratis”); en Go no existe eso — hay que instrumentar cada cliente explícitamente.

Edward Oo: CPU al 66%… pero steal al 62%

La segunda charla fue un caso de debugging en homelab que aplica a cualquier VM en cloud. Una alerta de CPU dispara: 66% de uso. Pero al desglosar: steal 62%, user 12%. La VM no recibía ciclos reales de CPU porque el hypervisor se los daba a otra VM (noisy neighbor) — kubectl top mostraba solo 10% de uso, con la salud real escondida en node_cpu_seconds_total{mode='steal'}.

La cascada era elegante en su perversidad: PostgreSQL vivía en el nodo con steal, el servidor de SSO (authentik) en otro nodo, y cada llamada a la DB cruzaba la red overlay con mTLS para morir en timeouts. Resultado: 33 restarts en 12 horas con Exit Code: 0 — no eran crashes, era el liveness probe matando el pod porque la DB no respondía a tiempo. El fix: un nodeSelector para co-localizar DB y servidor. Cero restarts.

Sus 5 lecciones, que valen para cualquier entorno virtualizado:

1. CPU Usage ≠ CPU Steal — kubectl top no muestra steal
2. ExitCode 0 = probe kill, no crash de la app
3. Co-localizar workloads stateful — el chart de Helm no trae nodeSelector por defecto
4. Cloudflare Proxy no es universal — tráfico machine-to-machine no necesita CDN (le costó 4 semanas de 403 silencioso en remote_write)
5. Perder datos no significa que desaparecieron — vmctl backfill recuperó 336M de samples en 15 minutos desde el TSDB local de Prometheus

Su stack es un argumento sólido para VictoriaMetrics frente a Thanos/Mimir en escala pequeña: un solo binario, menos de 500MB de RAM, 100% compatible con PromQL, backfill nativo. Y todo el plano de observabilidad en una VPS separada de ~6€/mes — si el cluster tiene un problema serio, los dashboards siguen vivos.

Blueswen: SRE donde las ratas muerden los cables

Blueswen (Grafana Champion) cerró con dos años de SRE en edge devices para fast foods en EE.UU. — un edge server por restaurante convirtiendo el Drive Thru en métricas con camera AI. El edge “vive en el sitio, no en el datacenter”: red prestada del cliente, cortes de luz, calor, y sí, ratas mordiendo cables.

Tres patrones que me llevo:

• Backfill tras corte de red: el agent buffea en disco y reenvía al volver la red — pero llega con timestamps viejos (out-of-order). Si el storage no tiene out_of_order_time_window configurado, esas métricas se descartan en silencio.
• Detección de offline con doble vía: remote write como señal principal + un heartbeat a S3 consultado con Athena como respaldo, cruzados con SQL Expression de Grafana 11 en una misma alert rule. Solo se declara offline si ambas vías callan — adiós falsos positivos por firewall del cliente.
• Textfile Collector de Node Exporter para métricas sin exporter: un cron + script que escribe un archivo en formato Prometheus, recolectado “de colado” sin tocar el data flow.

La frase de cierre del meetup lo resume todo: en el sitio, lo difícil nunca fue recolectar las métricas, sino saber que perdiste la señal en el momento en que la pierdes.