Dieser Artikel ist aus der Rede von Xiang Yang, DeepFlow-Produktleiter von Yunshan Network, auf der QCon Global Software Development Conference (Peking) 2024 mit dem Thema „eBPF + LLM: Infrastruktur zur Realisierung beobachtbarer Agenten“ zusammengestellt. Überprüfen Sie den Link und laden Sie die PPT herunter .
Countdown zur Anmeldung für den zweiten Tag! Kommen Sie und nehmen Sie am Observability Open Source Developer Meetup | teil
Heute freue ich mich, mit Ihnen einen Teil der Arbeit zu teilen, die DeepFlow im Bereich Observability Agents geleistet hat. Das heutige Thema umfasst hauptsächlich zwei Aspekte: Wie kann eBPF zur Lösung von Datenqualitätsproblemen verwendet werden, und wie kann LLM verwendet werden, um auf dieser Basis effiziente Agenten zu erstellen. Aus diesen beiden Aspekten können wir erkennen, warum eBPF und LLM Schlüsselinfrastrukturen für die Realisierung von Observability Agents sind .
Bei der ersten Frage oben handelt es sich tatsächlich um ein Data-Governance-Problem. Es gibt viele Möglichkeiten, qualitativ hochwertige Daten zu erhalten, beispielsweise durch die Verwendung organisatorischer Spezifikationen und die Verbesserung der Effizienz der F&E-Technik. Was ich heute teile, ist hauptsächlich Letzteres, insbesondere wie man eBPF, eine innovative Technologie, nutzt, um Full-Stack-Observability-Daten ohne Eingriffe zu erhalten. Sobald wir über qualitativ hochwertige Daten verfügen, können wir LLM in Kombination mit Prompt Word Engineering, RAG, Feinabstimmung und anderen Methoden verwenden, um einen effizienten beobachtbaren Agenten zu erstellen. Die heute geteilten Praktiken stammen von unserem Observability-Produkt DeepFlow, das ebenfalls ein immer beliebter werdendes Open-Source-Projekt ist. Abschließend werde ich auch meine Gedanken zur Entwicklung beobachtbarer Agenten mitteilen.
01
Erstellen Sie mit eBPF hochwertige Observability-Signalquellen
Der Kern des ersten Themas ist die Datenverwaltung mit dem Ziel, qualitativ hochwertige Observability-Daten zu erhalten. Werfen wir zunächst einen Blick auf die herkömmlichen Lösungen. Wir verwenden beispielsweise APM, um die Integrität und Relevanz der Daten zu diesem Zeitpunkt sicherzustellen. Insbesondere in einer Cloud-nativen Umgebung kann der Zugriff des Clients auf den Server über komplexe K8s-Netzwerke, verschiedene Gateways, verschiedene Middleware, Datenbanken, DNS und andere grundlegende Dienste erfolgen. Diese Zwischenverbindungen können nicht abgedeckt werden , selbst der beobachtete Standort von APM und die tatsächliche Netzwerkanforderung des Prozesses werden unterschiedlich sein. Wenn wir auf dieser Grundlage Datenverwaltung und Datenanalyse durchführen, stellen wir normalerweise fest, dass es Probleme mit der Integrität und Konsistenz der Daten gibt. Die Förderung und Verbesserung der geschäftsseitigen Instrumentierungsabdeckung erfordert oft viel Zeit und Energie Sie müssen Paketerfassung und Protokolle sowie andere Methoden verwenden, um heterogene Daten einer großen Anzahl grundlegender Dienste zu verketten. Es wird angenommen, dass das folgende Bild ein Problem darstellt, auf das wir bei der Verwendung von APM häufig stoßen: Die vom Client beobachtete Verzögerung beträgt 500 ms, die vom Server beobachtete Verzögerung beträgt jedoch nur 10 ms. Noch schlimmer ist, dass der Server die Instrumentierung möglicherweise nicht gesendet hat noch.
Warum sagen wir, dass eBPF die Infrastruktur für hochwertige Observability-Signalquellen ist ? Die eBPF-Technologie ist eine vom Kernel programmierbare Technologie. Jede kleine Biene im Bild unten ist eine Funktionsposition, die eBPF einbinden kann. Wir können eBPF verwenden, um alle internen Zustände jedes Prozesses auf dem Cloud-Host über Hook-Geschäftsfunktionen, Systemaufrufe, Kernelfunktionen, Netzwerk- und Festplattentreiberfunktionen wahrzunehmen. Noch wichtiger ist, dass diese Aktion aufgrund der Existenz von eBPF Verifier absolut sicher ist und ihre Leistung aufgrund des JIT-Kompilierungsmechanismus mit dem nativen Code des Kernels vergleichbar ist.
Die eBPF-Technologie bietet zwei einzigartige Vorteile und kann die Datenqualitätsprobleme, mit denen APM konfrontiert ist, gut lösen. Der erste Vorteil ist Zero Intrusion (Zero Code) . Der Betrieb eines eBPF-Programms erfordert keine Codeänderung, Neukompilierung oder Neustart eines Anwendungsprozesses. Es handelt sich um eine Plug-and-Play-Technologie, die jederzeit in Ihre Produktion hochgeladen werden kann Zeit. Umgebung. Der zweite Vorteil ist der Full Stack . Unabhängig davon, ob es sich um einen Geschäftsprozess, ein Gateway, eine Nachrichtenwarteschlange, eine Datenbank oder ein Betriebssystem handelt, kann eBPF zum Sammeln von Beobachtungsdaten verwendet werden. Wenn ein Prozess ausgeführt wird, kann daher seine Interaktion mit dem gesamten Software-Stack, von der Geschäftslogik bis zur Sprachlaufzeit, von gemeinsam genutzten Bibliotheken über den Kernel bis hin zu Hardwaretreibern, mit eBPF abgedeckt werden. Aus der Abbildung unten können wir ersehen, dass die Rohdaten, die eBPF sammeln kann, sehr umfangreich sind, darunter: Prozessereignisse, Dateiereignisse, Leistungsereignisse, Socket-Ereignisse, Kernel-Ereignisse und Hardware-Ereignisse. Das Thema der heutigen QCon-Sitzung ist Business Observability . Bei diesem Thema konzentrieren wir uns zunächst auf die ersten vier Datentypen.
Bei den Daten, die Sie im Bild oben sehen, handelt es sich jedoch nur um Rohdaten. Sie erfordern Identifizierung, Extraktion, Konvertierung, Zuordnung, Aggregation und andere Vorgänge, um geschäftliche Observability-Daten zu erhalten, die wir täglich verwenden können. Das Bild unten ist eine Zusammenfassung eines Teils der eBPF-Rohdatenverarbeitung in DeepFlow. Sie können sehen, dass wir die goldenen Indikatoren für Anforderung/Fehler/Verzögerung basierend auf Socket-Ereignissen extrahieren können Durch die Korrelation aller Aufrufe können verteilte Tracing-Aufrufketten gebildet werden. Durch die Aggregation dieser Aufrufketten kann eine detailliertere API-Karte erstellt werden. Unter anderem ist die auf eBPF basierende Zero-Intrusion-Ablaufverfolgung die ursprüngliche Fähigkeit von DeepFlow. Die verteilte Ablaufverfolgung kann ohne Instrumentierung oder TraceID-Injection erreicht werden. Interessierte Partner können sie gerne auf unserem GitHub Repo herunterladen und ausprobieren . Darüber hinaus können Prozessstart- und Stoppprotokolle aus Prozessereignissen extrahiert werden, Dateizugriffsprotokolle können aus Dateiereignissen extrahiert werden und CPU-, Speicher-, GPU-, Videospeicher- und Sperrereignisse können aus Perf-Ereignissen extrahiert werden sowie Flammendiagramme zur Leistungsanalyse gezeichnet.
Neben der Gewinnung des Beobachtungssignals besteht eine wichtige Aufgabe darin, einheitliche Bezeichnungen in die Daten einzufügen. Das Einfügen von Ressourcen- und Geschäftstags aus K8s, Cloud und CMDB hilft uns beispielsweise dabei, Daten auf Systemebene wie Prozesse, Threads und Coroutinen sowie Tags auf Netzwerkebene wie Subnetz horizontal zuzuordnen. IP und TCP SEQ helfen uns, verteilte Anrufketten vertikal zu verknüpfen.
Schauen wir uns am Beispiel der verteilten Ablaufverfolgung die Wirkung von DeepFlow mit eBPF an. Die folgende Abbildung vergleicht den Unterschied zwischen APM- und eBPF-Tracking-Ergebnissen: Die Verwendung von APM kann im Allgemeinen den Java-Prozess abdecken, es ist jedoch normalerweise schwierig, das API-Gateway, das Microservice-Gateway, das Service Grid, DNS, Redis, MySQL usw. insgesamt abzudecken Anwendung, und es ist schwierig, andere Nicht-Anwendungen abzudecken. Die Kosten für die Anwendungsabdeckung der Java-Sprache sind ebenfalls relativ hoch. Mithilfe von eBPF, das auf Zero Intrusion und Full-Stack-Daten basiert, kann der gesamte Aufrufstapel alle Geschäftsprozesse und Infrastrukturprozesse sowie K8s-Netzwerkübertragungen, das Lesen und Schreiben von Dateien und andere Ereignisse abdecken. Diese Fähigkeit ist eine sehr innovative Innovation. Wir haben diese Arbeit in einer fast 20-seitigen wissenschaftlichen Arbeit veröffentlicht, die letztes Jahr von der ACM SIGCOMM, der wichtigsten akademischen Konferenz der American Computer Society, angenommen wurde.
Zurück zum Thema der heutigen Sitzung, der Geschäftsbeobachtbarkeit : Wie werden die von eBPF aus dem Kernel erhaltenen Daten mit dem Geschäft verknüpft? eBPF ist eine Kerntechnologie, und die gesamte ökologische Diskussion konzentriert sich auf System, Leistung, Sicherheit usw., während sich Anwendungen auf Geschäftssemantik konzentrieren und Entwickler darauf hoffen, Geschäfts- und Effizienzinformationen zu erhalten. Wie man dafür sorgt, dass die Beobachtbarkeit von eBPF die Dimensionswand durchbricht, vom System zum Unternehmen, lassen Sie mich über den Ansatz von DeepFlow sprechen. Am Beispiel von Socket-Daten analysieren wir bei der Protokollanalyse der von eBPF erhaltenen Daten normalerweise nur die Header-Felder von Standardprotokollen (wie HTTP, MySQL usw.). DeepFlow unterstützt jetzt mehr als 20 Protokollanalysen, die die Kategorien HTTP1/2/S, RPC, MQ, DB und Netzwerk abdecken. Die integrierten Parsing-Funktionen von DeepFlow können Standardfelder aus den Headern dieser Protokolle und sogar Nutzdaten wie URLs, SQL-Anweisungen, Fehlercodes usw. extrahieren. Informationen wie Geschäftsfehlercodes, Transaktionsseriennummern, Bestell-IDs und Fahrzeugrahmennummern, die sich in der HTTP-Nutzlast befinden, können jedoch nicht gemäß einer einheitlichen Logik extrahiert werden. Und manchmal verwendet das Unternehmen Protobuf, Thrift und andere Methoden zur Serialisierung und muss mit dem entsprechenden Schema kombiniert werden, um die Nutzlast zu analysieren.
Hier verwenden wir eine andere Technologie, WebAssembly, um dieses Problem zu lösen. Wenn wir glauben, dass eBPF eine Kernel-programmierbare Technologie ist, dann ist WebAssembly eine programmierbare Technologie im Benutzermodus. DeepFlow verwendet es, um eine Reihe sicherer, leistungsstarker Hot-Loading-Plugin-Mechanismen zu implementieren. Benutzer können Golang, Rust, C/C++ und andere Sprachen verwenden, um Plugins zu schreiben, um eine bedarfsgesteuerte Analyse von Geschäftsnutzlasten zu erreichen. Dabei werden das Anforderungsprotokoll und das Dateizugriffsprotokoll analysiert. Warten Sie, bis die eBPF-Beobachtungsdaten verbessert werden. Sie können beispielsweise ein Golang-Programm schreiben, das auf dem von DeepFlow bereitgestellten Plugin SDK basiert, um die HTTP-Protobuf-Nutzlast zu analysieren und die Felder von geschäftlichem Interesse zu extrahieren. Sie können sogar den Fehlercode, die Fehlermeldung und andere Informationen in der Nutzlast verwenden, um die entsprechenden Felder im ursprünglichen HTTP-Anforderungsprotokoll neu zu schreiben.
Schließlich lautet der Titel dieses Abschnitts „Aufbau hochwertiger Observability-Signalquellen mit eBPF“. Daher sind wir der Ansicht, dass eBPF eine Infrastruktur und der erste Schritt in der gesamten Observability-Konstruktion ist. Basierend auf der soliden Grundlage von Zero-Intrusion-Observability-Funktionen können wir traditionelle Intrusive-Daten bei Bedarf integrieren und einheitliche Labels einfügen, um eine leistungsfähigere Observability-Plattform aufzubauen. Die Fähigkeiten von eBPF ähneln dem Eingeben eines Abschnitts zu Beginn von Star Wars, Whos your daddyum die Karte vollständig zu öffnen , während herkömmliche aufdringliche Daten wie die Verwendung von Wissenschaftsbällen für die Unternehmensseite sind, um bei Bedarf eine Festpunkterkundung lokaler Gebiete durchzuführen.
02
Verwenden Sie LLM, um effiziente Observability-Agenten zu erstellen
Der zweite heute geteilte Punkt ist, wie man die Fähigkeiten von LLM nutzen kann, um beobachtbare Intelligenz auf der Grundlage hochwertiger Daten aufzubauen. In der Vergangenheit war die schlechte Datenqualität (geringe Abdeckung, unordentliches Format) das größte Problem von AIOps. Wenn Sie planen, mit AIOps zu beginnen, dauert es normalerweise ein halbes Jahr oder länger, um die Datenverwaltung voranzutreiben. Die hochwertigen Daten von eBPF bedeuten nun, dass die Grundlage solide ist. Gleichzeitig fällt es mit der AGI-Ära zusammen und LLM hat weitaus leistungsfähigere Fähigkeiten als frühere kleine Modelle gezeigt. Daher glauben wir, dass eBPF + LLM die Infrastruktur zur Realisierung von Observability Agents ist . Lassen Sie mich einige DeepFlow-Praktiken in diesem Bereich vorstellen.
Zum jetzigen Zeitpunkt erstellt DeepFlow nicht Agenten für alle Probleme. Wir hoffen, die Probleme im gesamten Prozess der Entwicklung, des Testens sowie des Betriebs und der Wartung zu untersuchen und zwei oder drei auszuwählen, die durch die Kombination von Beobachtbarkeit + Agenten am schwierigsten zu lösen sind. Um die Schmerzpunkte zu verstehen, konzentrieren Sie sich zunächst auf diese zwei oder drei Punkte. Das erste Szenario, das wir gefunden haben, sind Arbeitsaufträge , insbesondere der chaotische Prozess in den frühen Phasen der Erstellung einer Arbeitsauftragsgruppe; das zweite Szenario sind Änderungen , insbesondere die schnelle Abgrenzung von Leistungseinbußen nach Änderungen, das dritte Szenario sind Schwachstellen , die wir noch untersuchen Dieses Szenario ist kein Problem, und heute werden wir einige unserer vorläufigen Gedanken mit Ihnen teilen.
Ineffizienz von Arbeitsaufträgen : Nehmen wir zunächst an, dass ein Alarm in Ihrem Unternehmen die Erstellung eines Gruppenchats, beispielsweise einer Feishu-Gruppe, auslöst. Nehmen wir ein typisches Szenario, das wir im Büro eines Kunden sehen: Nachdem die erste Person in die Arbeitsauftragsgruppe aufgenommen wurde, sieht sie sich möglicherweise die Anrufkettenverfolgungsdaten an, führt eine Analyse durch und stellt fest, dass dies nicht ihr Problem ist Die zweite Person trat der Gruppe bei. Diese Person sah sich einige Indikatordaten an und stellte fest, dass dies nicht ihr Problem war. Dann brachte sie eine dritte Person in die Gruppe Ereignisdaten, und nachdem er einige Analysen durchgeführt hatte, stellte er immer noch fest, dass es nicht sein Problem war. Ziehen Sie dann die vierte Person, die fünfte Person usw. heran Wang wurde in die Gruppe aufgenommen und eine tiefergehende und detailliertere Analyse und Zusammenfassung erstellt, damit der Sarg fertiggestellt und die Arbeit erledigt werden konnte. Leiten Sie den Auftrag an die richtige verantwortliche Person, Xiao Li, weiter . Wir stellen oft fest, dass der Prozess sehr verwirrend und ineffizient ist, bevor der Arbeitsauftrag Xiao Li zugeordnet wird, und mehr als eine Stunde dauern kann. Selbst wenn die zu Beginn hinzugezogenen Personen nicht am gesamten Prozess beteiligt sind, wird die Existenz dieser Arbeitsauftragsgruppe von Zeit zu Zeit ihre normale Arbeit unterbrechen, was erhebliche Auswirkungen auf die Effizienz aller im Arbeitsauftrag beteiligten Personen hat Gruppe.
Wie kann ein Observability Agent dieses Problem lösen? Wenn ein Arbeitsauftrag erstellt wird, wird der von einem KI-Agenten gesteuerte Roboter automatisch in die Arbeitsauftragsgruppe gezogen. Der AI-Agent ruft zunächst die DeepFlow-API auf, um Tracking, Indikatoren, Ereignisse, Protokolle und andere Datentypen anzuzeigen, und verwendet eine Reihe statistischer Algorithmen, um die Merkmale der Daten zusammenzufassen (wodurch die Anzahl der Token effektiv reduziert wird). verwendet diese Funktionsinformationen als Aufforderung zum Aufrufen von LLM (Derzeit wird GPT4 hauptsächlich für die Analyse verwendet. Nach der Analyse eines Datentyps nutzt der KI-Agent die Funktionsaufruf- oder JSON-Modus-Funktionen von LLM, um zu entscheiden, welcher oder welche anderen Datentypen analysiert werden müssen. Abschließend fordert der AI-Agent LLM auf, eine Zusammenfassung aller Analyseergebnisse zu erstellen.
In diesem Prozess stellt das eBPF von DeepFlow vollständige Observability-Daten für den gesamten Stapel bereit, und AutoTagging fügt einheitliche, semantisch reichhaltige Beschriftungen in alle Daten ein . Basierend auf den Analyseergebnissen kann der KI-Agent mithilfe von Labels wie label.owner die entsprechende verantwortliche Person genau in die Arbeitsauftragsgruppe ziehen. Obwohl die Genauigkeit der Arbeitsauftragsabgrenzung von AI Agent zu diesem Zeitpunkt noch nicht 100 % erreichen kann, konnte die sehr chaotische Anfangsphase der Arbeitsauftragsgruppe in den meisten Fällen erfolgreich von mehr als einer Stunde auf eine Minute komprimiert werden, und das ist auch der Fall Die Effizienz der Arbeitsauftragsgruppe wurde erheblich verbessert. Die Anzahl der Personen in der Arbeitsauftragsgruppe wurde reduziert, wodurch die Arbeitseffizienz des gesamten Teams erheblich verbessert wurde .
Ineffizienz von Änderungen : Wir haben festgestellt, dass in einer Cloud-nativen Umgebung die Gründe für Leistungseinbußen nach der Veröffentlichung des Dienstes vielfältig sein können und es aufgrund der Komplexität der Anrufkette und des Softwarecode-Stacks manchmal schwierig für die für On Call verantwortlichen Partner ist lokalisieren Die Hauptursache liegt darin, dass es auch aufgrund der Unkenntnis von Inhalten, die über den Rahmen des eigenen Wissens hinausgehen, sehr leicht zu Fehleinschätzungen kommen kann. Wenn ein solches Problem auftritt, besteht die einzige Möglichkeit darin, die Kapazität vorübergehend zu erweitern oder ein Rollback durchzuführen, um den Betrieb wiederherzustellen, und zu warten, bis das Problem behoben ist, bevor die Version erneut veröffentlicht wird. Die Testumgebung ist jedoch möglicherweise nicht in der Lage, die Probleme in der Produktionsumgebung zu reproduzieren. Daher müssen wir eine Reihe von Mechanismen zur Wiedergabe des Datenverkehrs einführen, um die Analyse der Grundursache des Problems zu unterstützen. In diesem Szenario hoffen wir, dass AI Agent Entwicklern dabei helfen kann, die Grundursachen für Leistungseinbußen schnell zu identifizieren und die Version viel früher wieder online zu stellen.
Für Szenarien mit komplexen Anrufketten haben wir am Beispiel des Arbeitsauftragsagenten bereits eine gute Lösung. Für Szenarien mit komplexen Funktionsaufrufstapeln ist dies die Spezialität von eBPF. Es kann Geschäftsfunktionen, Bibliotheksfunktionen, Laufzeitfunktionen und Kernelfunktionsaufrufstapel abrufen, wenn der Prozess ohne Eingriffe ausgeführt wird. Aufgrund der Sicherheit und des geringen Overheads von eBPF kann die Profilerstellung in der Regel über einen bestimmten Zeitraum hinweg aktiviert werden, bevor die Leistung nach der Änderung auf ein unzumutbares Niveau absinkt Daten, um die Ursachenabgrenzung schnell abzuschließen.
Die eBPF-Profiling-Daten decken ein sehr breites Spektrum an Technologie-Stacks ab und es ist für jeden Geschäftsentwickler schwierig, alle Informationen zu verstehen. Genau in diesem Szenario ist AI Agent gut. Wie in der folgenden Abbildung gezeigt, ist LLM normalerweise in der Lage, das Wissen über Kernelfunktionen, Laufzeitfunktionen und grundlegende Bibliotheksfunktionen zu verstehen, sodass die Analyseergebnisse dieser Funktionen direkt angegeben werden können. Auch wenn es Dinge gibt, in denen LLM nicht gut ist, da die Softwareprojekte, in denen sich solche Funktionen befinden, nicht häufig aktualisiert werden und zum Allgemeinwissen gehören, können wir darüber nachdenken, die Teile, die LLM nicht beherrscht, durch Feinabstimmung zu verbessern. Werfen wir einen Blick auf einige häufig verwendete Anwendungsbibliotheksfunktionen wie Pythons Requests usw. Diese Bibliotheken zeichnen sich durch eine große Anzahl, schnelle Iteration und eine umfangreiche Schnittstellendokumentation aus. Wir können darüber nachdenken, die Dokumentation solcher Funktionen zu vektorisieren und den RAG-Mechanismus zu verwenden Verbesserung der LLM-Analyse. Weiter oben sind die internen Geschäftscodes des Unternehmens nicht allgemein bekannt, sie sind in größerer Menge vorhanden und ändern sich schneller. Daher können wir sie direkt an LLM weiterleiten commit_id-Label in K8s. Mit der AutoTagging-Funktion von DeepFlow kann der AI-Agent den Datensatz der letzten Codeänderung problemlos über commit_id lokalisieren und LLM benachrichtigen. Es ist ersichtlich, dass durch den kombinierten Einsatz von LLM-, Fine-Tuning-, RAG- und Prompt-Engineering-Technologie alle Berufsfelder, die an eBPF-Full-Stack-Profiling-Daten beteiligt sind, vollständig abgedeckt werden können, was Entwicklern dabei hilft, die Grundursachen schnell zu identifizieren .
Ineffizienz von Schwachstellen : In einem Bericht heißt es: „Die Behebung von Schwachstellen kann zu 76 % nutzlos sein, und nur 3 % der Schwachstellen sollte vorrangige Aufmerksamkeit geschenkt werden.“ DeepFlow untersucht derzeit noch, wie AI Agent verwendet werden kann, um die Effizienz in diesem Link zu verbessern. Sicher ist, dass eBPF eine hervorragende Datenerfassungstechnologie für Cloud Workload Security ist. Isovalent fasst die vier goldenen Beobachtungssignale der Sicherheit zusammen: Prozessausführung, Netzwerk-Socket, Dateizugriff und Layer-7-Netzwerkidentität . DeepFlow deckt diese vier Signale derzeit teilweise ab und wird sie in Zukunft weiter ausbauen. Ich glaube, dass wir mit der Vervollständigung dieser Daten in Kombination mit LLM in der Lage sein werden, einen sehr auffälligen KI-Agenten für die Sicherheitsszene zu schaffen.
Lassen Sie uns am Ende dieses Teils darüber sprechen, wie Sie AI Agent kontinuierlich verbessern können. Am Beispiel des Arbeitsauftragsszenarios verwenden wir Chaos Engineering in der Testumgebung, um eine große Menge abnormaler Daten zu erstellen. Da wir die richtigen Grundursachen dieser Anomalien kennen, können sie zur Bewertung der KI-Agenl verwendet werden und kontinuierlich verbessern. In der Produktionsumgebung (Hinweis: Die rechte Seite des PPT sollte die Produktionsumgebung sein) haben wir einen Mechanismus hinzugefügt, mit dem Benutzer Punkte erzielen können, und Agent-Entwickler werden basierend auf den Bewertungen Verbesserungen vornehmen.
03
Praxisbeispiele für Observability-Agenten für DeepFlow-Benutzer
Wie sieht der KI-Agent von DeepFlow jetzt aus? Lassen Sie uns eine kurze Einführung in diesen Teil geben. Derzeit kann der AI-Agent auf der Seite der DeepFlow Enterprise Edition über die Seiten Topologiekarte, Anrufkettenverfolgung und kontinuierliche Analyse aufgerufen werden. Gleichzeitig kann die API des Agenten auch von Feishu ChatBot aufgerufen werden, um die Funktion zu implementieren eines Arbeitsauftragsexperten. Nachdem der KI-Agent die erste Runde der Zusammenfassung gegeben hat, stellt er auch etwa drei oder vier Fragen bereit, die Sie möglicherweise weiter stellen. Sie können direkt auf diese Fragen klicken, um das Gespräch fortzusetzen. Selbstverständlich können Nutzer auch direkt eigene Fragen zum Dialog eingeben.
Darüber hinaus wurde heute auch die AI-Agent-Funktion in der DeepFlow Community Edition veröffentlicht und ist derzeit in der Lage, die aktuellen Grafana-Panel-Daten zu analysieren. Derzeit unterstützen wir zwei Panels, Topo und Tracing, und sind an vier große Modelle angepasst: GPT, Tongyi Qianwen, Wenxinyiyan und ChatGLM. Sie können es gerne herunterladen und ausprobieren.
04
Gedanken zu zukünftigen Entwicklungsrichtungen
Lassen Sie mich abschließend die zukünftige Entwicklungsrichtung des DeepFlow AI Agent erläutern.
Jetzt kann eBPF Cloud-Anwendungen vollständig abdecken. Als Nächstes werden wir seine Fähigkeiten auf die Endseite erweitern, einschließlich autonomem Fahren und Smart-Space-Domain-Steuerung bei Smart Cars sowie einigen Smartphone-Szenarien, in denen Berechtigungen zulässig sind.
Andererseits haben wir auch festgestellt, dass RAG viel Raum für Optimierung bietet. Hier ist eine Rezension von RAG: Retrieval-Augmented Generation for Large Language Models: Eine Umfrage . Wir hoffen, dass sie für alle hilfreich sein wird.
05
Was ist DeepFlow?
DeepFlow ist ein von Yunshan Network entwickeltes Observability- Produkt mit dem Ziel, eine umfassende Observability für komplexe Cloud-Infrastrukturen und Cloud-native Anwendungen bereitzustellen. Basierend auf eBPF realisiert DeepFlow eine Zero-Intrusion ( Zero Code)-Erfassung von Beobachtungssignalen wie Anwendungsleistungsindikatoren, verteilter Ablaufverfolgung und kontinuierlicher Leistungsanalyse und kombiniert sie mit der Smart Label ( SmartEncoding)-Technologie, um eine vollständige Stack ( Full Stack)-Korrelation und einen effizienten Zugriff auf alle zu erreichen Beobachtungssignale. Mithilfe von DeepFlow können Cloud-native Anwendungen automatisch über eine umfassende Beobachtbarkeit verfügen, wodurch die schwere Last der kontinuierlichen Instrumentierung für Entwickler entfällt und DevOps/SRE-Teams Überwachungs- und Diagnosefunktionen vom Code bis zur Infrastruktur erhalten.
GitHub-Adresse: https://github.com/deepflowio/deepflow
Besuchen Sie die DeepFlow-Demo und erleben Sie null Instrumentierung, vollständige Abdeckung und vollständig relevante Beobachtbarkeit.
Veranstaltungsvorschau |. Observability Open Source Developer Meetup „Intelligente Observability: Observable Evolution angetrieben durch große Modelle“