Este artículo es una compilación del discurso compartido por Xiang Yang, líder de producto DeepFlow de Yunshan Network, en la Conferencia Global de Desarrollo de Software QCon (Beijing) 2024 , con el tema "eBPF + LLM: Infraestructura para la realización de agentes observables". Revise el enlace y descargue el PPT .
¡Cuenta atrás para la inscripción del segundo día! Ven y únete a la reunión de desarrolladores de código abierto de Observability Nanjing Station |
Hoy me complace compartir con ustedes parte del trabajo que DeepFlow ha realizado en agentes de observabilidad. El tema de hoy incluye principalmente dos aspectos: cómo utilizar eBPF para resolver problemas de calidad de datos y cómo utilizar LLM para crear agentes eficientes sobre esta base. A partir de estos dos aspectos, podemos ver por qué eBPF y LLM son infraestructuras clave para realizar agentes de observabilidad .
La primera pregunta anterior es en realidad una cuestión de gobernanza de datos. Hay muchas formas de obtener datos de alta calidad, como utilizar especificaciones organizativas y mejorar la eficiencia de la ingeniería de I+D. Lo que estoy compartiendo hoy es principalmente lo último, específicamente cómo usar eBPF, una tecnología innovadora, para obtener datos de observabilidad completos sin intrusión. Una vez que tengamos datos de alta calidad, podemos usar LLM, combinado con ingeniería de palabras rápida, RAG, ajuste fino y otros métodos, para construir un agente observable eficiente. Las prácticas compartidas hoy provienen de nuestro producto de observabilidad DeepFlow, que también es un proyecto de código abierto cada vez más popular. Finalmente, también compartiré mis pensamientos sobre la evolución de los agentes observables.
01
Cree fuentes de señales de observabilidad de alta calidad utilizando eBPF
La esencia del primer tema es la gobernanza de datos, con el objetivo de obtener datos de observabilidad de alta calidad. Primero echemos un vistazo a las soluciones tradicionales. Por ejemplo, utilizamos APM para recopilar datos. ¿Cómo garantizar la integridad y relevancia de los datos en este momento? Especialmente en un entorno nativo de la nube, cuando el cliente accede al servidor, puede pasar por redes K8 complejas, varias puertas de enlace, varios middleware, bases de datos, DNS y otros servicios básicos. Estos enlaces intermedios no están cubiertos por APM. Incluso la ubicación observada de APM y la solicitud de red real del proceso serán diferentes. Cuando hacemos gobernanza y análisis de datos sobre esta base, generalmente encontramos que hay problemas con la integridad y coherencia de los datos. A menudo se necesita mucho tiempo y energía para promover y mejorar la cobertura de la instrumentación del lado empresarial, y también lo hacemos. Es necesario utilizar captura de paquetes y registros y otros métodos para concatenar datos heterogéneos de una gran cantidad de servicios básicos. Se cree que la siguiente imagen es un problema que encontramos a menudo cuando usamos APM: el retraso observado por el cliente es de 500 ms, pero el retraso observado por el servidor es de solo 10 ms. Lo que es aún peor es que es posible que el servidor no haya enviado la instrumentación. todavía.
Más cerca de casa, ¿por qué decimos que eBPF es la infraestructura para fuentes de señales de observabilidad de alta calidad ? La tecnología eBPF es una tecnología programable por el kernel. Cada pequeña abeja en la imagen a continuación es una posición de función que eBPF puede enganchar. Podemos usar eBPF para percibir todos los estados internos de cualquier proceso en el host de la nube a través de funciones comerciales Hook, llamadas al sistema, funciones del kernel, funciones de red y controladores de disco. Más importante aún, esta acción es completamente segura debido a la existencia de eBPF Verifier y, debido al mecanismo de compilación JIT, su rendimiento es comparable al código nativo del kernel.
La tecnología eBPF tiene dos ventajas únicas y puede resolver bien los problemas de calidad de los datos que enfrenta APM. La primera ventaja es la intrusión cero (Código Cero) . El funcionamiento de un programa eBPF no requiere modificación del código, recompilación o reinicio de ningún proceso de aplicación. Es una tecnología plug-and-play que se puede cargar en su producción en cualquier momento. tiempo. La segunda ventaja es el Full Stack . Ya sea un proceso de negocio, una puerta de enlace, una cola de mensajes, una base de datos o un sistema operativo, eBPF se puede utilizar para recopilar datos de observación. Por lo tanto, cuando se ejecuta un proceso, su interacción con toda la pila de software, desde la lógica empresarial hasta el tiempo de ejecución del lenguaje, desde las bibliotecas compartidas hasta el kernel y los controladores de hardware, se puede cubrir utilizando eBPF. En la siguiente figura, podemos ver que los datos sin procesar que eBPF puede recopilar son muy ricos, incluidos: eventos de proceso, eventos de archivo, eventos de rendimiento, eventos de socket, eventos de kernel y eventos de hardware. El tema de la sesión QCon de hoy es la observabilidad empresarial . Para este tema, primero nos centraremos en los primeros cuatro tipos de datos.
Sin embargo, los datos que ve en la imagen de arriba son solo datos sin procesar. Requiere identificación, extracción, conversión, asociación, agregación y otras operaciones para obtener datos de observabilidad comercial que podamos usar a diario. La siguiente imagen es un resumen de parte del procesamiento de datos sin procesar de eBPF en DeepFlow. Puede ver que podemos extraer los indicadores dorados de Solicitud/Error/Retraso de la API en función de los eventos de socket. Al correlacionar estos indicadores, podemos crear un mapa de servicio. y al correlacionar todas las llamadas, se pueden formar cadenas de llamadas de seguimiento distribuido y, al agregar estas cadenas de llamadas, se puede construir un mapa API más detallado. Entre ellos, el rastreo distribuido sin intrusión basado en eBPF es la capacidad original de DeepFlow. El rastreo distribuido se puede lograr sin instrumentación ni inyección de TraceID. Los socios interesados pueden descargarlo y probarlo en nuestro repositorio de GitHub . Además, los registros de inicio y detención de procesos se pueden extraer de Eventos de proceso, el Registro de acceso a archivos se puede extraer de Eventos de archivos y los eventos de CPU, memoria, GPU, memoria de video y bloqueo se pueden extraer de Eventos de rendimiento y se pueden extraer gráficos de llama de análisis de rendimiento. dibujado.
Además de obtener la señal de observación, una tarea importante que debemos realizar es inyectar etiquetas unificadas en los datos. Por ejemplo, inyectar etiquetas de recursos y negocios obtenidas de K8, Cloud y CMDB nos ayuda a asociar horizontalmente datos de pila completa, inyectando etiquetas a nivel de sistema, como procesos, subprocesos y corrutinas, así como etiquetas a nivel de red, como Subred, IP y TCP SEQ nos ayudan a asociar verticalmente cadenas de llamadas distribuidas.
Tomando el seguimiento distribuido como ejemplo, echemos un vistazo al efecto de DeepFlow usando eBPF. La siguiente figura compara la diferencia entre los resultados de seguimiento de APM y eBPF: el uso de APM generalmente puede cubrir el proceso de Java, pero generalmente es difícil cubrir la puerta de enlace API, la puerta de enlace de microservicio, la red de servicios, DNS, Redis, MySQL, etc. El costo de cobertura de aplicaciones del lenguaje Java también es relativamente alto. Utilizando eBPF, basado en cero intrusiones y datos de pila completa, toda la pila de llamadas puede cubrir todos los procesos comerciales y procesos de infraestructura, así como la transmisión de red K8, la lectura y escritura de archivos y otros eventos. Esta capacidad es una innovación muy vanguardista. Publicamos este trabajo en un artículo académico de casi 20 páginas, que fue aceptado por ACM SIGCOMM, la principal conferencia académica de la American Computer Society, el año pasado.
Volviendo al tema de la observabilidad empresarial de la sesión de hoy , ¿cómo se asocian los datos obtenidos por eBPF del kernel con el negocio? eBPF es una tecnología central y toda la discusión ecológica se centra en el sistema, el rendimiento, la seguridad, etc., mientras que las aplicaciones se centran en la semántica empresarial y los desarrolladores esperan obtener información empresarial y de eficiencia. Cómo hacer que la observabilidad de eBPF atraviese el muro dimensional, desde el sistema hasta el negocio, permítanme hablar sobre el enfoque de DeepFlow. Tomando Socket Data como ejemplo, cuando realizamos el análisis de protocolos de los datos obtenidos por eBPF, generalmente solo analizamos los campos de encabezado de protocolos estándar (como HTTP, MySQL, etc.). DeepFlow ahora admite más de 20 análisis de protocolos, que cubren las categorías HTTP1/2/S, RPC, MQ, DB y Red. Las capacidades de análisis integradas de DeepFlow pueden extraer campos estándar de los encabezados de estos protocolos e incluso cargas útiles, como URL, declaraciones SQL, códigos de error, etc. Sin embargo, información como códigos de error comerciales, números de serie de transacciones, ID de pedidos y números de bastidor de automóvil ubicados en la carga útil HTTP no se pueden extraer de acuerdo con una lógica unificada. Y, a veces, la empresa utilizará Protobuf, Thrift y otros métodos para la serialización, y debe combinarse con el esquema correspondiente para analizar la carga útil.
Aquí utilizamos otra tecnología WebAssembly para resolver este problema. De hecho, si pensamos que eBPF es una tecnología programable por el kernel, entonces WebAssembly es una tecnología programable en modo de usuario. DeepFlow lo usa para implementar un conjunto de mecanismos de complementos seguros, de alto rendimiento y de carga en caliente. Los usuarios pueden usar Golang, Rust, C/C++ y otros lenguajes para escribir complementos para lograr el análisis bajo demanda de cargas comerciales. analizando así el registro de solicitudes y el registro de acceso a archivos. Espere a que se mejoren los datos de observación de eBPF. Por ejemplo, puede escribir un programa Golang basado en el SDK de complemento proporcionado por DeepFlow para analizar la carga útil HTTP Protobuf y extraer los campos de interés comercial. Incluso puede utilizar el código de error, el mensaje de error y otra información en la carga útil para reescribir los campos correspondientes en el registro de solicitudes HTTP original.
Finalmente, el título de esta sección es "Construcción de fuentes de señales de observabilidad de alta calidad utilizando eBPF". Por lo tanto, nuestra opinión es que eBPF es una infraestructura y el primer paso en toda la construcción de la observabilidad. Sobre la base sólida de las capacidades de observabilidad de intrusión cero, podemos incorporar datos intrusivos tradicionales bajo demanda e inyectar etiquetas unificadas para construir una plataforma de observabilidad más poderosa. Las capacidades de eBPF son como escribir una sección al comienzo de Star Wars Whos your daddypara abrir completamente el mapa , mientras que los datos intrusivos tradicionales son como el lado comercial que usa bolas científicas para realizar exploración de punto fijo de áreas locales a pedido.
02
Utilice LLM para crear agentes de observabilidad eficientes
El segundo punto compartido hoy es cómo utilizar las capacidades de LLM para crear inteligencia observable basada en datos de alta calidad. En el pasado, el mayor problema de AIOps era la mala calidad de los datos (baja cobertura, formato desordenado). Cuando planea comenzar a hacer AIOps, generalmente lleva medio año o más promover la gobernanza de datos. Ahora, los datos de alta calidad de eBPF significan que la base es sólida. Al mismo tiempo, coincide con la era AGI y LLM ha demostrado capacidades mucho más poderosas que los modelos pequeños anteriores. Por lo tanto, creemos que eBPF + LLM es la infraestructura para realizar agentes de observabilidad . Permítanme compartir algunas prácticas de DeepFlow en esta área.
En esta etapa, DeepFlow no crea agentes para todos los problemas. Esperamos explorar los problemas en todo el proceso de desarrollo, prueba y operación y mantenimiento, y seleccionar dos o tres que sean más difíciles de resolver combinando observabilidad + agentes. Para comprender los puntos débiles, primero concéntrese en estos dos o tres puntos. El primer escenario que encontramos son las órdenes de trabajo , específicamente el proceso caótico en las primeras etapas de creación de un grupo de órdenes de trabajo. El segundo escenario son los cambios , específicamente la rápida demarcación de la degradación del rendimiento después de los cambios. El tercer escenario son las Vulnerabilidades , todavía estamos explorando; este escenario, y hoy compartiremos algunas de nuestras ideas preliminares.
Ineficiencia de las órdenes de trabajo : supongamos primero que una alarma en su empresa desencadenará la creación de un chat grupal, como un grupo Feishu. Tomemos un escenario típico que vemos en la oficina de un cliente: después de que la primera persona ingresa al grupo de órdenes de trabajo, puede mirar los datos de seguimiento de la cadena de llamadas, hacer algunos análisis y descubrir que no es su problema; segunda persona en el grupo de orden de trabajo, únase al grupo, esta persona miró algunos datos de indicadores, y después de hacer un análisis, descubrió que no era su problema, luego trajo a una tercera persona al grupo, esta persona miró el; datos del evento, y después de hacer un poco de análisis, todavía descubrió que no era su problema; luego, incorporó a la cuarta persona, a la quinta persona,...; Wang, fue incorporado al grupo, y se hizo un análisis y un resumen más profundo y detallado, para que el ataúd pudiera finalizarse y el trabajo. Enviar la orden a la persona a cargo correcta, Xiao Li . A menudo nos encontramos con que antes de que la orden de trabajo coincida con Xiao Li, el proceso es muy confuso e ineficiente y puede tardar más de una hora. Incluso si las personas que fueron traídas al principio no participan en todo el proceso, la existencia de este grupo de orden de trabajo interrumpirá su trabajo normal de vez en cuando, lo que tiene un impacto significativo en la eficiencia de todos en la orden de trabajo. grupo.
¿Cómo puede un agente de observabilidad resolver este problema? Cuando se crea una orden de trabajo, el robot controlado por el agente AI se incorporará automáticamente al grupo de órdenes de trabajo. El Agente de IA primero llama a la API de DeepFlow para ver el seguimiento, indicadores, eventos, registros y otros tipos de datos, y utiliza una serie de algoritmos estadísticos para resumir las características de los datos (reduciendo así efectivamente la cantidad de Tokens), y luego utiliza esta información de funciones como indicaciones para llamar a LLM (actualmente, GPT4 se utiliza principalmente para análisis. Después de analizar un tipo de datos, el Agente de IA utiliza las capacidades de llamada a funciones o modo JSON de LLM para decidir qué otro tipo o tipos de datos deben analizarse. Finalmente, el Agente de IA solicita a LLM que haga un resumen basado en todos los resultados del análisis.
En este proceso, eBPF de DeepFlow proporciona datos de observabilidad completos y de pila completa, y AutoTagging inyecta etiquetas unificadas y semánticamente ricas en todos los datos . Según los resultados del análisis, el Agente de IA puede utilizar etiquetas como label.owner para incluir con precisión a la persona a cargo correspondiente en el grupo de órdenes de trabajo. En esta etapa, aunque la precisión de la delimitación de la orden de trabajo del Agente AI no puede alcanzar el 100%, ha podido comprimir con éxito el período inicial muy caótico del grupo de órdenes de trabajo de más de una hora a un minuto en la mayoría de los casos, y ha logrado mejoró significativamente la eficiencia del grupo de órdenes de trabajo. Se reduce el número de personas en el grupo de órdenes de trabajo, mejorando así significativamente la eficiencia del trabajo de todo el equipo .
Ineficiencia de los cambios : descubrimos que en un entorno nativo de la nube, las razones de la degradación del rendimiento después del lanzamiento del servicio pueden ser multifacéticas y, debido a la complejidad de la cadena de llamadas y la pila de códigos de software, a veces es difícil para los socios responsables de On Call. localizar La causa fundamental es que también es muy posible juzgar mal fácilmente debido a la ignorancia del contenido más allá del alcance del propio conocimiento. Después de que ocurre este tipo de problema, la única forma es expandir temporalmente la capacidad o retroceder para restaurar el negocio y esperar a que se solucione el problema antes de lanzar la versión nuevamente. Sin embargo, es posible que el entorno de prueba no pueda reproducir los problemas en el entorno de producción, por lo que debemos introducir una serie de mecanismos de reproducción de tráfico para ayudar a analizar la causa raíz del problema. En este escenario, esperamos que AI Agent pueda ayudar a los desarrolladores a identificar rápidamente las causas fundamentales de la degradación del rendimiento y volver a poner la versión en línea mucho antes.
Para escenarios con cadenas de llamadas complejas, ya tenemos una buena solución en el ejemplo del agente de órdenes de trabajo. Para escenarios con pilas de llamadas de funciones complejas, esta es la especialidad de eBPF. Puede obtener funciones comerciales, funciones de biblioteca, funciones de tiempo de ejecución y pilas de llamadas de funciones del kernel cuando el proceso se está ejecutando sin ninguna intrusión. Debido a la seguridad y la baja sobrecarga de eBPF, la creación de perfiles se puede activar continuamente. Por lo tanto, los datos de la creación de perfiles generalmente se acumulan durante un período de tiempo antes de que el rendimiento se deteriore a un nivel intolerable después del cambio. datos para completar rápidamente la delimitación de la causa raíz.
Los datos de eBPF Profiling cubren una amplia gama de pilas de tecnología y es difícil para cualquier desarrollador de negocios comprender toda la información. Este escenario es en lo que AI Agent es bueno. Como se muestra en la figura siguiente, LLM generalmente puede comprender el conocimiento de las funciones del kernel, las funciones de tiempo de ejecución y las funciones básicas de la biblioteca, por lo que los resultados del análisis de estas funciones se pueden proporcionar directamente. Incluso si hay cosas en las que LLM no es bueno, dado que los proyectos de software donde se encuentran dichas funciones no se actualizan con frecuencia y pertenecen al conocimiento común, podemos considerar mejorar las partes que LLM no domina mediante ajustes. Echemos un vistazo a algunas funciones de biblioteca de aplicaciones de uso común, como las solicitudes de Python, etc. Estas bibliotecas se caracterizan por una gran cantidad, una iteración rápida y una rica documentación de interfaz. Podemos considerar vectorizar la documentación de dichas funciones y utilizar el mecanismo RAG para. mejorar el análisis LLM. Más arriba están los códigos comerciales internos de la empresa. No son de conocimiento común, son más numerosos y cambian más rápido. Por lo tanto, elegimos optimizar las palabras clave para enviarlas directamente a LLM. Por ejemplo, podemos inyectar el Git correspondiente. La etiqueta commit_id en K8s puede permitir que el agente AI ubique fácilmente el registro de modificación de código reciente a través de commit_id y notifique a LLM. Se puede ver que mediante el uso combinado de la tecnología LLM, Fine-tuning, RAG e Prompt Engineering, todos los campos profesionales involucrados en los datos de creación de perfiles de pila completa de eBPF se pueden cubrir por completo, lo que ayuda a los desarrolladores a identificar rápidamente las causas fundamentales .
Ineficiencia de las vulnerabilidades : un informe decía: "La rectificación de vulnerabilidades puede ser inútil en un 76% y sólo se debe prestar atención prioritaria al 3% de las vulnerabilidades". DeepFlow todavía está explorando cómo utilizar AI Agent para mejorar la eficiencia en este enlace. Lo que es seguro es que eBPF es una excelente tecnología de recopilación de datos para Cloud Workload Security. Isovalent resume las cuatro señales de oro de observación de la seguridad: ejecución de procesos, socket de red, acceso a archivos e identidad de red de capa 7 . Actualmente, DeepFlow tiene una cobertura parcial de estas cuatro señales y continuará mejorándola en el futuro. Creo que con la finalización de estos datos, combinados con LLM, podremos crear un agente de IA de escena de seguridad muy llamativo.
Al final de esta parte, hablemos sobre cómo mejorar continuamente AI Agent. Tomando el escenario de la orden de trabajo como ejemplo, utilizamos la ingeniería del caos en el entorno de prueba para construir una gran cantidad de datos anormales. Debido a que conocemos las causas fundamentales correctas de estas anomalías, se pueden usar para evaluar AI Agenl. y mejorarlo continuamente. En el entorno de producción (nota: el lado derecho del PPT debe ser el entorno de producción), hemos agregado un mecanismo para que los usuarios puntúen y los desarrolladores de agentes realizarán mejoras en función de las puntuaciones.
03
Ejemplos de práctica de agentes de observabilidad para usuarios de DeepFlow
Entonces, ¿cómo se ve ahora el agente AI de DeepFlow? Demos una rápida introducción a esta parte. Actualmente, en la página de DeepFlow Enterprise Edition, el Agente de IA puede ser convocado desde el mapa de topología, el seguimiento de la cadena de llamadas y las páginas de análisis continuo. Al mismo tiempo, Feishu ChatBot también puede llamar a la API del Agente para implementar la función. de un experto en órdenes de trabajo. Después de que el Agente de IA brinde la primera ronda de resumen, también proporcionará alrededor de tres o cuatro preguntas que puede continuar haciendo. Puede hacer clic directamente en estas preguntas para continuar la conversación. Por supuesto, los usuarios también pueden introducir directamente sus propias preguntas para dialogar.
Además, la capacidad AI Agent también se lanzó hoy en DeepFlow Community Edition y actualmente puede analizar los datos actuales de Grafana Panel. Actualmente admitimos dos paneles, Topo y Tracing, y estamos adaptados a cuatro modelos grandes: GPT, Tongyi Qianwen, Wenxinyiyan y ChatGLM. Puede descargarlo y probarlo.
04
Reflexiones sobre las direcciones de la evolución futura
Finalmente, permítanme compartir la dirección de evolución futura de DeepFlow AI Agent.
Ahora, eBPF puede cubrir completamente las aplicaciones en la nube. A continuación, ampliaremos sus capacidades al lado final, incluida la conducción autónoma y el control de dominio espacial inteligente en automóviles inteligentes, así como algunos escenarios de teléfonos inteligentes donde se permiten permisos.
Por otro lado, también descubrimos que RAG tiene mucho espacio para la optimización. Aquí hay una revisión de RAG: Generación aumentada de recuperación para modelos de lenguaje grandes: una encuesta . Esperamos que sea útil para todos.
05
¿Qué es DeepFlow?
DeepFlow es un producto de observabilidad desarrollado por Yunshan Network , cuyo objetivo es proporcionar una observabilidad profunda para infraestructuras de nube complejas y aplicaciones nativas de la nube. Basado en eBPF, DeepFlow realiza una recopilación sin intrusión ( Zero Code) de señales de observación, como indicadores de rendimiento de aplicaciones, seguimiento distribuido y análisis de rendimiento continuo, y se combina con la tecnología de etiquetas inteligentes ( SmartEncoding) para lograr una correlación completa ( Full Stack) y un acceso eficiente a todos. señales de observación. Al utilizar DeepFlow, las aplicaciones nativas de la nube pueden tener automáticamente una observabilidad profunda, eliminando así la pesada carga de la instrumentación continua para los desarrolladores y brindando a los equipos de DevOps/SRE capacidades de monitoreo y diagnóstico desde el código hasta la infraestructura.
Dirección de GitHub: https://github.com/deepflowio/deepflow
Visite la demostración de DeepFlow para experimentar cero instrumentación, cobertura total y observabilidad totalmente relevante.
Vista previa del evento | Encuentro de desarrolladores de código abierto sobre observabilidad "Observabilidad inteligente: evolución observable impulsada por modelos grandes"