Announcing general availability of Elastic APM .NET agent profiler auto-instrumentation

A few months back, we introduced the beta release of Elastic APM .NET agent profiler auto-instrumentation. Fast forward to today, we're excited to announce the general availability (GA) of this powerful capability that allows the .NET APM agent to automatically instrument .NET Framework, .NET Core, and .NET applications without requiring code changes or recompilation. In addition, assemblies for common messaging frameworks like Kafka and RabbitMQ, as well as MySQL, Oracle, and PostgreSQL, can now be automatically instrumented.

At the time of the beta release, we posted a detailed technical blog about how auto-instrumentation works in the next iteration of the Elastic APM .NET Agent. This blog contains a deep-dive into profiling — including COM Interfaces and Method rewriting — and includes a practical Kafka example to demonstrate the value of using a profiler-based approach to instrumentation. It's an excellent read for those wanting to dig into the technical details behind the approach.

As the technical how has already been well addressed, it's worthwhile to spend a moment on why this feature is important, and also who might benefit most from its use.

Until recently, the primary way to instrument .NET Framework applications was using the NuGet APM agent package, which has been a preferred option for developers adding instrumentation early in the development cycle. While the NuGet APM agent is commonly used and provides the ability to create observable applications, the approach is limited because it requires modification of the application code itself. This approach works well when observability requirements are understood and addressed as part of the application development process and when we have access to the application code.

Here are some real-world examples of how the new Elastic APM agent profiler auto-instrumentation can create a path to application observability that would otherwise have been limited.

Scenario 1: Instrumenting existing .NET applications

As organizations transition from siloed monitoring strategies to a holistic observability approach, many enterprise architecture (or platform) teams have been tasked with standardizing observability practices across the organization. One such recommendation might be to enable distributed tracing for all critical and non-critical applications. This presents a problem for .NET application owners who have not built their applications in consideration of such requirements.

In the prior model of application instrumentation, a developer would need to download and install the binary packages, modify the code to include them in the applications, re-compile, and re-deploy the application(s). Such an approach is time-consuming and lacks scalability as it requires development, planning, testing, and deployment. Consider for a moment if this task took an hour per application; imagine what that would mean for tens (or even more) of applications.

Contrast what I've described above with the ability to use profiler-based auto-instrumentation, where four simple steps direct the .NET runtime to load the Elastic CLR profiler into the .NET process, loading and instantiating the APM agent early in the application startup.

Scenario 2: Instrumenting .NET applications migrating to the cloud

As software proliferates into every corner of our lives, telling us when to sleep and what to eat, it becomes increasingly necessary for businesses to adopt scalable cloud-based architectures to meet this demand. As such, container usage is growing at a staggering pace. A common use case for containers is to simplify the transition of moving from deploying applications in more traditional environments (physical hosts or hypervisors) to more modern, cloud environments.

In this scenario, profiler-based auto-instrumentation can easily be set up as part of the container configuration in such a way that when the container is instantiated, everything is in place for tracing telemetry to be collected and sent to the Elastic APM server. The key here is that the configuration takes place outside of the application (meaning no changes to code or recompilation required). Leveraging this approach allows applications to be configured once (as part of the deployment process) and deployed at scale.

In summary, Elastic APM .NET agent profiler auto-instrumentation helps you simplify, standardize, and accelerate application observability for your .NET applications by providing a no-code option for auto-instrumentation. We're keen to hear feedback on the profiler auto instrumentation. Please try it out by downloading the elasticapm_profiler*.zip from the GitHub release page, and let us know your thoughts, particularly if you are using technologies that are supported by the currently available instrumentations.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.