Application Diagnostics in .NET Core 3.1

What do you do when your .NET Core application doesn’t behave the way you expect? Maybe it’s slower since the last deployment or has started crashing at the worst possible times. How do you analyze the issue when your application is running in someone else’s data center on the other side of the planet? On Linux? In a container?

Damian and David from the .NET team will demonstrate ways to diagnose issues in .NET Core 3.1 applications, using new APIs, command line tools, and features of Visual Studio, to gather information, analyze it, and fix root causes.

Transcript

1. Application Diagnostics in .NET Core 3.1 David Fowler – ASP.NET Architect @davidfowl Damian Edwards – ASP.NET Program Manager @damianedwards
2. .NET diagnostics primitives • Events • This thing happened, here’s a message and some data associated with it, e.g. Request started, path: /test, query: a=b • Metrics • Here’s a number representing the current state of this thing, e.g. Requests per second: 4, CPU utilization: 36%, ThreadPool queue length: 3 • Dumps • Here’s the memory associated with the application process at a point in time, saved in a platform-specific file
3. Producing diagnostics data • ILogger – structured logging abstraction, used in ASP.NET Core • DiagnosticSource – synchronous, in-process, live objects (untyped) • Activity – auto-flowing, ephemeral diagnostics context, dist. tracing • Runtime events – details from the CLR • EventSource – produce events & metrics, built-in
4. ILogger
5. DiagnosticSource
6. EventSource
7. Collecting diagnostics data • EventListener API • DiagnosticListener API • EventPipe API • EventPipe – default “on” out-of-process diagnostics server • Effectively “ETW for .NET” that works cross-platform • dotnet CLI tools • dotnet-counters: Collect & view counters • dotnet-trace: Collect & convert events • dotnet-dump: Collect a process dump • dotnet-gcdump: Collect a managed heap dump • dotnet-sos: Installs SOS and configures LLDB for dump debugging • dotnet-symbol: Downloads symbols files for dump debugging
8. EventListener
9. DiagnosticsListener
10. EventPipe API
11. Demo: CLI tools
12. Scenarios
13. Distributed tracing • Logs share trace IDs across HTTP calls between ASP.NET Core apps by default in 3.0 • Support for W3C Trace Context • The OpenTelemetry SDK supports ASP.NET Core • Visualize with tools such as Prometheus, Jaeger, Zipkin, and Application Insights
14. App is leaking memory
15. Async diagnostics
16. App is running slowly
17. App is crashing
18. Questions & thanks! @davidfowl @damianedwards