Diagnosetool für langsame Anrufketten – ARMS-Code-Hotspots

Von Daten bis hin zu großen Modellanwendungen: Am 25. November fand die Hangzhou Yuanchuang-Konferenz statt, um Entwicklungstipps auszutauschen.

Beobachtbarer Technologiehintergrund

Ausgehend vom ersten von Google veröffentlichten Artikel mit dem Titel „Dapper, a Large-Scale Distributed Systems Tracing Infrastructure“ entwickelte es sich später in drei Hauptrichtungen: Metriken (Indikatoren), Tracing (Linkverfolgung) und Protokollierung (Protokoll). Ergänzende beobachtbare Lösungen sind werden nach und nach von der Industrie akzeptiert und werden zu De-facto-Standards.

Basierend auf der oben genannten Full-Stack-Observable-Lösungstechnologie hat sich die Diagnose eines Problems von der Möglichkeit, nicht zu starten oder sich ausschließlich auf Protokolle zu verlassen, auf die folgenden Schritte geändert:

1. Entdecken Sie abnormale Anwendungsinformationen und ermitteln Sie abnormale Module mithilfe verschiedener voreingestellter Alarme, die von Metriken/Protokollen bereitgestellt werden

2. Fragen Sie das Ausnahmemodul und die zugehörigen Protokolle (Protokolle) ab und analysieren Sie diese, um die Kernfehlerinformationen zu finden

3. Lokalisieren Sie das Codefragment, das das Problem verursacht, anhand detaillierter Anrufkettendaten (Tracing).

Basierend auf den oben genannten beobachtbaren Lösungen können Probleme nicht nur schnell lokalisiert und Verluste rechtzeitig nach ihrem Auftreten reduziert werden, sondern in vielen Fällen können Probleme auch im Voraus erkannt und behoben werden, bevor größere Ausfälle auftreten.

Überwachung toter Winkel

Können alle Online-Überwachungsprobleme auf der Grundlage der oben genannten beobachtbaren Lösungen ein für alle Mal gelöst werden? Tatsächlich ist dies nicht der Fall, insbesondere im Hinblick auf die Ablaufverfolgung, da diese im Allgemeinen auf technischen Java-Agent/SDK-Lösungen basiert, um Anrufkettenüberwachungsdaten von gängigen Softwareentwicklungs-Frameworks wie HTTP-Diensten, RPC-Diensten, Datenbanken und verteilten Nachrichten zu sammeln MQ usw. Anschließend ordnet die nachfolgende Verarbeitungslogik für die Wiederherstellung der Anrufkettendaten die Überwachungsinformationen der spezifischen Anforderung zu, sodass bei Auftreten einer Ausnahme in der Anforderung die relevanten Anrufinformationen anhand der gesammelten Überwachungsdaten angezeigt werden können. Neben der Bereitstellung der Kernverbindungsmethode, die eine Anfrage durchläuft, hat die Aufrufkette auch eine weitere Kernfunktion: Sie hilft bei der Identifizierung langsamer und zeitaufwändiger Stellen in einer Aufrufkette und hilft bei der Codeoptimierung. Der spezifische Fehlerbehebungsprozess kann verwendet werden, um die zeitaufwändige Engpasslogik in der Anrufkette anhand der detaillierten Informationen der Anrufkette zu diagnostizieren, wie in der folgenden Abbildung dargestellt:

Wie in der Abbildung oben gezeigt, dient eine Aufrufkette als Trace und verfügt über eine eindeutige TraceId. Der Trace enthält mehrere Spans, von denen jeder den Aufruf an mehrere Downstream-Dienste darstellt, von denen jeder über entsprechende SpanId-Informationen verfügt. Anhand der obigen Abbildung können Sie die zeitaufwändige Situation erkennen, die bei mehreren Diensten auftritt, die eine Anforderung durchläuft (es wird davon ausgegangen, dass ein Downstream-Dienst einem Span entspricht, und einige Link-Tracking-Systeme können unterschiedlich sein), was sich auf die Anwendungszeit auswirkt Aufwändig Lokalisieren Sie Engpässe und führen Sie entsprechende Leistungsoptimierungen durch.

Im Bereich verteilter Mikrodienste kann es jedoch aufgrund der Komplexität der aufrufenden Verbindungen zu maschinenübergreifenden oder sogar maschinenübergreifenden Räumen kommen, da das allgemeine Tracing-System die Kernmethoden nur dann im Mainstream-Open-Source-Software-Framework begraben kann, wenn die Die zeitaufwändige Position wird im Tracing-Vergrabungspunkt angezeigt. Bei Verwendung der Benutzergeschäftslogik gibt es einen langen zeitaufwändigen Zeitraum in der endgültigen Aufrufkette, der nicht der spezifischen Codeausführungsmethode entsprechen kann, was dazu führt, dass dies nicht genau beurteilt werden kann Geschäftslogik zeitaufwändig.

Der konkrete Fall ist im folgenden Code zu sehen:

public String demo() throws SQLException {

    // 此处耗时1000ms，模拟其他业务耗时逻辑
    take1000ms(1000);
    // SQL 查询执行操作
    stmt = conn.createStatement();
    ResultSet rs = stmt.executeQuery("SELECT * FROM table");

    return "Hello ARMS!";
}

private void take1000ms(long time) {
  try {
    Thread.sleep(time);
  } catch (InterruptedException e) {
    e.printStackTrace();
  }
}

In der obigen Codelogik stellen die Zeilen 6 bis 7 die Ausführungslogik im Zusammenhang mit der Datenbankverbindung dar. Diese Art von Logik wird im Allgemeinen von gängigen Ablaufverfolgungssystemen abgedeckt. Die spezifische Geschäftszeit des Kunden in Zeile 4 entspricht jedoch im Allgemeinen den fehlenden Überwachungspunkten ausgeblendet, was dazu führt, dass der Zeitverbrauch schließlich in der Demo der Spring Boot-Methode des vorherigen Layer-Eintrags gezählt wird.

Die entsprechende endgültige Anzeigeform in der Tracing-Aufrufkette ähnelt möglicherweise der folgenden Abbildung. In der Tracing-Aufrufkette sind nur der Zeitverbrauch der externen Schnittstelle der ersten Schicht und der Zeitverbrauch der Ausführungslogik des bekannten Software-Frameworks enthalten Darin kann man erkennen, dass unter anderem der grau schattierte Teil Der Geschäftslogikcode des Benutzers, der nicht vom Tracing-System abgedeckt wird, als Überwachungs-Blindspot verwendet wird. Sein tatsächlicher Zeitaufwand ist unbekannt, was viele Hindernisse bei der Online-Fehlerbehebung verursacht Leistungsprobleme:

Die oben genannten Probleme treten bei Unternehmensbenutzern sehr häufig auf und oft können sie nur seufzen und sich hilflos fühlen!

Lösung

Was das zeitaufwändige Diagnoseproblem langsamer Anrufketten angeht, wenn dem Tracing-System vergrabene Punkte fehlen, gibt es nach Kenntnis des Autors derzeit nur sehr wenige relevante Lösungen in der Branche. Studierende, die mit Arthas vertraut sind, erwähnen möglicherweise den Trace-Befehl [1]. In der Tat ist es bis zu einem gewissen Grad möglich, die spezifischen zeitaufwändigen Standorte langsamer Anrufketten in einigen einfachen Szenen langsamer Anrufketten manuell zu überprüfen, die stabil reproduziert werden können. Aber auch die Grenzen liegen auf der Hand:

Begrenzter Fokus

Es unterstützt nur die Diagnose langsamer Anrufe in stabil reproduzierbaren Szenarien. Es ist schwierig, Probleme mit langsamen Anrufen in Szenarien zu beheben, die schwer reproduzierbar sind, wie z. B. Speicherbereinigung, Ressourcenkonflikte und Netzwerkprobleme.

Hohe Nutzungsschwelle

In tatsächlichen Produktionsszenarien kann die Aufrufkette sehr komplex sein. Wenn Sie mit dem Geschäftscode sehr vertraut sein müssen, können Sie den Trace-Befehl manuell für eine bestimmte Geschäftsmethode ausführen, um die Anforderungszeit zu überwachen. Wenn Sie mit der Geschäftsmethode nicht vertraut sind Ausführung oder Es ist schwierig, dieses Tool zur Fehlerbehebung bei einigen komplexen asynchronen Aufrufszenarien zu verwenden.

Hoher Untersuchungsaufwand

Dieses Tool kann tatsächlich zur Fehlerbehebung bei langsamen Anrufen in einfachen Single-Hop-Geschäftsszenarien verwendet werden. In komplexen anwendungsübergreifenden Multi-Hop-Geschäftsszenarien wird der Fehlerbehebungsprozess jedoch sehr mühsam. Sie müssen nicht nur einige APM-Tools verwenden, um die Anwendungsinstanz zu lokalisieren, in der sich der spezifische langsame Aufruf befindet, sondern auch in Szenarien, in denen der Stapel der Geschäftsaufrufmethode sehr tief ist, müssen Sie relevante Befehle Schicht für Schicht ausführen und Schritt für Schritt überwachen Schritt, um die Ursache des Problems zu finden.

Zusammenfassend lässt sich sagen, dass der Trace-Befehl von Arthas in einigen einfachen langsamen Anrufszenarien verwendet werden kann, aber zur Fehlerbehebung in der langsamen Anrufkette in komplexen Szenarien nicht ausreicht!

Zu diesem Zweck können das Alibaba Cloud ARMS-Team und das Alibaba Dragonwell-Team Benutzern durch kontinuierliche Analysetechnologie helfen, die Informationen zum Call-Chain-Methodenstapel besser wiederherzustellen, um diese Art von Tracing-Überwachungs-Blind-Spot-Problem besser zu lösen.

Kontinuierliche Analysefunktionen von ARMS

Als bekanntes APM-Tool in China bietet ARMS nicht nur gängige beobachtbare Lösungen für Tracing-, Metrik- und Protokollierungsunternehmen, sondern auch sofort einsatzbereite Lösungen für die kontinuierliche Profilerstellung (Continuous Profiling, CP). Kontinuierliche Profilerstellung hilft bei der Überwachung und Lokalisierung von Engpässen bei der Anwendungsleistung, indem Stapelinformationen von Anwendungen wie CPU/Speicher und anderen Ressourcen dynamisch in Echtzeit erfasst werden. Die Architektur der derzeit von ARMS bereitgestellten kontinuierlichen Analysefunktionen ist in der folgenden Abbildung dargestellt:

Auf der Clientseite bietet die Java-Agent-Technologie nicht-invasiv kontinuierliche Analyse- und Datenerfassungsfunktionen auf der Grundlage anderer beobachtbarer Funktionen. Anschließend werden die gesammelten Daten auf der Serverseite analysiert und verarbeitet, und schließlich stellt die Konsole den Benutzern sofort einsatzbereite Funktionen zur Verfügung, darunter CPU-Diagnose, Speicherdiagnose und Code-Hotspot-Funktionen.

CPU- und Speicherdiagnose

Flammendiagramme sind sicherlich vielen Lesern bekannt, die Probleme mit der Anwendungsleistung behoben haben. Indem Sie beobachten, ob das Flammendiagramm eine breite Spitze aufweist, können Sie Probleme mit der Anwendungsleistung lokalisieren. Für viele Entwickler bezieht sich das oben erwähnte Flammendiagramm im Allgemeinen auf das CPU-Hotspot-Flammendiagramm. Es stellt die zeitaufwändige Situation dar, in der Methoden von der CPU in der Anwendung innerhalb eines bestimmten Zeitraums ausgeführt werden. Die von ARMS bereitgestellte CPU- und Speicherdiagnosefunktion basiert auf der kontinuierlichen Open-Source-Analyse Async Profiler [2], die die normale Erfassung von Anwendungs-CPU- und Speicheranwendungsmethoden-Stack-Informationen unter Bedingungen mit geringem Overhead unterstützt und eine einfache und effiziente normale Überwachung unterstützt des Produktionsszenarios der Anwendungs-CPU und des Arbeitsspeichers. Anwendungsstatus: Verabschieden Sie sich von der Situation, in der es schwierig ist, die Anwendung regelmäßig mit Open-Source-Tools zu öffnen, und es leicht ist, die Problemszenarien zu übersehen, die nicht einfach zu reproduzieren sind.

Code-Hotspots

Nachdem wir über die CPU- und Speicherdiagnose gesprochen haben, fragen sich einige Leser möglicherweise: Können wir den Flammengraphen des Methodenstapels, der der CPU-Diagnose entspricht, verwenden, um das Problem der Verfolgung blinder Flecken bei der Systemüberwachung zu lösen und bei der Fehlerbehebung bei langsamen Aufrufketten zu helfen? Die Antwort ist negativ! Denn bei der CPU-Diagnose werden regelmäßig die Methodenstapelinformationen des auf der CPU ausgeführten Ausführungsthreads erfasst und dann in ein Flammendiagramm umgewandelt.

Neben dem auf der CPU ausgeführten Status „Laufend“ (auch „On-CPU“ genannt) verfügt der Thread-Status im Softwareprogramm auch über andere Zustände wie „Blockiert“ und „Wartend“ (zusammen „Off-CPU“ genannt), und eine langsame Aufrufkette weist häufig mehrere Zustände auf Thread-Zustände. Durch die Überlagerung dauert die endgültige Präsentation lange. Daher hat das CPU-Flammendiagramm nur begrenzte Auswirkungen auf Szenarios mit langsamer Aufrufkette.

Gibt es also eine Flame-Graph-Technologie, die nicht nur On-CPU-Inhalte beschreiben, sondern auch Off-CPU-Inhalte einbeziehen kann? Dann müssen wir noch die Flammenkarte der Wanduhr (Wallclock) erwähnen. Das Implementierungsprinzip ist nicht kompliziert: Es wird eine Gruppe von Threads unter allen Anwendungsthreads mit einer festen Häufigkeit ausgewählt, um deren Methodenstapelinformationen zum aktuellen Zeitpunkt zu sammeln und das entsprechende Flammendiagramm durch Aggregationsverarbeitung zu zeichnen. Async Profiler bietet auch entsprechende Funktionen.

Der Hauptcode-Hotspot dieses Artikels basiert auf der Wall-Clock-Funktion des Open-Source-Async-Profilers. Durch die Korrelation der TraceId- und SpanId-Informationen in der Aufrufkette wird ein On- und Off-CPU-Flammendiagramm auf Aufrufkettenebene bereitgestellt kann die Details der blinden Flecken von Tracing effektiv überwachen. Verschiedene häufige Probleme mit langsamen Anrufketten wiederherstellen und Benutzern bei der Diagnose helfen. Der spezifische Prozess ist in der folgenden Abbildung dargestellt. Durch die Zuordnung oder Löschung von TraceId- und SpanId-Informationen zu Beginn und am Ende der Thread-Erstellung Span enthält der endgültig generierte Stapel-Snapshot der Wall-Clock-Methode relevante Informationen und führt ihn dann kontinuierlich durch Analyse der Daten Verarbeiten und analysieren Sie das Flammendiagramm der Wanduhr, das sich auf die entsprechende Anrufkette bezieht, und stellen Sie es wieder her, um das Problem der langsamen Anrufkette zu lokalisieren:

Kernfunktionen

Die derzeit von ARMS bereitgestellten kontinuierlichen Analysefunktionen weisen im Vergleich zu anderen Diagnosetools für langsame Anrufketten oder Open-Source-Tools für die kontinuierliche Analyse die folgenden Merkmale auf:

geringer Overhead

Durch Maßnahmen wie die automatische Stichprobenentnahme auf der Grundlage des Trace-Prozesses und die Wall-Clock-Analyse auf der Grundlage der zugehörigen Stichprobenraten weist die aktuelle Fähigkeit des ARMS-Produkts zur kontinuierlichen Analyse einen CPU-Overhead von 5 % und einen Off-Heap-Speicher-Overhead von etwa 50 MB auf. Der GC Zusätzlicher Overhead ist nicht offensichtlich und kann in der Produktionsumgebung normal verwendet werden. Einschalten.

feine Körnigkeit

Zusätzlich zu CPU- und Speicher-Hotspots auf Anwendungsebene stellt es durch die Korrelation von TraceId- und SpanId-Informationen auch Methodenstapelinformationen für die Aufrufkettenebene bereit, was effektiv bei der Diagnose langsamer Aufrufkettenprobleme helfen kann.

Sicher, zuverlässig, einfach und effizient

Einige Open-Source-Technologien zur kontinuierlichen Profilerstellung, z. B. die Verwendung von Arthas zum Generieren von CPU-Flammendiagrammen (die unterste Ebene basiert auch auf Async Profiler), werden nach der Verwendung im Allgemeinen ein- und ausgeschaltet, sodass sie selbst bei technischen Risiken nicht leicht zu finden sind . Während des Produktentwicklungsprozesses haben wir immer noch viele Risikoprobleme bei der Verwendung von Open-Source-Technologien wie Async Profiler im kontinuierlichen Profilierungsprozess entdeckt. Beispielsweise kann die Speicherprofilierung zum Absturz der Anwendung #694 [3] führen , das Flammendiagramm der Wanduhr kann dazu führen, dass Threads für längere Zeit blockiert werden #769 [4] usw. Durch die Behebung dieser Probleme werden unsere Produktfunktionen sicherer und zuverlässiger. Zusätzlich zur Sicherheit speichert die kontinuierliche Analysefunktion von ARMS die Daten nach dem normalen Einschalten automatisch sieben Tage lang, sodass Benutzer nicht die Diagnosestelle jeder langsamen Anrufkette verpassen.

Verwenden Sie Code-Hotspots, um Probleme bei langsamen Anrufketten zu beheben

Aktivieren Sie Code-Hotspots

1. Melden Sie sich bei der ARMS-Konsole an und wählen Sie Anwendungsüberwachung > Anwendungsliste in der linken Navigationsleiste.

2. Wählen Sie oben auf der Anwendungslistenseite die Zielregion aus und klicken Sie dann auf den Namen der Zielanwendung.

3. Klicken Sie in der linken Navigationsleiste auf Anwendungseinstellungen und dann auf die Registerkarte Benutzerdefinierte Konfiguration .

4. Nachdem Sie den CPU- und Speicher-Hotspot- Hauptschalter eingeschaltet haben , schalten Sie den Code-Hotspot- Schalter ein und konfigurieren Sie die IP-Adresse der zu aktivierenden Anwendungsinstanz oder die Netzwerksegmentadresse, zu der eine Gruppe von Instanzen gehört.

5. Klicken Sie unten auf der Seite auf Speichern .

Code-Hotspot-Daten über Schnittstellenaufrufe anzeigen

1. Melden Sie sich bei der ARMS-Konsole an und wählen Sie Anwendungsüberwachung > Anwendungsliste in der linken Navigationsleiste.

2. Wählen Sie oben auf der Anwendungslistenseite die Zielregion aus und klicken Sie dann auf den Namen der Zielanwendung.

3. Klicken Sie in der linken Navigationsleiste auf „ Schnittstellenaufruf “, wählen Sie rechts auf der Seite die Zielschnittstelle aus und klicken Sie dann auf die Registerkarte „ Anrufkettenabfrage“ .

4. Klicken Sie auf der Registerkarte „Anrufkettenabfrage “ auf den Link „Ziel-TraceId“ .

5. Klicken Sie auf das Lupensymbol in der Detailspalte . Zuerst können Sie auf die Registerkarte „Methodenstapel“ klicken, um einen Blick auf die Methodenstapelinformationen zu werfen, die mit dem Tracing-Tool angezeigt werden. Sie können sehen, dass es nur MariaDB-bezogene Ausführungslogik enthält sein vorderer Teil Die Geschäftszeit wurde nicht erfasst.

6. Klicken Sie anschließend auf die Registerkarte „Code-Hotspots“ . Im Flammendiagramm auf der rechten Seite können Sie sehen, dass zusätzlich zum MariaDB-bezogenen Methodenstapel (entsprechend der ganz rechten und scharfen Flamme im Flammendiagramm auf der rechten Seite der Abbildung unten) Es enthält auch Java. Der mit lang.Thread.sleep() verbundene Zeitverbrauch von 990 ms (aufgrund der kontinuierlichen Analyse, um den Thread-Methodenstapel basierend auf der Stichprobe zu erhalten, kann es zu Abweichungen kommen).

Die linke Seite der Abbildung ist eine zeitaufwändige Liste aller an diesem Aufruf beteiligten Methoden, und die rechte Seite ist ein Flammendiagramm mit allen Methodenstapelinformationen der entsprechenden Methode. Darunter zeigt die Spalte „Selbst“ den Zeitverbrauch der Methode selbst. Um die spezifische Hot-Code-Logik zu beheben, können Sie die äußerst zeitaufwändigen Geschäftsmethoden lokalisieren, indem Sie sich auf die Spalte „Selbst“ konzentrieren oder direkt auf die größeren Flammen am unteren Rand des Flammendiagramms auf der rechten Seite schauen. Die größeren Flammen sind die Hauptursache für Der hohe Zeitverbrauch in der oberen Schicht ist im Allgemeinen ein Engpass bei der Systemleistung, wie beispielsweise die Methode java.lang.Thread.sleep () in der obigen Abbildung. Weitere Einzelheiten zur Verwendung finden Sie in der Benutzerdokumentation [5] zu dieser Funktion .

Verwandte Links:

[1] Trace-Befehl

https://arthas.aliyun.com/en/doc/trace.html

[2] Asynchroner Profiler

https://github.com/async-profiler/async-profiler

[3] #694

https://github.com/async-profiler/async-profiler/issues/694

[4] #769

https://github.com/async-profiler/async-profiler/issues/769

[5] Benutzerdokumentation

https://help.aliyun.com/zh/arms/application-monitoring/user-guide/use-code-hotspots-to-diagnose-code-level-problems?spm=a2c4g.11186623.0.i3

Autor: Cheng Pu, Yi Bo