Dynatrace OneAgent instruments your .NET applications by placing trace statements at strategic locations in your code for code tracing, performance metrics, error detection, dependency tracking, and more.
Not every detected .NET application is instrumented by default. Dynatrace maintains a set of rules to instrument specific processes (for example, IIS application-pools, which you can extend with our own rules). To learn the basics about process group monitoring setup (automatic deep monitoring, custom monitoring rules, and built-in monitoring rules), see Set up process group monitoring.
Dynatrace provides extensive .NET monitoring capabilities:
See our supported technologies matrix for details on supported frameworks.
Dynatrace is committed to support each version according to its support lifetime:
The .NET code module uses POSIX signals to capture stack traces for the method hotspots feature.
Because those signals can interrupt the application at arbitrary times, certain applications/libraries (in particular, .NET libraries with native dependencies) might not work correctly with method hotspots features enabled.
An affected application might show symptoms such as:
The only current solution is to disable the corresponding OneAgent features for the affected process group:
Method hotspots might not be able to correctly capture stack traces on musl-libc based operating systems such as Alpine. This is because certain debug information is removed by the musl-libc library. Moving to a glibc-based operating system (Debian/Ubuntu) can mitigate this specific issue.
With .NET Core 3.1, a new, optional feature called trimmed self-contained deployments and executables was introduced to optimize the size of packaged applications. To successfully instrument your application with OneAgent, turn off trimming. UiPath, for example, uses trimming, which makes it impossible to instrument with OneAgent.