TORAI: Unsupervised Fine-grained RCA using Multi-Source Telemetry Data

1. El Problema: Puntos Ciegos en la RCA de Microservicios

Las metodologías actuales de Análisis de Causa Raíz (RCA, por sus siglas en inglés) para sistemas de microservicios enfrentan tres limitaciones críticas que reducen su eficacia en entornos reales:

• Suposición de Cobertura Total de Trazas (Blind Spots): La mayoría de los métodos existentes asumen que todos los servicios están instrumentados con trazas distribuidas para construir un "grafo de llamadas al servicio" completo. Sin embargo, en sistemas que evolucionan rápidamente o que incluyen componentes de caja negra (software compilado, servicios de terceros), existen "puntos ciegos" (servicios sin trazas). Cuando estos existen, los métodos basados en grafos fallan porque no pueden analizar servicios críticos que no aparecen en el grafo.
• Dependencia de Datos Etiquetados (Supervisados): Muchos enfoques requieren grandes volúmenes de datos de entrenamiento etiquetados manualmente. Esto es poco práctico en sistemas de microservicios dinámicos donde las actualizaciones son frecuentes y los fallos históricos no cubren necesariamente los nuevos escenarios de error.
• Instrumentación Intrusiva: Algunos métodos requieren una integración estricta entre métricas, registros (logs) y trazas (por ejemplo, inyectar trace_id en cada línea de log), lo que exige modificaciones costosas en el código fuente y es inviable para componentes cerrados.

2. Metodología: TORAI

TORAI es un enfoque no supervisado diseñado para identificar causas raíz granulares (tanto servicios como indicadores específicos) sin depender de un grafo de llamadas completo ni de datos etiquetados. Utiliza datos de telemetría multi-fuente (métricas, logs y trazas disponibles) a través de un proceso de cinco etapas:

1. Transformación de Datos: Convierte las métricas, logs y trazas disponibles en series temporales.
   • Métricas: Se extraen las "cuatro señales doradas" (tráfico, saturación, latencia, errores).
   • Logs: Se analizan las ocurrencias de plantillas de logs (usando algoritmos como Drain) en lugar de su semántica, para evitar errores de parsing.
   • Trazas: Se extraen latencia y códigos de estado, pero no se construye un grafo de llamadas.
2. SeverityScorer (Puntuación de Severidad): Calcula un vector de severidad para cada servicio basándose en la desviación de sus series temporales respecto al comportamiento normal (usando desviación estándar). Si una fuente de datos falta (ej. no hay trazas), se imputa un valor de cero, permitiendo que el sistema funcione con datos parciales.
3. SymptomCluster (Agrupación de Síntomas): Utiliza un Modelo de Mezcla Gaussiana (GMM) para agrupar servicios con síntomas de severidad similares. Esto separa los servicios anómalos de los normales, reduciendo la carga computacional para el siguiente paso. El GMM permite agrupamiento "suave", donde un servicio puede pertenecer a múltiples grupos si su comportamiento es ambiguo.
4. CausalRanker (Ranking Causal): Dentro de cada grupo de severidad, aplica inferencia causal (utilizando el algoritmo Ψ-PC) para construir grafos causales dirigidos acíclicos (DAG) y ordenar los servicios candidatos. Identifica la causa raíz como el nodo sin padres en el grafo causal dentro del grupo.
5. RankAggregation y FineGrainer:
   • RankAggregation: Combina el ranking de los grupos de severidad con el ranking causal interno para producir una lista ordenada de servicios causales (causa raíz de nivel grueso).
   • FineGrainer: Realiza pruebas de hipótesis (usando mediana y rango intercuartílico para robustez ante outliers) en los indicadores individuales (métricas específicas, plantillas de logs) de los servicios candidatos para identificar el indicador exacto de la falla (ej. "CPU del servicio X" o "Log de error Y").

3. Contribuciones Clave

• Identificación de Limitaciones: Se formalizan las tres barreras principales de los métodos actuales (cobertura de trazas, datos etiquetados e instrumentación intrusiva).
• Propuesta de TORAI: Un nuevo método que elimina la necesidad de un grafo de llamadas completo. TORAI puede diagnosticar fallos en servicios que son "puntos ciegos" (sin trazas) utilizando únicamente métricas y logs.
• Enfoque No Supervisado: No requiere datos de entrenamiento etiquetados, haciéndolo adaptable a sistemas en evolución rápida.
• Robustez ante Instrumentación Incompleta: Demuestra que es posible realizar RCA efectiva sin modificar el código fuente para integrar trazas en logs o tener trazas en todos los servicios.

4. Resultados Experimentales

Los autores evaluaron TORAI en tres sistemas de referencia (Online Boutique, Sock Shop, Train Ticket) y en 10 fallos reales de un proveedor de internet.

• Eficacia en Causa Raíz Gruesa (Coarse-grained):
  • TORAI superó a 9 métodos de última línea (baselines) en todos los conjuntos de datos.
  • En Online Boutique, alcanzó un promedio de 0.93 en Avg@5 (precisión en los 5 primeros), frente a 0.79 del mejor baseline.
  • En Sock Shop (100% de puntos ciegos, sin trazas), TORAI logró un 0.94 de Avg@5, mientras que los métodos basados en trazas fallaron completamente.
  • En Train Ticket (sistema grande con 64 servicios), TORAI obtuvo un 0.89 de Avg@5, superando significativamente a los baselines (el mejor fue 0.64).
• Eficacia en Causa Raíz Fina (Fine-grained):
  • TORAI identificó con mayor precisión los indicadores específicos (métricas o logs) de la falla, logrando un promedio de 0.68 en Avg@5 en Online Boutique, superando al segundo mejor (BARO) que obtuvo 0.39.
• Eficiencia:
  • TORAI es rápido, analizando fallos en segundos (ej. ~20 segundos para Train Ticket con 64 servicios). En comparación, métodos basados en redes neuronales profundas (como CausalRCA) tardaron horas o excedieron los límites de tiempo en sistemas grandes.
• Robustez ante Puntos Ciegos:
  • Un análisis de sensibilidad mostró que TORAI mantiene una alta precisión incluso cuando se eliminan trazas de hasta el 100% de los servicios. En el caso de 100% de puntos ciegos, TORAI sigue funcionando con alta precisión basándose solo en métricas y logs.
• Escenarios Reales:
  • En pruebas con fallos reales de producción, TORAI logró un 100% de precisión (AC@3), ubicando la causa raíz correcta dentro de las tres primeras recomendaciones en todos los casos.

5. Significado e Impacto

El trabajo de TORAI es significativo porque aborda una brecha crítica entre la teoría de la RCA y la realidad de la ingeniería de software moderna:

1. Viabilidad Práctica: Permite realizar diagnósticos precisos en sistemas donde la instrumentación completa es imposible o demasiado costosa (común en empresas con legados o servicios de terceros).
2. Reducción de Fricción Operativa: Al no requerir datos etiquetados ni cambios en el código fuente, se puede implementar de inmediato en sistemas de producción sin interrumpir el desarrollo.
3. Precisión Granular: No solo señala qué servicio falló, sino qué indicador específico (ej. un log de pila de errores o un pico de CPU) causó el problema, acelerando la resolución de incidentes.
4. Escalabilidad: Su diseño eficiente permite aplicarlo a sistemas masivos con cientos de microservicios sin degradar el rendimiento, a diferencia de los métodos basados en grafos completos que se vuelven computacionalmente prohibitivos.

En resumen, TORAI representa un avance hacia una observabilidad más resiliente, capaz de operar en entornos imperfectos y dinámicos, garantizando la fiabilidad de los sistemas de microservicios incluso ante la ausencia de datos de trazas completos.