Diagnoseverbesserungen in .NET Core 3.0

In .NET Core 3.0 stellen wir eine Reihe von Tools vor, die die neuen Funktionen der .NET-Laufzeitumgebung nutzen und die Diagnose und Lösung von Leistungsproblemen vereinfachen.

Mithilfe dieser Funktionen können Sie einige häufig gestellte Diagnosefragen beantworten:

1. Ist meine Anwendung betriebsbereit?
2. Warum hat meine Anwendung ein abnormales Verhalten?
3. Warum stürzt meine Anwendung ab?

Ist meine Anwendung betriebsbereit?

Im Laufe der Zeit kann ein Speicherverlust in der Anwendung auftreten, der letztendlich zu einer OutOfMemoryException führt. In anderen Fällen kann problematischer Code zu einem Anstieg der Prozessorlast führen. Dies sind nur einige der Probleme, die Sie aktiv mit Metriken identifizieren können.

Metriken

Metriken sind Messdaten über einen bestimmten Zeitraum. Mit diesen Metriken können Sie den Status Ihres Systems auf hoher Ebene überwachen. Im Gegensatz zu .NET Framework unter Windows generiert .NET Core keine Leistungsindikatoren. Stattdessen haben wir eine neue Methode zum Generieren von Metriken in .NET Core über die EventCounter- API eingeführt.

EventCounters bieten eine Verbesserung gegenüber Windows-Leistungsindikatoren, da sie jetzt auf allen Betriebssystemen verwendet werden, die .NET Core unterstützen. Darüber hinaus können sie im Gegensatz zu Leistungsindikatoren auch in Umgebungen mit geringen Berechtigungen verwendet werden (z. B. bei der Bereitstellung von xcopy). Leider macht es das Fehlen eines Tools wie Performance Monitor (Perfmon) schwierig, diese Indikatoren in Echtzeit anzuzeigen.

Dotnet-Zähler
In Version 3.0-Vorschau5 stellen wir ein neues Befehlszeilentool zur Überwachung von Metriken vor, die von .NET Core-Anwendungen in Echtzeit generiert werden.

Sie können dieses Tool installieren, indem Sie den folgenden Befehl ausführen

dotnet tool install --global dotnet-counters --version 1.0.3-preview5.19251.2 

Im folgenden Beispiel sehen wir, dass die CPU-Auslastung und der Arbeitsspeicher unserer Anwendung zunehmen, wenn wir mit dem Laden unserer Webanwendung beginnen.



Ausführliche Anweisungen zur Verwendung dieses Tools finden Sie in der Readme-Datei im Projekt mit Dotnet-Zählern . Informationen zu den bekannten Einschränkungen von Dotnet-Zählern finden Sie in den offenen Fragen zu GitHub .

Warum hat meine Anwendung ein abnormales Verhalten?

Metriken helfen zwar dabei, das Auftreten abnormalen Verhaltens zu identifizieren, bieten jedoch wenig Verständnis dafür, was schief gelaufen ist. Um die Frage zu beantworten, warum Ihre Anwendung ein abnormales Verhalten aufweist, müssen Sie zusätzliche Informationen über Traces sammeln. Mithilfe von CPU-Profilen, die mithilfe von Traces erfasst wurden, können Sie beispielsweise den Hot Path in Ihrem Code ermitteln.

Trace

Traces sind feste diskrete Ereignisdatensätze mit Zeitstempel. Traces enthalten einen lokalen Kontext, mit dem Sie das Schicksal des Systems besser bestimmen können. Traditionell hat das .NET Framework (und Frameworks wie ASP.NET) mithilfe der Ereignisverfolgung für Windows (ETW) Diagnosespuren für ihre internen Komponenten generiert. In .NET Core wurden diese Traces in ETW für Windows und LTTng für Linux aufgezeichnet.

Dotnet-Trace

In Version 3.0-Vorschau5 öffnet jede .NET Core-Anwendung einen Duplexkanal mit dem Namen EventPipe (ein Unix-Domänensocket in * nix oder eine Named Pipe in Windows), über den Ereignisse gesendet werden können. Während wir noch am Controller-Protokoll arbeiten, implementiert dotnet-trace eine vorläufige Version dieses Protokolls.

Sie können dieses Tool installieren, indem Sie den folgenden Befehl ausführen

 dotnet tool install --global dotnet-trace--version 1.0.3-preview5.19251.2 

Im obigen Beispiel führe ich einen Dotnet-Trace mit einem Standardprofil aus, das CPU-Profiler-Ereignisse und Laufzeit-.NET-Ereignisse enthält.

Zusätzlich zu den Standardereignissen können Sie basierend auf der Studie, die Sie durchführen möchten, weitere Anbieter aktivieren.

Durch Ausführen der Dotnet-Ablaufverfolgung erhalten Sie eine .netperf-Datei. Diese Datei enthält Laufzeit- und CPU-Stack- Abrufereignisse, die in perfview visualisiert werden können . Das nächste Update von Visual Studio (16.1) bietet außerdem Unterstützung für die Visualisierung dieser Traces.



Wenn Sie OS X oder Linux ausführen, können Sie .netperf-Dateien in .speedscope.json-Dateien konvertieren, die beim Aufzeichnen von Traces mit Speedscope.app gerendert werden können.
Sie können eine vorhandene Ablaufverfolgung konvertieren, indem Sie den folgenden Befehl ausführen:

 dotnet trace convert <input-netperf-file> 

Das Bild unten zeigt ein Diagramm, das die gerade erhaltene Spur visualisiert.



Ausführliche Anweisungen zur Verwendung dieses Tools finden Sie in der Readme-Datei . Informationen zu bekannten Einschränkungen bei Dotnet-Trace finden Sie in offenen Problemen auf GitHub .

Warum stürzt meine Anwendung ab?

In einigen Fällen ist es nicht möglich, die Ursache des abnormalen Verhaltens durch einfaches Überwachen des Prozesses festzustellen. Im Falle eines Prozessfehlers oder in Situationen, in denen wir möglicherweise zusätzliche Informationen benötigen, z. B. den Zugriff auf den gesamten Prozessheap, ist ein Prozessspeicherauszug möglicherweise besser für die Analyse geeignet.

Dump-Analyse

Ein Speicherauszug ist eine Aufzeichnung des Status des virtuellen Arbeitsspeichers eines Prozesses, der normalerweise erfasst wird, wenn er unerwartet beendet wurde. Kernel-Dump-Diagnosen werden häufig verwendet, um die Ursachen für Anwendungsabstürze oder unerwartetes Verhalten zu ermitteln.

Traditionell haben Sie sich darauf verlassen, dass Ihr Betriebssystem einen Speicherauszug erhält, wenn eine Anwendung abstürzt (z. B. Windows-Fehlerberichte), oder ein Tool wie procdump verwendet , um einen Speicherauszug zu erfassen, wenn bestimmte Startkriterien erfüllt wurden.

Bisher bestand das Problem beim Dump-Dumping mit .NET unter Linux darin, dass das Dump-Dumping mit gcore oder dem Debugger zu sehr großen Dumps geführt hat, da die vorhandenen Tools nicht wussten, welche Seiten des virtuellen Speichers im .NET Core-Prozess gekürzt werden sollten.

Darüber hinaus war es schwierig, diese Dumps zu analysieren, selbst nachdem Sie sie gesammelt hatten, da Sie einen Debugger kaufen und konfigurieren mussten, um sos, eine Debugger-Erweiterung für .NET, zu laden.

Dotnet-Dump

In 3.0.0-Vorschau5 stellen wir ein neues Tool vor, mit dem Sie Prozess-Dumps sowohl unter Windows als auch unter Linux erfassen und analysieren können.

dotnet-dump befindet sich noch in der aktiven Entwicklung. Die folgende Tabelle zeigt, welche Funktionen derzeit auf welchen Betriebssystemen unterstützt werden.



Sie können dieses Tool installieren, indem Sie den folgenden Befehl ausführen

 dotnet tool install --global dotnet-dump --version 1.0.3-preview5.19251.2 

Nachdem Sie dotnet-dump installiert haben, können Sie den Prozessspeicherauszug erfassen, indem Sie den folgenden Befehl ausführen

 sudo $HOME/.dotnet/tools/dotnet-dump collect -p <pid> 

Unter Linux kann der resultierende Speicherauszug analysiert werden, indem der resultierende Speicherauszug mit dem folgenden Befehl geladen wird

 dotnet dump analyze <dump-name> 

Im folgenden Beispiel versuche ich, einen ASP.NET Core Hosting Environment-Speicherauszug zu definieren



Ausführliche Anweisungen zur Verwendung dieses Tools finden Sie in der Readme-Datei. Informationen zu bekannten Einschränkungen bei dotnet-dump finden Sie in offenen Problemen auf GitHub .

Fazit

Vielen Dank, dass Sie die neuen Diagnosetools in .NET Core 3.0 getestet haben. Bitte geben Sie uns weiterhin Feedback, entweder in den Kommentaren oder auf GitHub . Wir hören aufmerksam zu und werden Änderungen basierend auf Ihrem Feedback vornehmen.