Anmerkung des Herausgebers: Im Jahr 2023 gründete die Dragon Lizard Community offiziell eine Allianz für Systembetrieb und -wartung, die aus der Akademie für Informations- und Kommunikationstechnologie, Alibaba Cloud, ZTE, der Fudan-Universität, der Tsinghua-Universität, der Zhejiang-Universität, Yunguan Qiuhao und Chengyun Digital besteht , Yunshan Network, wurde von 12 Einheiten mitgesponsert, darunter Inspur Information, Tongxin Software und China Unicom Software Institute. Dieser Artikel stammt von Yun Guan Qiu Hao und stellt Kindling-OriginX vor, ein Mitglied der System Operation and Maintenance Alliance, das durch die Kombination der vollständigen Netzwerkdatenfunktionen von DeepFlow automatisch interpretierbare Fehlerursachenberichte generiert.
DeepFlow ist ein Open-Source-Projekt, das die eBPF-Technologie nutzt, um eine hohe Beobachtbarkeit für komplexe Cloud-Infrastrukturen und Cloud-native Anwendungen bereitzustellen. Durch die eBPF-Technologie sammelt DeepFlow feine Link-Tracking-Daten sowie Netzwerk- und Anwendungsleistungsindikatoren mit vollständiger Linkabdeckung und umfassenden TCP-Leistungsindikatoren. Diese Funktionen bieten professionellen Benutzern und Netzwerkexperten leistungsstarke Unterstützung bei der Fehlerbehebung und Problemlokalisierung.
Kindling-OriginX ist ein Produkt zur Ableitung von Fehlerursachen. Ziel ist es, Benutzern einen interpretierbaren Fehlerursachenbericht bereitzustellen, der es Benutzern ermöglicht, die Grundursache des Fehlers direkt zu verstehen und den Argumentationsprozess der Grundursache zu überprüfen Genauigkeit der Grundursache. Es reicht nicht aus, den Benutzern einfach zu sagen, welches Netzwerksegment Probleme aufweist, um ihnen zu helfen, besser zu verstehen, welche Fehler im Netzwerk aufgetreten sind.
In diesem Artikel wird Kindling-OriginX vorgestellt, das die vollständigen Netzwerkdatenfunktionen von DeepFlow kombiniert, um automatisch interpretierbare Fehlerursachenberichte zu erstellen.
Fügen Sie einen 200 ms verzögerten Netzwerksimulationsfehler in den Sitzdienst ein.
Als nächstes verwenden wir zunächst DeepFlow, um 200-ms-Netzwerkausfälle zu identifizieren und entsprechende Maßnahmen zu ergreifen.
Schritt 1: Verwenden Sie das Trace-System, um den Umfang einzugrenzen
Wenn in einer Microservice-Umgebung ein Leistungsproblem an einer Schnittstelle auftritt, besteht der erste Schritt darin, mithilfe des Tracking-Systems zu überprüfen, welcher Link die Langsamkeit verursacht, und die spezifische Leistung zu verstehen.
Mit dem Tracing-System können Benutzer bestimmte Traces genau lokalisieren. Nach der Analyse der Ablaufverfolgung wurde festgestellt, dass die Ausführungszeit des Sitzdienstes lang war und gleichzeitig ein langer Aufruf des Konfigurationsdienstes stattfand. In diesem Fall helfen verknüpfte Netzwerkindikatoren dabei, die Ursache des Netzwerkproblems zu ermitteln.
Schritt 2: Verwenden Sie das DeepFlow-Flammendiagramm, um zu bestimmen, in welchem Netzwerksegment der Fehler auftritt
Geben Sie die Trace-ID des Fehlerrepräsentanten in DeepFlow in das Flammendiagramm ein, ermitteln Sie die Leistung von Trace auf Netzwerkebene und analysieren Sie dann das Flammendiagramm eingehend Die menschliche Analyse ergab, dass dieser Fehler beim Anrufer, dem Seat-Service, aufgetreten sein sollte und das Problem während des Zeitraums aufgetreten ist, in dem der Systemaufruf an die Netzwerkkarte gesendet wurde Das heißt, es gab ein Problem im Container-Netzwerkzeitraum (was mit der Fehlerinjektion übereinstimmt).
(Bild/DeepFlow-Netzwerkflammendiagramm)
Schritt 3: Bestimmen Sie, welche Netzwerkindikatoren im Containernetzwerk abnormal sind
Basierend auf der Erfahrung bei der Fehlerbehebung müssen Benutzer die Netzwerkindikatoren der Pods von Seat-Service und Config-Service überprüfen. Zu diesem Zeitpunkt muss der Benutzer zur Netzwerkanzeigeseite auf Pod-Ebene von DeepFlow springen. Auf dieser Seite können Benutzer eine Verzögerungsänderung von 200 ms beim Verbindungsaufbau und eine Änderung im RTT-Indikator anzeigen.
(Anzeigen zur Überwachung des Bild-/DeepFlow-Pod-Füllstands)
(Anzeigen zur Überwachung des Bild-/DeepFlow-Pod-Füllstands)
Schritt 4: Mögliche Störfaktoren beseitigen
Wenn die CPU und die Bandbreite des Hosts voll sind, kommt es erfahrungsgemäß auch im virtuellen Netzwerk zu Paketverlusten und Verzögerungen. Daher ist es erforderlich, die CPU- und Knotenebenenbandbreite des Knotens zu überprüfen, auf dem sich der Sitzdienst und der Konfigurationsdienst befinden Stellen Sie sicher, dass die Ressourcen auf Knotenebene nicht ausgelastet sind.
Bestätigen Sie mit dem Befehl k8s den Knoten, auf dem sich die beiden Pods befinden, und gehen Sie dann zur Knotenindikator-Überwachungsseite von DeepFlow, um die entsprechenden Indikatoren zu überprüfen. Es wurde festgestellt, dass die BPS, PPS und andere Indikatoren des Knotens innerhalb eines angemessenen Bereichs liegen Reichweite.
(Bilden/Suchen Sie den Knoten, auf dem sich der Pod befindet, mit dem Befehl k8s)
(Überwachungsindikatoren für Bild-/DeepFlow-Knotenebene (Client))
(Bild-/DeepFlow-Knoten-Überwachungsindikatoren (Server))
Da es keine offensichtliche Anomalie bei den Netzwerkindikatoren auf Knotenebene gab, wurde schließlich festgestellt, dass der RTT-Indikator des Sitzdienstes auf Pod-Ebene abnormal war.
Zusammenfassung der manuellen Fehlerbehebung
Nach einer Reihe von Fehlerbehebungsprozessen kann der Endbenutzer das Problem beheben, es werden jedoch folgende Anforderungen an den Benutzer gestellt:
Sehr umfangreiches Netzwerkwissen
Umfassendes Verständnis des Netzwerk-Flammendiagramms
Kompetenter Umgang mit relevanten Werkzeugen
Kindling-OriginX Basierend auf unterschiedlichen Benutzerbedürfnissen und Nutzungsszenarien verarbeitet und präsentiert Kindling-OriginX DeepFlow-Daten.
In Analogie zum manuellen, vereinfachten Fehlerbehebungsprozess ist der Fehlerbehebungsprozess mit Kindling-OriginX wie folgt:
Analysieren Sie automatisch jede Spur
Angesichts des Fehlers zu diesem Zeitpunkt wird jeder Trace automatisch analysiert und die aufgelisteten Traces werden nach Fehlerknoten gruppiert. Reiseservice wird durch kaskadierende Fehler verursacht. Dieser Artikel konzentriert sich nicht auf kaskadierende Fehler. Wenn Sie interessiert sind, können Sie sich auf den Umgang mit kaskadierenden Fehlern bei Microservices beziehen.
Überprüfen Sie den Fehlerstammbericht, bei dem der Fehlerknoten Sitz-Service ist
Schlussfolgerung zur Fehlerursache:
Für die Unteranforderung 10.244.1.254:50332->10.244.5.79:15679 RTT-Indikator gibt es eine Verzögerung von etwa 200 ms.
Fehlerbegründung und -überprüfung
Da Kindling-OriginX festgestellt hat, dass es ein Problem mit dem Netzwerk gibt, bei dem Seat-Service Config-Service aufruft, muss es dem Benutzer nicht alle Daten des DeepFlow-Flammendiagramms vollständig präsentieren. Es muss lediglich eine Verbindung mit DeepFlow hergestellt werden Holen Sie sich nur den Sitzdienst, um die Konfiguration aufzurufen. Die Daten, die sich auf den Netzwerkaufruf des Dienstes beziehen, reichen aus.
Unter Verwendung des DeepFlow-Sitzdienstes zum Aufrufen von Konfigurationsdienstdaten wurde automatisch analysiert, dass das Containernetzwerk des Client-Pods eine Verzögerung von 201 ms aufwies.
Kindling-OriginX simuliert Expertenanalyseerfahrungen und korreliert die Neuübertragungsindikatoren und RTT-Indikatoren von DeepFlow weiter, um zu bestimmen, was die Verzögerung beim Aufruf des Konfigurationsdienstes durch den Sitzdienst verursacht.
Kindling-OriginX integriert außerdem die CPU-Auslastung und Bandbreitenindikatoren des Knotens, um Störfaktoren zu beseitigen.
Kindling-OriginX vervollständigt die gesamte Fehlerbegründung in einem einseitigen Bericht, und jede Datenquelle ist vertrauenswürdig und überprüfbar.
Kindling-OriginX und DeepFlow nutzen beide die eBPF-Technologie und sind bestrebt, flexible und effiziente Lösungen für Benutzer mit unterschiedlichen Anforderungen in unterschiedlichen Szenarien bereitzustellen. Wir freuen uns auch darauf, in Zukunft weitere inländische Produkte mit ergänzenden Funktionen zu sehen.
DeepFlow kann sehr vollständige Basisdaten des Full-Link-Netzwerks bereitstellen, wodurch Cloud-native Anwendungen umfassend beobachtbar werden und ist sehr nützlich für die Fehlerbehebung bei Netzwerkproblemen.
Kindling-OriginX verwendet eBPF, um North Star-Indikatoren zur Fehlerbehebung, KI-Algorithmen und Expertenerfahrungen zu sammeln, um eine Fehlerbeurteilungs-Engine zu erstellen, die Benutzern interpretierbare Ursachenberichte liefert.
—— Ende ——
Das obige ist der detaillierte Inhalt vonDragon Lizard System Operation and Maintenance Alliance: Wie Kindling-OriginX die Daten von DeepFlow integriert, um die Erklärung von Netzwerkfehlern zu verbessern. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!