La telemetría verde puede ocultar la pérdida silenciosa de datos cuando las cargas de trabajo cambian de herramientas

Un ingeniero de software descubrió que su sistema automatizado de telemetría reportó una salud normal durante semanas mientras fallaba silenciosamente al capturar la mayoría de la actividad de sus agentes de IA. El incidente ocurrió en octubre de 2026 después de que el usuario cambiara su flujo de trabajo de Claude Code a Codex, un cambio que movió la generación de datos fuera del alcance de su pipeline de monitoreo existente.

Qué sucedió

El ingeniero mantiene un informe semanal de comparación estratificada que analiza sesiones de agentes, rastreando métricas como tasas de error de herramientas y tokens de salida. Este informe es generado por un cron job cada lunes a las 09:30, que procesa transcripciones archivadas desde un directorio específico utilizado por Claude Code. Durante varias semanas, el informe continuó publicándose con un estado de "normal", mostrando cero problemas de calidad de datos y distribuciones estadísticas consistentes.

Sin embargo, los datos subyacentes habían cambiado drásticamente. El 6 de septiembre de 2026, el usuario configuró su sistema para enrutar ejecuciones programadas desatendidas y consultas sin interfaz gráfica (headless) hacia Codex por defecto, restringiendo Claude Code a solo dos sesiones por día. Más tarde, el 5 de octubre, devolvieron Claude Code al rol principal de orquestador, pero las ejecuciones desatendidas permanecieron en Codex. El pipeline de ingesta nunca se actualizó para leer desde el directorio de sesiones de Codex, lo que significaba que solo capturaba una fracción mínima del trabajo real realizado.

A pesar de este enorme punto ciego, las verificaciones de salud pasaron cada semana. El sistema verificaba que el comando de copia saliera con código 0, que el recuento de archivos de archivo no disminuyera y que se cumplieran las reglas internas de consistencia de datos. Como el cron job en sí se ejecutó con éxito y procesó los pocos archivos restantes de Claude Code sin errores, el sistema de monitoreo no tenía motivo para señalar un incidente. El informe describía con precisión la pequeña porción de datos que recibía, creando una falsa sensación de seguridad.

Detalles clave

• El informe de telemetría mostró medianas e intervalos intercuartílicos idénticos durante semanas, diferenciantese solo en 12 líneas relacionadas con metadatos y conteos menores.
• Entre el 13 y el 20 de septiembre, el sistema registró cero archivos de transcripción de Claude Code pero 192 archivos de despliegue de Codex.
• Del 27 de septiembre al 4 de octubre, la ingesta capturó solo 3 archivos de Claude Code mientras que se generaron 1.058 archivos de Codex.
• La sesión más reciente en la base de datos terminó el 11 de septiembre, sin embargo, el informe del 21 de septiembre aún marcaba el sistema como normal.
• Las verificaciones de salud validaban la ejecución de procesos y la consistencia de datos, pero no verificaban si el volumen de datos ingeridos coincidía con la actividad real.
• Una comprobación separada de obsolescencia pasó porque el archivo de la base de datos era reescrito semanalmente por el proceso de compilación, independientemente de si se agregaban nuevos datos.

Antecedentes

Los sistemas de telemetría a menudo dependen del monitoreo de "latido" o códigos de salida para determinar la salud. Si un script se ejecuta hasta completarse sin bloquearse, se considera saludable. Este enfoque funciona bien para detectar fallos catastróficos, pero falla al detectar "fallos silenciosos" donde el script se ejecuta pero no procesa datos significativos. En este caso, el monitoreo estaba acoplado estrechamente a una ruta de herramienta específica. Cuando la carga de trabajo cambió a una herramienta diferente con una estructura de archivos distinta, el monitor continuó observando la ruta vacía antigua.

Esto ilustra una trampa común en la observabilidad autoalojada: monitorear el mecanismo en lugar del resultado. El sistema confirmaba que el pipeline de datos estaba operativo, pero no confirmaba que el pipeline estuviera recibiendo la entrada esperada. Sin un denominador externo—un recuento del trabajo total realizado en todas las herramientas—el sistema no podía reconocer que su visión del mundo se había reducido.

Por qué importa

Para equipos que ejecutan su propio software, este escenario destaca el riesgo del monitoreo estático en entornos dinámicos. A medida que la infraestructura y los flujos de trabajo evolucionan, las rutas codificadas y las suposiciones se convierten en pasivos. Si tu script de respaldo se ejecuta con éxito pero respalda un directorio vacío porque la fuente de datos se movió, tu monitoreo probablemente permanecerá en verde hasta que intentes una restauración. La ausencia de errores no es evidencia de éxito.

Este incidente también demuestra el peligro de depender excesivamente de las verificaciones de consistencia interna. Métricas como "cero resultados huérfanos de herramientas" son valiosas para la integridad de los datos, pero inútiles para la cobertura. Un sistema puede ser perfectamente consistente mientras es completamente irrelevante. Los ingenieros deben asegurarse de que sus verificaciones de salud incluyan restricciones de validez sobre el volumen de datos y la frescura relativa a la realidad externa, no solo estados de proceso internos.

Además, el silencio del fallo lo hizo más difícil de detectar que un bloqueo. Un script roto genera alertas; un script funcional que procesa datos obsoletos genera confianza. Los equipos necesitan diseñar monitores que fallen ruidosamente cuando dejan de llegar datos, en lugar de aceptar silenciosamente lo que esté disponible. Esto requiere desacoplar la definición de "saludable" de "ejecutado sin error".

Qué puedes hacer

• Implementa monitoreo de latido para trabajos críticos que requiera una señal explícita dentro del proceso, no solo un código de salida exitoso.
• Agrega comprobaciones de denominador externo que comparen el volumen de datos ingeridos contra fuentes de verdad conocidas, como recuentos de archivos en todos los directorios relevantes.
• Configura alertas de obsolescencia basadas en la marca de tiempo del registro de datos más nuevo, no en la hora de última modificación del archivo de la base de datos.
• Revisa las políticas de enrutamiento y los cambios de herramientas para asegurar que los alcances de monitoreo se actualicen siempre que las fuentes de datos se desplacen o expandan.
• Prueba la lógica de monitoreo simulando inanición de datos para verificar que los escenarios de bajo volumen activen advertencias apropiadas.
• Desacopla las alertas del uso principal de la herramienta enviando notificaciones a canales independientes del flujo de trabajo monitoreado, asegurando visibilidad incluso cuando el flujo de trabajo monitoreado falla.