Cet article est compilé à partir du discours partagé par Xiang Yang, chef de produit DeepFlow de Yunshan Network, lors de la QCon Global Software Development Conference (Beijing) 2024 , sur le thème « eBPF + LLM : Infrastructure for Realizing Observable Agents ». Consultez le lien et téléchargez le PPT .
Compte à rebours pour les inscriptions pour la deuxième journée ! Venez rejoindre le Meetup des développeurs Open Source d'Observabilité à Nanjing Station |
Aujourd'hui, je suis heureux de partager avec vous une partie du travail effectué par DeepFlow sur les agents d'observabilité. Le sujet d'aujourd'hui comprend principalement deux aspects : comment utiliser eBPF pour résoudre des problèmes de qualité des données, et comment utiliser LLM pour construire des agents efficaces sur cette base. A partir de ces deux aspects, nous pouvons comprendre pourquoi eBPF et LLM sont des infrastructures clés pour réaliser des agents d'observabilité .
La première question ci-dessus concerne en réalité la gouvernance des données. Il existe de nombreuses façons d’obtenir des données de haute qualité, par exemple en utilisant des spécifications organisationnelles et en améliorant l’efficacité de l’ingénierie R&D. Ce que je partage aujourd'hui concerne principalement ce dernier point, en particulier comment utiliser eBPF, une technologie innovante, pour obtenir des données d'observabilité full-stack sans intrusion. Une fois que nous disposons de données de haute qualité, nous pouvons utiliser LLM, combiné à l'ingénierie de mots rapides, au RAG, au réglage fin et à d'autres méthodes, pour créer un agent observable efficace. Les pratiques partagées aujourd'hui proviennent de notre produit d'observabilité DeepFlow, qui est également un projet open source de plus en plus populaire. Enfin, je partagerai également mes réflexions sur l'évolution des agents observables.
01
Créez des sources de signaux d'observabilité de haute qualité à l'aide de l'eBPF
L’essence du premier enjeu est la gouvernance des données, dans le but d’obtenir des données d’observabilité de haute qualité. Jetons d'abord un coup d'œil aux solutions traditionnelles. Par exemple, nous utilisons APM pour collecter des données. Comment garantir l'intégrité et la pertinence des données à ce moment-là ? Surtout dans un environnement cloud natif, lorsque le client accède au serveur, il peut passer par des réseaux K8 complexes, diverses passerelles, divers middlewares, bases de données, DNS et autres services de base. Ces liens intermédiaires ne sont pas couverts par l'APM. , même l'emplacement observé de l'APM et la demande réseau réelle du processus seront différents. Lorsque nous effectuons la gouvernance et l'analyse des données sur cette base, nous constatons généralement qu'il existe des problèmes d'intégrité et de cohérence des données. Il faut souvent beaucoup de temps et d'énergie pour promouvoir et améliorer la couverture des instruments côté entreprise, et nous également. Il est nécessaire d'utiliser la capture de paquets, les journaux et d'autres méthodes sont utilisés pour concaténer les données hétérogènes d'un grand nombre de services de base. L'image ci-dessous est considérée comme un problème que nous rencontrons souvent lors de l'utilisation d'APM : le délai observé par le client est de 500 ms, mais le délai observé par le serveur n'est que de 10 ms. Ce qui est encore pire, c'est que le serveur n'a peut-être pas envoyé l'instrumentation. encore.
Plus près de chez nous, pourquoi dit-on que l’eBPF est l’infrastructure pour des sources de signaux d’observabilité de haute qualité ? La technologie eBPF est une technologie programmable par le noyau. Chaque petite abeille dans l'image ci-dessous est une position de fonction que eBPF peut accrocher. Nous pouvons utiliser eBPF pour percevoir tous les états internes de n'importe quel processus sur l'hôte cloud via les fonctions métier Hook, les appels système, les fonctions du noyau, les fonctions réseau et de pilote de disque. Plus important encore, cette action est totalement sûre grâce à l'existence d'eBPF Verifier, et grâce au mécanisme de compilation JIT, ses performances sont comparables à celles du code natif du noyau.
La technologie eBPF présente deux avantages uniques et peut bien résoudre les problèmes de qualité des données rencontrés par l'APM. Le premier avantage est le zéro intrusion (Zero Code) . Le fonctionnement d'un programme eBPF ne nécessite aucune modification du code, aucune recompilation ou redémarrage d'un quelconque processus d'application. Il s'agit d'une technologie plug-and-play qui peut être téléchargée sur votre production à tout moment. temps. Le deuxième avantage est le Full Stack . Qu'il s'agisse d'un processus métier, d'une passerelle, d'une file d'attente de messages, d'une base de données ou d'un système d'exploitation, eBPF peut être utilisé pour collecter des données d'observation. Par conséquent, lorsqu'un processus est en cours d'exécution, son interaction avec l'ensemble de la pile logicielle, de la logique métier au temps d'exécution du langage, des bibliothèques partagées au noyau en passant par les pilotes matériels, peut être couverte à l'aide d'eBPF. À partir de la figure ci-dessous, nous pouvons voir que les données brutes que eBPF peut collecter sont très riches, notamment : les événements de processus, les événements de fichiers, les événements de performances, les événements de socket, les événements de noyau et les événements matériels. Le thème de la session QCon d'aujourd'hui est l'observabilité commerciale . Pour ce sujet, nous nous concentrons d'abord sur les quatre premiers types de données.
Cependant, les données que vous voyez dans l'image ci-dessus ne sont que des données brutes. Elles nécessitent une identification, une extraction, une conversion, une association, une agrégation et d'autres opérations pour obtenir des données d'observabilité commerciale que nous pouvons utiliser quotidiennement. L'image ci-dessous est un résumé d'une partie du traitement des données brutes eBPF dans DeepFlow. Vous pouvez voir que nous pouvons extraire les indicateurs dorés de demande/erreur/délai de l'API basés sur les événements de socket, en corrélant ces indicateurs, nous pouvons créer une carte de service. , et en corrélant tous les appels, des chaînes d'appels de traçage distribuées peuvent être formées, et en agrégeant ces chaînes d'appels, une carte API plus fine peut être construite. Parmi eux, le traçage distribué sans intrusion basé sur eBPF est la capacité originale de DeepFlow. Le traçage distribué peut être réalisé sans instrumentation ni injection TraceID. Les partenaires intéressés sont invités à le télécharger et à l'essayer sur notre dépôt GitHub . De plus, les journaux de démarrage et d'arrêt des processus peuvent être extraits des événements de processus, le journal d'accès aux fichiers peut être extrait des événements de fichiers, et les événements de processeur, de mémoire, de GPU, de mémoire vidéo et de verrouillage peuvent être extraits des événements de performances et les graphiques de flamme d'analyse des performances peuvent être extraits. dessiné.
En plus d'obtenir le signal d'observation, une tâche importante que nous devons accomplir est d'injecter des étiquettes unifiées dans les données. Par exemple, l'injection de balises de ressources et d'entreprise obtenues à partir de K8, Cloud et CMDB nous aide à associer horizontalement des données complètes ; en injectant des balises au niveau du système telles que les processus, les threads et les coroutines, ainsi que des balises au niveau du réseau telles que le sous-réseau, IP et TCP SEQ nous aident à associer verticalement des chaînes d'appels distribuées.
En prenant le traçage distribué comme exemple, examinons l'effet de DeepFlow utilisant eBPF. La figure suivante compare la différence entre les résultats de suivi APM et eBPF : l'utilisation d'APM peut généralement couvrir le processus Java, mais il est généralement difficile de couvrir la passerelle API, la passerelle microservice, la grille de services, DNS, Redis, MySQL, etc. application, et il est difficile de couvrir d'autres non- Le coût de couverture des applications du langage Java est également relativement élevé. Grâce à eBPF, basé sur zéro intrusion et sur des données complètes, l'ensemble de la pile d'appels peut couvrir tous les processus métier et les processus d'infrastructure, ainsi que la transmission réseau du K8, la lecture et l'écriture de fichiers et d'autres événements. Cette capacité est une innovation très avant-gardiste. Nous avons publié ces travaux dans un article académique de près de 20 pages, qui a été accepté l'année dernière par l'ACM SIGCOMM, la plus haute conférence académique de l'American Computer Society.
Revenant au sujet de la session d'aujourd'hui sur l'observabilité métier , comment les données obtenues par eBPF à partir du noyau sont-elles associées à l'entreprise ? eBPF est une technologie de base, et toute la discussion écologique se concentre sur le système, les performances, la sécurité, etc. ; tandis que les applications se concentrent sur la sémantique commerciale et que les développeurs espèrent obtenir des informations commerciales et efficaces. Comment faire en sorte que l'observabilité de l'eBPF franchisse le mur dimensionnel, du système à l'entreprise, permettez-moi de parler de l'approche de DeepFlow. En prenant Socket Data comme exemple, lors de l'analyse de protocole sur les données obtenues par eBPF, nous analysons généralement uniquement les champs d'en-tête des protocoles standard (tels que HTTP, MySQL, etc.). DeepFlow prend désormais en charge plus de 20 analyses de protocoles, couvrant les catégories HTTP1/2/S, RPC, MQ, DB et Réseau. Les capacités d'analyse intégrées de DeepFlow peuvent extraire des champs standard des en-têtes de ces protocoles et même des charges utiles, telles que des URL, des instructions SQL, des codes d'erreur, etc. Cependant, les informations telles que les codes d'erreur commerciaux, les numéros de série de transactions, les identifiants de commande et les numéros de châssis de voiture situés dans HTTP Payload ne peuvent pas être extraits selon une logique unifiée. Et parfois, l'entreprise utilise Protobuf, Thrift et d'autres méthodes de sérialisation, et celles-ci doivent être combinées avec le schéma correspondant pour analyser la charge utile.
Ici nous utilisons une autre technologie WebAssembly pour résoudre ce problème. En fait, si l’on pense qu’eBPF est une technologie programmable par le noyau, alors WebAssembly est une technologie programmable en mode utilisateur. DeepFlow l'utilise pour implémenter un ensemble de mécanismes de plug-ins sécurisés, hautes performances et de chargement à chaud. Les utilisateurs peuvent utiliser Golang, Rust, C/C++ et d'autres langages pour écrire des plugins afin de réaliser une analyse à la demande des charges utiles de l'entreprise. analysant ainsi le journal des demandes et le journal d'accès aux fichiers. Attendez que les données d'observation eBPF soient améliorées. Par exemple, vous pouvez écrire un programme Golang basé sur le SDK de plug-in fourni par DeepFlow pour analyser la charge utile HTTP Protobuf et extraire les domaines d'intérêt commercial. Vous pouvez même utiliser le code d'erreur, le message d'erreur et d'autres informations dans la charge utile pour réécrire les champs correspondants dans le journal des requêtes HTTP d'origine.
Enfin, le titre de cette section est « Création de sources de signaux d'observabilité de haute qualité à l'aide de l'eBPF ». Par conséquent, notre point de vue est que l’eBPF est une infrastructure et la première étape de toute la construction de l’observabilité. Sur la base de capacités d'observabilité sans intrusion, nous pouvons incorporer des données intrusives traditionnelles à la demande et injecter des étiquettes unifiées pour créer une plate-forme d'observabilité plus puissante. Les capacités de l'eBPF sont comme si l'on tapait une section au début de Star Wars Whos your daddypour ouvrir complètement la carte ; tandis que les données intrusives traditionnelles sont comme si le côté commercial utilisait des boules scientifiques pour effectuer une exploration à point fixe de zones locales à la demande.
02
Utilisez LLM pour créer des agents d'observabilité efficaces
Le deuxième point partagé aujourd’hui est de savoir comment utiliser les capacités du LLM pour créer une intelligence observable basée sur des données de haute qualité. Dans le passé, le plus gros problème de l’AIOps était la mauvaise qualité des données (faible couverture, format compliqué). Lorsque vous envisagez de commencer à utiliser l'AIOps, il faut généralement six mois ou plus pour promouvoir la gouvernance des données. Aujourd’hui, les données de haute qualité de l’eBPF signifient que la base est solide. En même temps, cela coïncide avec l’ère AGI, et le LLM a démontré des capacités bien plus puissantes que les petits modèles précédents. Nous pensons donc que eBPF + LLM est l'infrastructure pour réaliser des agents d'observabilité . Permettez-moi de partager quelques pratiques DeepFlow dans ce domaine.
À ce stade, DeepFlow ne construit pas d'agents pour tous les problèmes.Nous espérons explorer les problèmes dans l'ensemble du processus de développement, de test, d'exploitation et de maintenance, et en sélectionner deux ou trois qui sont les plus difficiles à résoudre en combinant observabilité + agents. Pour comprendre les points douloureux, concentrez-vous d’abord sur ces deux ou trois points. Le premier scénario que nous avons trouvé est celui des ordres de travail , en particulier le processus chaotique dans les premières étapes de création d'un groupe d'ordres de travail ; le deuxième scénario est celui des changements , en particulier la démarcation rapide de la dégradation des performances après les changements ; le troisième scénario est celui des vulnérabilités , que nous explorons toujours ; ce scénario, et aujourd’hui nous partagerons certaines de nos réflexions préliminaires.
Inefficacité des bons de travail : Supposons d'abord qu'une alarme dans votre entreprise déclenchera la création d'un chat de groupe, comme un groupe Feishu. Prenons un scénario typique que nous voyons dans le bureau d'un client : une fois que la première personne a été intégrée au groupe d'ordres de travail, elle peut examiner les données de suivi de la chaîne d'appels, effectuer une analyse et constater que ce n'est pas son problème, puis elle récupère le problème ; deuxième personne dans le groupe de bons de travail. Rejoignez le groupe, cette personne a regardé certaines données d'indicateur, et après avoir fait quelques analyses, il a découvert que ce n'était pas son problème, puis il a amené une troisième personne dans le groupe, cette personne a regardé le groupe ; les données de l'événement, et après avoir fait quelques analyses, il a quand même découvert que ce n'était pas son problème ; puis appelez la quatrième personne, la cinquième personne,... ; Wang a été intégré au groupe, et une analyse et un résumé plus approfondis et détaillés ont été effectués, afin que le cercueil puisse être finalisé et que le travail puisse être transmis. Transmettre la commande au bon responsable, Xiao Li . Nous constatons souvent qu'avant que le bon de travail ne soit associé à Xiao Li, le processus est très déroutant et inefficace, et peut prendre plus d'une heure. Même si les personnes recrutées au début ne participent pas à l'ensemble du processus, l'existence de ce groupe d'ordres de travail interrompra de temps en temps leur travail normal, ce qui a un impact significatif sur l'efficacité de chacun dans l'ordre de travail. groupe.
Comment un agent d’observabilité peut-il résoudre ce problème ? Lorsqu'un bon de travail est créé, le robot piloté par AI Agent sera automatiquement intégré au groupe de bons de travail. L'agent AI appelle d'abord l'API DeepFlow pour afficher le suivi, les indicateurs, les événements, les journaux et d'autres types de données, et utilise une série d'algorithmes statistiques pour résumer les caractéristiques des données (réduisant ainsi efficacement le nombre de jetons), puis utilise ces informations sur les fonctionnalités comme invites pour appeler LLM (actuellement, GPT4 est principalement utilisé pour l'analyse. Après avoir analysé un type de données, l'agent AI utilise les capacités d'appel de fonction ou de mode JSON de LLM pour décider quel(s) autre(s) type(s) de données doivent être analysés. Enfin, l'agent AI demande à LLM de faire un résumé basé sur tous les résultats d'analyse.
Dans ce processus, l'eBPF de DeepFlow fournit des données d'observabilité complètes et complètes, et le marquage automatique injecte des étiquettes unifiées et sémantiquement riches dans toutes les données . Sur la base des résultats de l'analyse, l'agent IA peut utiliser des étiquettes telles que label.owner pour attirer avec précision la personne responsable correspondante dans le groupe de bons de travail. À ce stade, bien que la précision de la délimitation des ordres de travail d'AI Agent ne soit pas encore à 100 %, il a réussi à compresser avec succès le groupe chaotique d'ordres de travail initial de plus d'une heure à une minute dans la plupart des cas, et il a considérablement amélioré le le nombre de personnes dans le groupe de bons de travail est réduit, améliorant ainsi considérablement l'efficacité du travail de toute l'équipe .
Inefficacité des changements : Nous avons constaté que dans un environnement cloud natif, les raisons de la dégradation des performances après la sortie du service peuvent être multiples, et en raison de la complexité de la chaîne d'appel et de la pile de code logiciel, il est parfois difficile pour les partenaires responsables d'On Call localiser La cause fondamentale est qu'il est également très possible de se tromper facilement en raison de l'ignorance d'un contenu dépassant la portée de ses propres connaissances. Une fois ce type de problème survenu, le seul moyen est d'augmenter temporairement la capacité ou de revenir en arrière pour restaurer l'activité, et d'attendre que le problème soit résolu avant de publier à nouveau la version. Cependant, l'environnement de test peut ne pas être en mesure de reproduire les problèmes dans l'environnement de production. Nous devons donc introduire une série de mécanismes de lecture du trafic pour aider à analyser la cause première du problème. Dans ce scénario, nous espérons qu’AI Agent pourra aider les développeurs à identifier rapidement les causes profondes de la dégradation des performances et à remettre la version en ligne beaucoup plus tôt.
Pour les scénarios avec des chaînes d'appels complexes, nous avons déjà une bonne solution dans l'exemple de l'agent d'ordre de travail. Pour les scénarios avec des piles d'appels de fonctions complexes, c'est la spécialité d'eBPF. Il peut obtenir des fonctions métier, des fonctions de bibliothèque, des fonctions d'exécution et des piles d'appels de fonctions du noyau lorsque le processus s'exécute sans aucune intrusion. En raison de la sécurité et de la faible surcharge d'eBPF, le profilage peut être activé en permanence. Par conséquent, les données de profilage ont généralement été accumulées pendant un certain temps avant que les performances ne se détériorent à un niveau intolérable après le changement. données pour compléter rapidement la délimitation des causes profondes.
Les données de profilage eBPF couvrent un très large éventail de piles technologiques, et il est difficile pour tout développeur commercial de comprendre toutes les informations. Ce scénario se trouve être celui pour lequel AI Agent est doué. Comme le montre la figure ci-dessous, LLM est généralement capable de comprendre la connaissance des fonctions du noyau, des fonctions d'exécution et des fonctions de base de la bibliothèque, de sorte que les résultats de l'analyse de ces fonctions peuvent être donnés directement. Même s'il y a des choses pour lesquelles LLM n'est pas bon, puisque les projets logiciels où se trouvent ces fonctions ne sont pas mis à jour fréquemment et appartiennent au savoir commun, nous pouvons envisager d'améliorer les parties que LLM ne maîtrise pas par un réglage fin. Jetons un coup d'œil à certaines fonctions de bibliothèque d'applications couramment utilisées, telles que les requêtes de Python, etc. Ces bibliothèques se caractérisent par un grand nombre, une itération rapide et une documentation d'interface riche. Nous pouvons envisager de vectoriser la documentation de ces fonctions et d'utiliser le mécanisme RAG pour. améliorer l’analyse LLM. Plus haut se trouvent les codes métiers internes de l'entreprise. Ils ne sont pas de notoriété publique, sont plus nombreux et changent plus rapidement. Par conséquent, nous choisissons d'optimiser les mots d'invite pour les transmettre directement à LLM. Par exemple, nous pouvons injecter le Git correspondant. commit_id dans K8. La capacité de marquage automatique de DeepFlow peut facilement permettre à l'agent AI de localiser l'enregistrement de modification de code récent via commit_id et d'en informer LLM. On peut constater que grâce à l'utilisation combinée des technologies LLM, Fine-tuning, RAG et Prompt Engineering, tous les domaines professionnels impliqués dans les données de profilage full-stack eBPF peuvent être entièrement couverts, aidant ainsi les développeurs à identifier rapidement les causes profondes .
Inefficacité des vulnérabilités : Un rapport indiquait : « La rectification des vulnérabilités peut être inutile à 76 %, et seulement 3 % des vulnérabilités devraient faire l'objet d'une attention prioritaire. » DeepFlow étudie toujours comment utiliser AI Agent pour améliorer l'efficacité de ce lien. Ce qui est certain, c'est qu'eBPF est une excellente technologie de collecte de données pour la sécurité des charges de travail dans le cloud. Isovalent résume les quatre signaux d'observation en or de la sécurité : exécution des processus, socket réseau, accès aux fichiers et identité réseau de couche 7 . DeepFlow couvre actuellement partiellement ces quatre signaux et continuera de l'améliorer à l'avenir. Je pense qu'avec l'achèvement de ces données, combiné avec LLM, nous serons en mesure de créer un agent IA de scène de sécurité très accrocheur.
À la fin de cette partie, parlons de la façon d’améliorer continuellement AI Agent. En prenant le scénario d'ordre de travail comme exemple, nous utilisons l'ingénierie du chaos dans l'environnement de test pour construire une grande quantité de données anormales. Parce que nous connaissons les causes profondes correctes de ces anomalies, elles peuvent être utilisées pour évaluer l'IAAgenl. et l'améliorer continuellement. Dans l'environnement de production (remarque : le côté droit du PPT doit être l'environnement de production), nous avons ajouté un mécanisme permettant aux utilisateurs de noter, et les développeurs d'agents apporteront des améliorations en fonction des scores.
03
Exemples de pratiques d'agent d'observabilité pour les utilisateurs de DeepFlow
Alors, à quoi ressemble l’agent IA de DeepFlow maintenant ? Donnons une brève introduction à cette partie. Actuellement, dans la page DeepFlow Enterprise Edition, l'agent IA peut être invoqué à partir de la carte topologique, du suivi de la chaîne d'appels et des pages d'analyse continue. En même temps, l'API de l'agent peut également être appelée par Feishu ChatBot pour implémenter la fonction. d'un expert en bons de travail. Une fois que l'agent IA a donné le premier tour de résumé, il proposera également environ trois ou quatre questions que vous pourrez continuer à poser. Vous pouvez directement cliquer sur ces questions pour continuer la conversation. Bien entendu, les utilisateurs peuvent également saisir directement leurs propres questions pour le dialogue.
De plus, la fonctionnalité AI Agent a également été publiée aujourd'hui dans DeepFlow Community Edition et est actuellement capable d'analyser les données actuelles du Grafana Panel. Actuellement, nous prenons en charge deux panneaux, Topo et Tracing, et sommes adaptés à quatre grands modèles : GPT, Tongyi Qianwen, Wenxinyiyan et ChatGLM. Vous êtes invités à le télécharger et à l'essayer.
04
Réflexions sur les orientations futures de l'évolution
Enfin, permettez-moi de partager l'orientation future de l'évolution de DeepFlow AI Agent.
Désormais, eBPF peut couvrir entièrement les applications cloud. Ensuite, nous étendrons ses capacités jusqu'au bout, y compris la conduite autonome et le contrôle de domaine spatial intelligent sur les voitures intelligentes, ainsi que certains scénarios de smartphone où les autorisations sont autorisées.
D'un autre côté, nous avons également constaté que RAG avait beaucoup de marge d'optimisation. Voici une revue de RAG : Retrieval-Augmented Generation for Large Language Models : A Survey .
05
Qu'est-ce que DeepFlow ?
DeepFlow est un produit d'observabilité développé par Yunshan Network , visant à fournir une observabilité approfondie des infrastructures cloud complexes et des applications cloud natives. Basé sur eBPF, DeepFlow réalise une collecte sans intrusion ( Zero Code) de signaux d'observation tels que des indicateurs de performances d'application, un traçage distribué et une analyse continue des performances, et se combine avec la technologie Smart Label ( SmartEncoding) pour obtenir une corrélation complète ( Full Stack) et un accès efficace à tous. signaux d'observation. Grâce à DeepFlow, les applications cloud natives peuvent automatiquement bénéficier d'une observabilité approfondie, éliminant ainsi le lourd fardeau de l'instrumentation continue pour les développeurs et fournissant aux équipes DevOps/SRE des capacités de surveillance et de diagnostic, du code à l'infrastructure.
Adresse GitHub : https://github.com/deepflowio/deepflow
Visitez la démo DeepFlow pour découvrir une instrumentation nulle, une couverture complète et une observabilité pleinement pertinente.
Aperçu de l'événement | Meetup des développeurs Open Source d'observabilité « Observabilité intelligente : évolution observable pilotée par de grands modèles »