El equipo responsable de ServiceQueryEdge aplicó una combinación de Jobs Monitoring y un agente de IA construido sobre Claude para localizar y corregir cuellos de botella en su pipeline Spark. Las optimizaciones resultaron en una disminución del 44% en los costos diarios de infraestructura y una reducción del 60% en la duración de ejecución en el datacenter identificado como US1, al tiempo que redujeron el esfuerzo manual necesario para correlacionar síntomas con causas raíz.
ServiceQueryEdge alimenta un grafo de relaciones entre entidades de observabilidad y se ejecuta diariamente en siete datacenters. En las particiones más voluminosas, el job procesaba hasta 27 TB de datos de entrada y alrededor de 16.000 millones de registros. Antes de la intervención, el flujo promediaba 1.500 USD diarios en costos de infraestructura y cada corrida superaba las 17 horas, cifras que condicionaban tanto la latencia operativa como el coste operativo del servicio.
Para ganar visibilidad sobre el comportamiento del pipeline, el equipo instrumentó Jobs Monitoring y explotó el Spark SQL Plan, una representación visual e interactiva del plan de ejecución. Además desarrollaron una estructura de prompts que consolida métricas por etapa, el plan SQL, telemetría y fragmentos del código fuente para alimentar al agente. Con esa entrada, el agente podía generar hipótesis y señalar nodos del plan potencialmente responsables de degradaciones.
El agente realizaba llamadas MCP a través del Datadog MCP Server y empleaba herramientas concretas para recuperar trazas y spans, como get_datadog_trace, apm_search_spans y apm_explore_trace. Esa integración permitió cruzar señales de ejecución en tiempo de ejecución con la estructura lógica del job y con la implementación del código, lo que facilitó conectar un operador lento en el plan a la sección de código que estaba provocando la ineficiencia.
Los autores enfatizan que, aunque los agentes de IA son hábiles para razonar sobre código y formular hipótesis, necesitan señales reales de rendimiento para evitar conjeturas erróneas. La combinación explícita del Spark SQL Plan, la telemetría granular y el código fuente cerró la brecha entre observación y causa, ofreciendo un contexto que hacía comprensible por qué cierto nodo del plan impactaba el rendimiento general. En las etapas iniciales de despliegue surgieron problemas de escala: al extraer grandes volúmenes de telemetría el agente agotó su ventana de contexto durante las llamadas MCP, y múltiple ejecuciones agravaban la pérdida de contexto. Como consecuencia, algunas sugerencias del agente resultaron incompletas o incoherentes, y parte del trabajo de correlación siguió recayendo en ingenieros humanos que debían validar y completar el análisis.
Para preservar el contexto y elevar la calidad de las recomendaciones se introdujeron subagentes encargados de tareas específicas de adquisición y preprocesado de información. El equipo priorizó un alcance de datos preciso por encima del volumen bruto y también experimentó con embeddings más profundos de métricas y runtime. Esos embeddings aumentaron la señal disponible para el razonamiento, aunque a costa de elevar la tasa de falsos positivos en ciertas hipótesis.
Como respuesta a recomendaciones fuera de objetivo, se añadió un subagente validador que actúa como calificador en lugar de generador. Este validador recibe el mismo contexto — salud del job y plan SQL— y busca razones por las que una propuesta no funcionará antes de que llegue al ingeniero o al pipeline de cambios. El blog documenta un ejemplo en el que el validador detectó que aplicar un filtro de spam antes de una join principal no reduciría filas de forma significativa y, además, que ese mismo filtro ya estaba aplicado en el código previo a la join.
Operationalmente, la combinación de Jobs Monitoring, el agente principal y el validador permitió a los ingenieros saltar directamente al nodo relevante del plan con contexto acerca de por qué era importante, eliminando horas de diagnóstico manual. En el datacenter US1, las acciones concretas derivadas de ese análisis condujeron a la reducción del 44% en costos de computación y a una disminución del 60% en la duración de la corrida, resultados que reflejan el impacto sobre la eficiencia y el coste operativo.
La experiencia dejó lecciones claras sobre limitaciones y control: no todas las recomendaciones del agente fueron válidas en su forma inicial — por ejemplo, sugerencias de podar lecturas de columnas resultaron redundantes porque Spark ya aplicaba esa optimización—, y la calidad de las salidas dependió más de un scope preciso que de la cantidad de datos alimentados al agente. En ese sentido, la validación automática y la supervisión humana se revelaron requisitos indispensables.
Fuentes
Respuestas (0)
Aún no hay respuestas en este tema.
