Bauen Sie die nächste Generation intelligenter beobachtbarer Systeme auf Basis von eBPF

[Live-Übertragungsvorschau] Wie weit müssen wir gehen, um Oracle zu ersetzen?

Dieser Artikel basiert auf den Beiträgen zur KubeCon China 2023. Das Thema, das wir heute teilen, ist der Aufbau der nächsten Generation intelligenter beobachtbarer Systeme auf Basis von eBPF.

Bevor wir beginnen, möchte ich uns kurz vorstellen. Mein Name ist Liu Kai, mein Spitzname ist Qian Lu und ich bin derzeit der Verantwortliche für das Überwachungsunterprodukt ARMS K8s von Alibaba Cloud. Dies ist mein Kollege Dr. Dong Shandong mit dem Spitznamen Fanden. Er ist der Verantwortliche für den AIOps-Bereich des ARMS-Produkts von Alibaba Cloud.

Beobachtbarkeitsherausforderungen in K8s

Diese gemeinsame Nutzung gliedert sich im Wesentlichen in drei Teile. Schauen wir uns zunächst den ersten Teil an, die Beobachtbarkeitsherausforderungen in K8s.

Mit dem Aufkommen von Konzepten wie Cloud Native, K8s und Microservices haben unsere Anwendungen viele Veränderungen erfahren, wie zum Beispiel Microservices, Containerisierung usw. Dann wird sich alles in Richtung eines einheitlichen Standards entwickeln, was uns viele Vorteile bringen wird. Zum Beispiel extreme Flexibilität, effizienter Betrieb und Wartung, Standard-Laufzeitumgebung usw. Aber gleichzeitig bringt K8s auch viele Probleme für Entwickler mit sich.

Wir haben mehr als 1.000 Arbeitsaufträge in K8s in der öffentlichen Cloud gesammelt. Auf welche Probleme sind Entwickler tatsächlich gestoßen, nachdem sie ihre Infrastruktur auf K8s migriert haben?

Durch die Analyse der Arbeitsaufträge können wir drei große Herausforderungen analysieren:

Erstens sind die Infrastrukturprobleme von K8 nicht optimistisch. Aus dem statistischen Diagramm können wir ersehen, dass netzwerkbezogene Probleme mehr als 56 % ausmachen. Wenn Entwickler also auf diese Probleme stoßen, müssen wir als beobachtbares System welche Daten sammeln ? Wie Können wir den Grund für die Ausnahme beantworten?
Zweitens müssen wir, da ein großer Teil der Komplexität der Anwendung auf die Infrastruktur übertragen wurde, nicht nur Indikatoren der Anwendungsschicht, sondern auch Container-, Netzwerk- und andere Beobachtungsdaten sammeln. Wie können wir das in K8s elegant tun? sammeln Was ist mit diesen Daten?
Drittens: Wie sollten wir diese Daten verwenden, nachdem wir so viele Daten gesammelt haben, um Entwicklern bei der Behebung von Problemen zu helfen?

Datenerfassungslösung in K8s

Okay, lassen Sie uns diese drei Fragen beantworten und mit dem folgenden Inhalt fortfahren: der Datenerfassungslösung in K8s.

Im Allgemeinen können K8s-Anwendungen in viele Schichten unterteilt werden. Die oberste Schicht ist die Geschäftsschicht, einschließlich einiger unserer Front-End-Seiten und Applets; die Anwendungsschicht ist der Maßstab für unsere Back-End-Anwendungen; die Container-Schicht kann viele Arten von Laufzeiten haben, wie zum Beispiel Containerd, Docker usw. ; Die Infrastrukturschicht umfasst K8s. Also ist es hier drüben? Nicht wirklich. Da die Komplexität von K8s-Anwendungen ständig abnimmt, müssen wir oft noch tiefer in die Materie eintauchen. Dabei kann es sich um Netzwerk-Plug-ins, einen Linux-Kernel oder sogar einige Hardwaretreiber handeln. An dieser Stelle können wir die erste zuvor genannte Frage beantworten. Welche Daten benötigen wir in K8s? Die Antwort liegt in allen Daten, die wir sehen können. Ein Fehler auf irgendeiner Ebene kann zu Anomalien in unserem Gesamtsystem führen.

Als Nächstes gehen wir der zweiten Frage nach, nämlich wie wir diese Daten erfassen.

Tatsächlich verfügt unser beobachtbares Feld derzeit über viele unabhängige Lösungen auf jeder Ebene. Auf der Geschäftsebene gibt es beispielsweise Lösungen wie Einwahltests, Front-End-Überwachung und Geschäftsprotokollanalyse; auf der Anwendungsebene gibt es APM-Systeme wie Opentelemetry und Jaeger; auf der Containerebene und der Infrastrukturebene Es gibt Prometheus und verschiedene Exporters-Beobachtungslösungen. Aber wenn er tiefer geht, werden diese traditionellen beobachtbaren Systeme selten behandelt. Dies führt zum Problem der blinden Beobachtungsflecken. Darüber hinaus verfügen viele Schichten zwar über eigene Beobachtungspläne, ihre Daten sind jedoch nicht korreliert. Sie sind relativ unabhängig voneinander und es gibt keine einheitliche Korrelationsdimension, die die Daten auf jeder Ebene integrieren kann, sodass ein Dateninselphänomen vorliegt.

Gibt es also eine Möglichkeit, diese Probleme zu lösen?

Die Antwort ist die eBPF-Technologie. Lassen Sie mich zunächst kurz die eBPF-Technologie vorstellen. eBPF ist eine virtuelle Maschine, die im Linux-Kernel läuft. Sie stellt einen speziellen Befehlssatz bereit und ermöglicht es uns, benutzerdefinierte Logik zu laden, ohne den Kernel neu zu kompilieren oder die Anwendung neu zu starten.

Dieses Diagramm zeigt den grundlegenden Ablauf der Verwendung von eBPF. Wir müssen einen Teil des eBPF-Codes schreiben und ihn dann mit dem Kompilierungstool in Bytecode kompilieren. Dann können wir diesen Bytecode über den BPF-Systemaufruf am angegebenen Mountpunkt mounten. Der Mount-Punkt kann ein Systemaufruf, eine Kernel-Methode oder sogar ein User-Space-Geschäftscode sein. In der unteren rechten Ecke können wir beispielsweise den eBPF-Bytecode dynamisch an den Eingabe- und Rückgabepositionen der hello_world-Methode bereitstellen und die Laufzeitinformationen der Methode über den eBPF-Befehlssatz sammeln.

Die eBPF-Technologie weist drei Hauptmerkmale auf: Erstens ist sie nicht aufdringlich, wird dynamisch bereitgestellt und der Zielprozess muss nicht neu gestartet werden. Zweitens ist sie hochleistungsfähig. Der eBPF-Bytecode wird in Maschinencode eingefügt und dann ausgeführt sehr effizient; drittens ist es sicherer, es läuft in seiner eigenen Sandbox und führt nicht zum Absturz des Zielprozesses. Es verfügt außerdem über eine strenge Verifizierungsprüfung beim Laden, die sicherstellt, dass der von uns hinzugefügte Code normal ist und dies auch der Fall sein wird Keine Endlosschleife oder illegaler Zugriff. Speicher- und andere Probleme.

In dieser Tabelle werden die Unterschiede zwischen eBPF und herkömmlichen APM-Sonden verglichen. Die eBPF-Technologie bietet offensichtliche Vorteile in Bezug auf Abdeckung, Eindringlichkeit, Leistung und Sicherheit.

Wie können wir Daten basierend auf eBPF sammeln? Die erste Fähigkeit, die wir aufgebaut haben, war Architekturbewusstsein. Das Architekturbewusstsein kann die Anwendungsarchitektur, den Betriebsstatus und den Netzwerkfluss des Clusters automatisch analysieren.

Die Kommunikation zwischen K8s-Mikrodiensten auf Kernelebene ist der Paketsende- und -empfangsprozess des Linux-Netzwerkprotokollstapels. Ich werde die UDP-Paketsammlung als Beispiel nehmen, um den Paketsammlungsprozess kurz vorzustellen. Beginnend in der oberen linken Ecke wird ein Soft-Interrupt ausgelöst, wenn das Datenpaket die Netzwerkkarte erreicht. Do_softirq verarbeitet den Soft-Interrupt und gibt die Methode net_rx_action ein. Diese Methode fragt die Datenpakete auf der Netzwerkkarte aktiv über das Netzwerk ab Kartentreiber.

Nachdem das Datenpaket empfangen wurde, wird es an den Netzwerkprotokollstapel übermittelt. Dies ist eine sehr wichtige Methode, netif_receive_skb, und viele Paketerfassungstools funktionieren auch an dieser Stelle. Diese Methode stellt es in die SKB-Empfangswarteschlange des Benutzerprozesses ein, nachdem je nach Paketprotokoll eine andere Paketverarbeitungslogik verwendet wurde, z. B. ARP oder IP, TCP oder UDP. Wenn unser Benutzerprozess recvfrom syscall aufruft, um die Paketsammlung zu initiieren, liest er die Pakete in der SKB-Warteschlange in den Benutzerbereich.

Lassen Sie uns auf dieser theoretischen Grundlage einen Blick auf das Architekturbewusstsein werfen. Was es tatsächlich tut, ist die Erkennung des Netzwerkflusses und der Netzwerkqualität. Daher können wir einige wichtige Kernel-Methoden im Sende- und Empfangspfad von Linux-Paketen beobachten, um diese Ziele zu erreichen.

In dieser Tabelle habe ich einige Beobachtungspunkte aufgelistet, wie z. B. netif_receive_skb und dev_queue_xmit, die die Häufigkeit, Größe und Netzwerkflussrichtung gesendeter und empfangener Datenpakete zählen können. Methoden wie tcp_drop/tcp_retransmit_skb werden verwendet, um Paketverluste zu beobachten und Neuübertragung, mit der die Netzwerkqualität gemessen werden kann.

Diese Seite ist eine Zielseite für das Architekturbewusstsein unserer Produkte. Auf diesem Bild können wir die Clusterübersicht, den Netzwerkfluss, Topologieinformationen und den Status jedes Knotens klar erkennen. Daraus können wir erkennen, dass die beiden Knoten oben gelb markiert sind und dann orange werden. Das bedeutet, dass ein Problem mit dem Netzwerkstatus dieser beiden Knoten vorliegt. Man kann sagen, dass der Paketverlust zunehmen wird oder dass die Neuübertragungen zunehmen werden. Aber was für ein Phänomen wird es letztendlich auf der Anwendungsebene widerspiegeln?

Als nächstes folgt die zweite von uns entwickelte Funktion, bei der es sich um eine Beobachtung der Anwendungsleistung handelt. Tatsächlich geht es bei unserer aktuellen Architekturwahrnehmung eher darum, den Zustand dieser Infrastruktur auf der Transportschicht zu messen. Tatsächlich würden wir in unseren täglichen Entwicklungsprozessen lieber einige Informationen auf der Anwendungsebene sehen. Zum Beispiel, ob die 4XX- und 5XX-Fehler unseres HTTP-Dienstes zugenommen haben und ob sich die Verarbeitungsverzögerung erhöht hat usw.

Wie kann man also die Anwendungsschicht beobachten? Lassen Sie uns zunächst den Aufrufprozess zwischen K8s-Anwendungen analysieren. Normalerweise ruft unsere Anwendung die RPC-Bibliothek eines Drittanbieters auf, und dann ruft die Bibliothek eines Drittanbieters den Systemaufruf auf. Als nächstes durchläuft sie im Kernel die Transportschicht Netzwerkschicht und senden Sie es schließlich über den Netzwerkkartentreiber aus.

Daher sind herkömmliche beobachtbare Sonden normalerweise in der RPC-Bibliothek vergraben. Diese Ebene wird von der Programmiersprache und dem Kommunikations-Framework beeinflusst.

eBPF kann auch denselben Mount-Punkt wie herkömmliches APM wählen und Daten über uprobe in der RPC-Bibliothek sammeln. Da eBPF jedoch viele Montagepunkte hat, können wir auch die vergrabenen Punkte wie die Systemaufrufschicht, die IP-Schicht und die Netzwerkkartentreiberschicht senken. Dann können wir die sendenden und empfangenden Byteströme des Netzwerks abfangen und dann die Protokollanalyse durchführen um Netzwerkanfragen und -antworten zu analysieren, um Dienstleistungsdaten zu erhalten. Dies hat den Vorteil, dass der Netzwerk-Bytestrom von der Programmiersprache entkoppelt ist und wir uns nicht an die Implementierung verschiedener Sprachen und Frameworks für jedes RPC-Protokoll anpassen müssen, was die Komplexität der Entwicklung erheblich reduziert.

In dieser Tabelle werden die Vor- und Nachteile verschiedener Montageorte verglichen. Es ist ersichtlich, dass es eine relativ bessere Lösung ist, den Punkt im Systemaufruf zu vergraben. Da Syscall über Prozessinformationen verfügt, ist es für uns praktisch, die Metadaten einiger Container nach oben zu verknüpfen. Der Mountpunkt von Syscall ist stabil und der Overhead ist sehr gering.

Nachdem ich bestätigt habe, dass der Montageort ein Systemaufruf ist, möchte ich kurz das Prinzip der Analyse der Serviceleistung vorstellen.

Am Beispiel des Linux-Systems können die Systemaufrufe zum Lesen und Schreiben von Daten aufgezählt werden, z. B. Lesen, Schreiben, Senden an, Recvfrom usw. Daher entscheiden wir uns, den eBPF-Bytecode in diese Systemaufrufe einzubinden, damit wir ihn intuitiv abrufen können die gelesenen Daten. Geschriebene Daten der Anwendungsschicht. Wenn wir beispielsweise einen HTTP-Dienst beobachten, haben wir die Empfangsdaten des obigen Beispiels über den Lesepunkt und die Sendedaten des folgenden Beispiels über den Schreibpunkt erfasst.

Anschließend gelangen die Sende- und Empfangsdaten jeweils in den Protokollparser. Der Protokollparser analysiert die Daten gemäß den Anwendungsprotokollstandards. Beispielsweise legt das HTTP-Protokoll fest, dass in der Anforderungszeile das Format der ersten Zeile „Methode“, „Pfad“ und „Version“ und das Format der ersten Zeile der Antwort „Version“, „StatusCode“ und „Nachricht“ lautet, sodass wir das extrahieren können Die Methode dieser HTTP-Anfrage ist Get und der Pfad ist /index.html, der Rückgabestatuscode ist 200. Darüber hinaus können wir basierend auf dem Zeitpunkt, zu dem Lese- und Schreibvorgänge ausgelöst werden, die Verarbeitungsverzögerung vom Server, der die Anfrage empfängt, bis zur Rückgabe der Antwort berechnen.

Nachdem wir diese Schlüsselinformationen extrahiert haben, können wir die Servicedaten nach einigen Aggregationsverarbeitungsprozessen auf die beobachtbare Plattform exportieren.

Dieses Bild ist eine Landingpage unseres Produkts zur Beobachtung der Anwendungsleistung. Aus diesem Bild können wir deutlich erkennen, dass wir über eBPF drei goldene Indikatoren des HTTP-Serverdienstes ohne Eingriff beobachten können, nämlich die Anzahl der Anfragen, die Anzahl der Fehler und die durchschnittliche Verzögerung. Auch hier sieht man einige Probleme, das heißt, die Anzahl der Anfragen ist gesunken. Warum ist es zurückgegangen? Dies kann auf eine Anomalie zurückzuführen sein, aber in diesem Bild können wir den Grund nicht finden.

Das Dritte, was wir tun müssen, ist die Korrelation mehrdimensionaler Daten. Wie bereits erwähnt, haben wir tatsächlich für jede Ebene in K8s-Anwendungen entsprechende Lösungen. Aber sie haben keine Möglichkeit, sich miteinander zu integrieren. Die hier erwähnte Integration bedeutet, dass ihnen eine einheitliche Korrelationsdimension fehlt. Einige unserer Beobachtungsdaten für Container umfassen beispielsweise normalerweise die Dimension der Container-ID. Zum Beispiel die CPU-/Speicherauslastung des Containers. Für die Beobachtung der K8-Ressourcen haben sie dann alle die Dimension der K8-Entität, z. B. welcher Pod und welche Bereitstellung. Für die Anwendungsleistungsüberwachung beispielsweise enthalten einige unserer traditionellen APM-Plattformen normalerweise Dimensionen wie ServiceName oder Trace-ID. Daher verfügen sie nicht über eine einheitliche Korrelationsdimension, sodass es keine Möglichkeit gibt, die Beobachtungsdaten zusammenzuführen.

Wie integriert man diese Daten? eBPF ist ein sehr guter Hub, da es im Kernel-Modus läuft und einige zusätzliche Informationen sammeln kann. Um einige Beispiele zu nennen, nehmen wir zunächst die Mount-Punkte einiger Prozessklassen. Dann kann eBPF beim Mounten einige seiner Prozessnummern, den PID-Namespace und andere Informationen sammeln. Wenn diese Informationen zu einer Laufzeit des Containers kombiniert werden, können wir seine Container-ID leicht analysieren. Auf diese Weise können wir die Integration mit Containerdaten abschließen.

Ein weiteres Beispiel sind einige netzwerkbezogene Mountpunkte. Wir können das Triplett von skb über eBPF sammeln, das die Adresse des anfordernden Endes, die Adresse des Peers und seinen Netzwerk-Namespace ist. Wir verwenden diese Adressinformationen, um den K8s-API-Server zu überprüfen und festzustellen, zu welcher K8s-Entität er gehört. Damit ist die Integration der K8s-Ressourcen abgeschlossen.

Schließlich gibt es Daten zur Überwachung der Anwendungsleistung. Im Allgemeinen überträgt das APM-System Trace-Kontext wie Servicename und Trace-ID in bestimmten Feldern im Protokoll der Anwendungsschicht. Wenn wir dann die Protokollanalyse in eBPF durchführen, können wir diese Daten zusätzlich analysieren und dann diese Assoziationsebene vervollständigen. Beispielsweise überträgt das HTTP-Protokoll Trace-Kontextinformationen über Header.

Okay, die nächsten Daten sind einige Implementierungen unserer Produkte. Auf diesem Bild kann ich eine Verschmelzung von Architekturbewusstsein und Anwendungsschichtdaten erkennen.

Dann zeigt dieses Bild eine Fusion von K8-Ressourcen und Container-Beobachtungsdaten.

Im obigen Inhalt habe ich hauptsächlich die beiden Hauptthemen vorgestellt, die wir zuvor erwähnt haben: welche Daten wir sammeln müssen und wie wir diese Daten sammeln. Wie können diese Daten nach Erhalt zur Fehlerlokalisierung genutzt werden? Als nächstes wird mein Kollege Dr. Dong Shandong weiterhin mit Ihnen teilen.

Praxis zur Fehlerlokalisierung in K8s

Guten Tag allerseits, ich bin Dong Shandong. Vielen Dank, Qianlu, für Ihre Einführung und den Austausch gerade jetzt. Qian Lu gab uns eine detaillierte Einführung in die Beobachtbarkeitsherausforderungen in K8s und stellte die Methode zur Verwendung der eBPF-Technologie zur Datenerfassung und -korrelation vor. Als Nächstes möchte ich Sie gerne mit der Praxis der Fehlerortung in K8 vertraut machen.

Schauen wir uns zunächst einen Weg zur manuellen Fehlerbehebung bei der ARMS K8s-Überwachung an. Angenommen, es liegt ein langsamer Netzwerkanruffehler zwischen dem Gateway und dem Produktdienst vor. Wie erkennen und beheben Menschen zu diesem Zeitpunkt normalerweise Fehler? Zunächst stellen wir Alarme für Eingangsanwendungen und Schlüsselanwendungen ein, beispielsweise Alarme für die drei goldenen Indikatoren der Anwendung: RT (durchschnittliche Antwortzeit), Fehlerrate (Fehlerrate) und Anforderungsvolumen (QPS). Wenn wir einen Alarm erhalten, können wir erkennen, dass in der Gateway-Anwendung etwas nicht normal ist. Aber woher wissen wir, wo das Problem verursacht wird? Liegt es an einem Downstream-Knoten oder an einem Netzwerkproblem?

Das erste, worauf wir achten müssen, ist der Gateway-Dienstknoten im Topologiediagramm links. Es lässt sich feststellen, dass beim Goldindikator RT einen plötzlichen Anstieg aufweist und es auch langsame Anrufindikatoren gibt.

Klicken Sie entlang dieses Topologiediagramms auf die Downstream-Knoten des Gateways, einschließlich Warenkorbservice, Nacos und Produktservice. Es wurde festgestellt, dass nur der goldene Indikator des Produktservices dem Gateway-Indikator des Eingangs ähnelt. Es kann zunächst festgestellt werden, dass der Fehler möglicherweise auf der Verbindung vom Gateway zum Produktservice auftritt. Als nächstes können wir die Aktion gerade wiederholen und die Downstream-Knoten des Produktdienstes weiter analysieren. Wir können feststellen, dass alle Downstream-Knoten normal sind.

Abschließend können wir bestätigen, ob beim Netzwerkanruf vom Gateway zum Produktservice ein Problem vorliegt. Klicken Sie auf die gepunktete Linie in der Abbildung (die Netzwerkanrufkante vom Gateway zum Produktdienst), um die Netzwerkanrufindikatoren anzuzeigen, z. B. die Anzahl der Paketneuübertragungen und die durchschnittliche RT. Es wurde festgestellt, dass auch diese beiden Indikatoren einen ähnlichen plötzlichen Anstieg verzeichneten.

Zusammenfassend kann anhand des manuellen Durchlaufs und der Analyse der Topologiekarte zunächst festgestellt werden, dass der Fehler auf der Verbindung vom Gateway zum Produktdienst aufgetreten ist. Dies hängt auch mit den beiden Indikatoren für Netzwerkaufrufe zusammen, und das ist auch der Fall höchstwahrscheinlich ein Netzwerkproblem.

Der manuelle Untersuchungspfad hat für uns einen großen Referenzwert für eine intelligente Ursachenpositionierung. Der intuitive Gedanke ist, dass wir den oben genannten Prozess direkt automatisieren sollten.

Sie können zunächst die eigenen Serviceindikatoren des Gateways überprüfen und feststellen, dass RT unter den drei goldenen Indikatoren einen ungewöhnlich plötzlichen Anstieg aufweist, während seine Ressourcenindikatoren wie CPU-, Speicher- und Festplattennutzung normal sind. Dies weist auf ein Problem mit Ihren Servicemetriken hin.

Dann können wir die entsprechenden Downstream-Knoten über die topologische Beziehung erhalten. Die Idee ähnelt der Überprüfung des Gateways: Überprüfen Sie, ob die drei goldenen Serviceindikatoren und Ressourcenindikatoren aller Downstream-Knoten Auffälligkeiten aufweisen. Es wurde festgestellt, dass nur der Produktservice im Downstream-Knoten abnormal ist. Obwohl auch die Fehlerrate von Clothservice negativ korreliert, ist der Rückgang der Fehlerrate aus geschäftlicher Sicht nicht ungewöhnlich und kann aufgrund der Geschäftssemantik ausgeschlossen werden.

Schließlich können Sie überprüfen, ob es Probleme mit den Netzwerkanrufen des Dienstes gibt. Es wurde festgestellt, dass es ähnliche Anomalien bei den Netzwerkindikatoren des Gateway-Calling-Produktdienstes gab. Zu diesem Zeitpunkt haben wir den Prozess der manuellen Analyse tatsächlich automatisiert.

Darüber hinaus können wir die Protokolle analysieren. Beispiel: Wir können eine Mustererkennung für Fehlerdienstknotenprotokolle durchführen, indem wir Protokollvorlagen extrahieren. Es kann festgestellt werden, dass beim Anpassen der Produktserviceschnittstelle das Timeout-Fehlerprotokoll angezeigt wird und die Anzahl 24 beträgt. Nach der Zusammenfassung wichtiger Fehlerprotokolle werden der automatisierte Analyseprozess und die Ergebnisse sowie Informationen und Zeiten der Fehlerprotokollvorlage als Inspektionsberichte ausgegeben und an Betriebs- und Wartungsexperten gesendet. Auf Basis dieser Informationen implementieren Experten eine intelligente unterstützte Ortung.

Ist die Geschichte also hier zu Ende?

Schauen wir uns jetzt den gesamten Prozess an und stellen fest, dass es sich tatsächlich nur um einen abnormalen Scan des gesamten Systems handelt. Wir sammeln alle abnormalen Informationen und stellen sie den Betriebs- und Wartungsexperten zur Verfügung. Können wir also noch weiter gehen und direkt die Schlussfolgerung zur Grundursache ableiten? Das ist der erste Gedanke.

Der zweite Gedanke ist, dass das gesamte Methodensystem im K8s-Überwachungsszenario angewendet wird. Können wir es auf Anwendungsüberwachung, Front-End-Überwachung, Geschäftsüberwachung und sogar Infrastrukturüberwachung ausweiten? Kann es mit demselben Algorithmusmodell in verschiedenen Überwachungsszenarien implementiert werden?

Nach der Zusammenfassung geben wir als Antwort die drei Schritte auf der linken Seite: Dimensionszuordnung, Anomalieabgrenzung und FTA (Fehlerbaumanalyse). Schauen wir uns diese drei Kernschritte im Detail an.

Die erste ist die dimensionale Drilldown-Analyse. Warum also eine dimensionale Drilldown-Analyse?

Vom Gateway wissen wir nur, dass es drei Downstream-Knoten gibt, und dann müssen wir die drei Downstream-Knoten durchqueren und anzeigen. Wenn wir über eine dimensionale Zuordnung verfügen, können wir tatsächlich direkt anhand der Gateway-Indikatoren analysieren, dass es Probleme mit dem nachgelagerten Produktservice gibt.

Werfen wir einen Blick auf die in der Branche gängigen Dimensions-Drilldown-Methoden: Nachdem im Gesamtindikator eine Anomalie aufgetreten ist, möchte das Ziel wissen, welche Dimensionen den abnormalen Teil verursacht haben. Denn der Gesamtindikator setzt sich aus jeder Dimensionswertgruppe zusammen. Nehmen Sie zum Beispiel den Gesamtfehlerratenindikator, dessen Dimensionen Service, Region und Host umfassen. In jeder Dimension gibt es mehrere Werte. Beispielsweise gibt es unter der Region Peking, Shanghai und Hangzhou.

Wenn bei den Gesamtindikatoren eine Anomalie festgestellt wird, wird eine Drilldown-Analyse jeder Dimension durchgeführt, um festzustellen, durch welche Dimension und welchen Wert die Anomalie verursacht wird. Bei der Analyse jeder Dimension wurde festgestellt, dass in einigen Dimensionen (z. B. Region) jeder Wert abnormal war, während in einigen Dimensionen (Host, Service) nur einige Werte abnormal waren. Wir müssen dieser Dimension mehr Aufmerksamkeit schenken, da nur einige der Werte abnormal sind. Durch eindimensionale Drilldown-Positionierung können wir erkennen, welche Werte in jeder Dimension abnormal sind.

Dann können wir abnormale Dimensionen und Werte kombinieren, um von der eindimensionalen Analyse zur kombinierten Dimensionsanalyse zu gelangen. Beispielsweise wurde festgestellt, dass sich der Wert von Host und der Wert von Service überschneiden, dh der abnormale Wert ist sowohl Host1 als auch Service1. Anschließend können Sie zusammenführen, um die Dimension der Grundursachenkombination zu ermitteln: Host1 und Service1.

Zusammenfassend lässt sich sagen, dass wir durch eindimensionale Drilldown-Analyse und kombinierte Dimensionsanalyse die spezifischen Dimensionen und Werte finden können, die zu Gesamtindikatoranomalien führen, und den Umfang des Fehlers schnell eingrenzen können.

In der Microservice-Topologie verfügen Knoten über mehrschichtige Aufrufbeziehungen. Bei der einstufigen dimensionalen Attribution müssen Sie auch wissen, in welche Richtung die dimensionale Attribution erfolgen soll.

In der K8s-Umgebung ist die Gesamttopologie relativ komplex und kann Anwendungstopologie und Ressourcentopologie umfassen. Dann haben wir die Topologie des gesamten Microservices vereinfacht. Man kann sich einfach vorstellen, dass das Topologiediagramm nur zwei Arten von Knoten hat, einer wird als Serviceknoten und der andere als Maschinenknoten bezeichnet. Nach der Vereinfachung der Knoten werden die entsprechenden Beziehungen unterteilt in: die aufrufende und aufgerufene Beziehung zwischen Diensten und die abhängige und abhängige Beziehung zwischen Diensten und Maschinen. Durch eine solche Kombination haben wir ein Microservice-Topologiediagramm, das chaotisch und scheinbar unmöglich zu starten war, in ein Diagramm umgewandelt, in dem wir von jedem Knoten aus eine horizontale und vertikale Drilldown-Analyse durchführen können.

Nehmen wir den Fehler gerade als Beispiel und gehen davon aus, dass das Gateway der abnormale Zieldienst ist. Ausgehend davon können Sie eine horizontale Dimensionsattribution durchführen und eine Drill-Down-Analyse von Anrufen durchführen. In vertikaler Richtung handelt es sich hauptsächlich um eine Beziehung der Ressourcenabhängigkeit. Führen Sie eine Drilldown-Analyse entlang der Ressourcenebene durch, um zu überprüfen, ob abnormale Maschinen-IPs vorhanden sind. Der letzte Schritt besteht darin, festzustellen, ob ein Problem mit der Netzwerkkommunikation des Netzwerk-Edge-Dienstes vorliegt, auf den sie angewiesen sind.

Durch horizontale Attribution, vertikale Attribution und Netzwerkkommunikationsattribution kann die Ursachenanalyse hierarchischer und logischer umgesetzt werden. In Kombination mit der schichtweisen Service-Topologieanalyse können wir alle abnormalen Knoten in der gesamten Kette analysieren.

Der letzte Schritt ist die Fehlerbaumanalysemethode. Nachdem wir den abnormalen Knoten oder die abnormale Netzwerkkommunikation lokalisiert haben, wissen wir, auf welchen Verbindungen das Problem aufgetreten ist. Aber um welche Art von Problem handelt es sich konkret, beispielsweise um ein Problem mit langsamen Anrufen im Netzwerk? Oder handelt es sich um ein Ressourcen-CPU-Problem?

Hier gibt es normalerweise mehrere Lösungen. Eine besteht darin, ein überwachtes Modell zur Implementierung der Fehlerklassifizierung zu erstellen. Diese Lösung stellt jedoch hohe Anforderungen an gekennzeichnete Datensätze und das Modell weist eine schlechte Generalisierung und Interpretierbarkeit auf. Die zweite Methode ist die Fehlerbaumanalysemethode. Lass uns genauer hinschauen:

Zunächst müssen wir unsere Erfahrungen bei der Fehlerbehebung und Governance von Microservices in einem FTA-Baum organisieren und zusammenfassen. Mit dem FTA-Baum können nach der Lokalisierung bestimmter Knoten und Kanten bedingte Beurteilungen ähnlich wie bei Entscheidungsbäumen getroffen werden, um Fehler zu klassifizieren. Beispielsweise wurde festgestellt, dass ein Problem mit der Verbindung des Gateway-Produktdienstknotens vorliegt. Wir können prüfen, ob das Gateway Downstream-Dienstabhängigkeiten aufweist, ob Fehler vorliegen oder der Downstream langsam ist und ob es Probleme mit seinen Netzwerkindikatoren gibt. Wenn alle drei Bedingungen erfüllt sind, handelt es sich um ein Netzwerkproblem.

Auf diese Weise wird ein logischeres und besser interpretierbares Fehlerklassifizierungsmodell erreicht.

Schließlich haben wir das Drei-Kern-Schritte-Modell der Ursachenlokalisierung in das Ursachenanalyseprodukt Insights integriert, wie in der Abbildung oben dargestellt, die die von Insights analysierte Liste abnormaler Ereignisse und den Ursachenbericht zeigt. Insights bietet zwei Kernseiten: die Seite mit der Ereignisliste für Ereignisanomalien und die Seite mit dem Bericht zur Ursachenanalyse. Derzeit unterstützt Insights mehrere Szenarien wie Anwendungsüberwachung und Kubernetes-Überwachung.

Im Hinblick auf den spezifischen Produktnutzungsprozess führt Insights eine intelligente Anomalieerkennung in Echtzeit durch, wenn die Anwendung mit ARMS verbunden ist. Die erkannten abnormalen Ereignisse werden auf der Seite mit der Liste der abnormalen Ereignisse angezeigt. Klicken Sie auf die Ereignisdetails, um einen detaillierten Bericht zur Ursachenanalyse anzuzeigen. Der Bericht enthält die Ereignisbeschreibung , Schlüsselindikatoren, eine Zusammenfassung der Anomalie-Ursachen, eine Liste der Ursachen und ein Linkdiagramm zur Fehlerausbreitung. Benutzer können auch auf bestimmte Ausnahmen in der Liste der Grundursachen klicken, um weitere Ergebnisse der Ausnahmeanalyse anzuzeigen, z. B. den Methodenstapel für Ausnahmeaufrufe, langsame SQL-Informationen, die von MySQL ausgeführt werden, Ausnahmeinformationen usw.

Zusammenfassen

Okay, damit endet das, was ich mit Qianlu geteilt habe. Um es kurz zusammenzufassen: Heute haben wir die drei wichtigsten beobachtbaren Herausforderungen in der K8s-Umgebung vorgestellt und anschließend den Datenerfassungsplan in der K8s-Umgebung erläutert: Wie man eBPF verwendet, um eine Datenerfassung auf verschiedenen Ebenen und eine Datenkorrelation zu erreichen. Abschließend wurde die praktische Erforschung der intelligenten Ursachenpositionierung im K8-Umfeld vorgestellt. Die Kernschritte sind Dimensionszuordnung, Anomalieabgrenzung und FTA-Fehlerbaumanalyse.

Ich hoffe, der heutige Inhalt kann Sie inspirieren und zum Nachdenken anregen. Vielen Dank fürs Zuhören!

Ursprünglicher Link

Dieser Artikel ist Originalinhalt von Alibaba Cloud und darf nicht ohne Genehmigung reproduziert werden.