Cinco minutos en vez de todo un día: así encuentra errores en Linux la nueva herramienta con IA

Entender un fallo complejo en Linux en cuestión de minutos en lugar de horas suena a fantasía. Pero el desarrollador Josef Bacik asegura que fue eso lo que provocó la salida de Systing 1.0 – una herramienta para trazado del sistema basada en eBPF, que ahora es capaz de analizar datos mediante inteligencia artificial.

Systing se creó originalmente como una herramienta para recopilar trazas detalladas del sistema y visualizarlas luego en Perfetto. El programa registra todos los eventos clave en una única línea temporal, lo que ayuda a ver las relaciones entre procesos. Este enfoque resultó especialmente útil para los desarrolladores de sched_ext, que necesitaban seguir de forma clara el funcionamiento del planificador de tareas.

Sin embargo, con el tiempo surgieron problemas. Las trazas se volvían demasiado voluminosas y llenas de detalles, lo que convertía el análisis en una tarea complicada. Parte de los datos, por ejemplo la interacción de la aplicación con la red, resultaba difícil de representar de forma clara: la mitad de las operaciones ocurre en el contexto de la aplicación, la otra mitad —en el contexto del núcleo de Linux. Analizar estas situaciones requería trabajo manual.

En la versión 1.0 Bacik cambió el enfoque. En lugar de guardar los datos solo en el formato de trazas de Perfetto, Systing ahora puede escribir los resultados en la base de datos DuckDB. Ese formato permite ejecutar consultas en SQL directamente, sin largas conversiones. Según el autor, DuckDB es notablemente más rápido al trabajar con grandes volúmenes de datos.

La novedad principal es la integración con Claude Code a través de un módulo especial. En vez de escribir y mantener guiones de análisis propios, Bacik delegó el examen de las trazas en la inteligencia artificial. Claude accede a la base DuckDB y responde preguntas sobre el comportamiento del sistema en tiempo real.

En uno de los ejemplos se trató de una aplicación de red que no alcanzaba la velocidad de transferencia esperada. Tras ejecutar Systing y pasar la traza a Claude Code, el sistema detectó bloqueos internos en una librería en Rust. Después de corregirlos, el tiempo de transferencia se redujo de 12 a 8 segundos. Luego se descubrió que la descompresión de los datos ocurría en el mismo hilo que las operaciones de red. Al separar las tareas, el tiempo bajó a 4 segundos. La causa final fueron buffers de transmisión demasiado pequeños, que generaban sobrecarga adicional. Tras ajustarlos, el indicador descendió hasta 2 segundos. Todo el trabajo llevó alrededor de una hora.

Pero la historia no terminó ahí. En producción el tiempo de transferencia aumentó súbitamente a 24 segundos. Una nueva traza mostró que la máquina en producción dedicaba un tiempo considerable a kretprobe en una función de red "caliente". Systing guarda información sobre la versión del núcleo, y Claude notó de inmediato la diferencia: en el entorno de pruebas se usaba el kernel de Linux 6.12, mientras que en producción estaba el 6.6. Una de las herramientas de seguridad se conectaba a la función de red mediante una interceptación eBPF, y en la versión 6.6 esas interceptaciones funcionan notablemente más despacio. Las optimizaciones aumentaron el número de operaciones de red por segundo, por lo que los costes de kretprobe pasaron a ser críticos y ralentizaron el sistema.

Según Bacik, antes la búsqueda de una causa así habría tomado horas. El principal tiempo consumido fue la grabación de la traza en el entorno de producción, mientras que el análisis con Claude llevó menos de cinco minutos. Tras migrar las cargas de trabajo a una versión de núcleo más reciente, la velocidad de transferencia volvió a 2 segundos. El desarrollador califica la nueva versión de Systing como un punto de inflexión. La herramienta dejó de ser solo un medio de visualización y se convirtió progresivamente en un asistente que no solo recopila datos, sino que ayuda a encontrar rápidamente la raíz del problema.