.NET

Overview

Instrumenting your .NET applications and services to generate traces, logs, and metrics is a powerful way to gain deep insights into its behavior and performance. By adding instrumentation, you enable your application to emit valuable data that can be used for monitoring, troubleshooting, and optimization.

Dash0 supports automatic instrumentation of .NET applications through OpenTelemetry's open-source and vendor-agnostic packages.

Use Cases

• Understand outgoing and incoming HTTP requests through traces and metrics. Allowing drill-downs to the database level.
• You can see which database statements were executed and how long they took, which gives you valuable data to optimize your applications.
• Reveal (uncaught) errors and the context in which they happened.

Install

OpenTelemetry comes with a ready-made auto-instrumentation package for .NET that will kickstart your observability journey. Learn more about the installation process within OpenTelemetry's official documentation.

Note: Currently the OpenTelemetry Auto-instrumentation is not supported on Apple Silicon. For more details, see the compatibility guide.

Auto-instrumentation

The steps below is for Linux. If you are on a Windows computer, check out the official guide using Powershell here.

1. Download the latest installation script

2. Execute the installation script

3. Execute the script for configuring your environment

Configure

Most auto-instrumentation in OpenTelemetry can be configured using environment variables. Specify the following variables to automatically apply the auto-instrumentation package and send data to your Dash0 environment:

1. Specify the application service name:

Replace my-first-observable-dotnet-service with a meaningful name that identifies your application.

2. Set up the data export endpoint and authorization token:

Note: You can specify which dataset to send data to by adding the Dash0-Dataset header. For example:

For more information, see the dataset documentation.

Supported libraries and frameworks

To understand which libraries are automatically instrumented by this package, please refer to the OpenTelemetry documentation.

Troubleshooting

How do I ensure that the OpenTelemetry Agent is correctly initialized and active?

To verify that the OpenTelemetry agent is initialized and active, enable debug logging:

TThis will produce multiple log files in the specified directory, ./logs.

Start by inspecting the *-Native.log file to confirm that OpenTelemetry auto-instrumentation is hooking into .NET.

Modules are loaded:

Rejit is happening, which is important for auto-instrumentation to dynamically rewrite modules:

You can investigate the rest of the files to look for other initialization issues.

How do I ensure that the OpenTelemetry Agent is producing telemetry data?

Change the exporter for the OpenTelemetry SDK to use console instead of the default otlp to show produced telemetry.

You should start seeing logs and metrics being produced:

or metrics:

Spans are only created when instrumented code is executed. If your application is idle, no spans will be generated. Invoke your application's APIs to generate traces.

Example:

If spans do not appear, continue troubleshooting.

1. Instrumentation is not loaded

Verify that OpenTelemetry instrumentation packages are loaded:

Example output:

2. Missing instrumentation

Ensure the frameworks or libraries you want to instrument are supported. If needed, consider adding manual instrumentation.

3. Sampling settings discard traces

Enable the always_on sampler to capture all telemetry:

Which resource attributes are being sent?

Resource attributes provide context, such as service name, host details, and runtime environment.

Using Console logs

Enable console logging as showed earlier, and verify resources are sent:

Using the OpenTelemetry Collector

Another way to inspect telemetry data is by running the OpenTelemetry Collector with a debug exporter.

The command uses the default configuration that comes with the OpenTelemetry Collector and changes the verbosity of the debug logs.
This setup allows you to inspect telemetry data flowing into the Collector.
You can also create a local config.yaml and mount it to the container for advanced configurations.

Remember to configure the exporters to export data to the Collector:

How do I add resource attributes?

Resource attributes can be added through environment variables to provide more context, such as service name, namespace, and runtime details.
This is useful for identifying the source of telemetry signals in complex systems.

For more details, refer to:

• OpenTelemetry's documentation on zero-code auto-instrumentation.