Application Diagnostics in .NET Core 3.1

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.

1fe64ebb176498be5f73ab51986c6b7b?s=128

David Fowler

January 29, 2020
Tweet

Transcript

  1. 1.

    Application Diagnostics in .NET Core 3.1 David Fowler – ASP.NET

    Architect @davidfowl Damian Edwards – ASP.NET Program Manager @damianedwards
  2. 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. 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. 4.
  5. 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
  6. 12.
  7. 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