Available instrumentations

The OpenTelemetry .NET Automatic Instrumentation supports a wide variety of libraries.

Instrumentations

All instrumentations are enabled by default for all signal types (traces, metrics, and logs).

You can disable all instrumentations for a specific signal type by setting the OTEL_DOTNET_AUTO_{SIGNAL}_INSTRUMENTATION_ENABLED environment variable to false.

For a more granular approach, you can disable specific instrumentations for a given signal type by setting the OTEL_DOTNET_AUTO_{SIGNAL}_{0}_INSTRUMENTATION_ENABLED environment variable to false, where {SIGNAL} is the type of signal, for example TRACES, and {0} is the case-sensitive name of the instrumentation.

Traces instrumentations

Status: Mixed. Traces are stable, but particular instrumentation libraries are in Experimental status due to lack of stable semantic convention.

[1]: Generic ADO.NET instrumentation that covers DbCommand methods. It covers only implementations for overridden methods. Typically, a lot of implementations utilize the new C# keyword; such cases need specific implementations. This instrumentation does not cover libraries covered by specific instrumentations such as SQLCLIENT, NPGSQL, MYSQLDATA, MYSQLCONNECTOR, ORACLEMDA, or SQLITE.

[2]: Supports System.Data.Common (≥4.0.0 and <12.0.0), System.Data for .NET Framework (≥2.0.0 and <5.0.0), and netstandard (≥2.0.0 and <3.0.0).

[3]: Only integrated pipeline mode is supported.

[4]: ASP.NET (.NET Framework) MVC / WebApi is not supported on ARM64.

[5]: Azure. prefixed packages, released after October 1, 2021.

[6]: Elastic.Clients.Elasticsearch version ≥8.0.0 and <8.10.0. Version ≥8.10.0 is supported by Elastic.Transport instrumentation.

[7]: Confluent.Kafka is supported from version ≥1.8.2 on ARM64 for Windows and Linux, and ≥1.9.2 on macOS.

[8]: MongoDB.Driver needs bytecode instrumentation only for < 3.7.0 versions; 3.7.0+ uses only source instrumentation.

[9]: RabbitMq.Client needs bytecode instrumentation only for 5.* and 6.* versions, 7.0.0+ uses only source instrumentation.

[10]: System.Data.SqlClient is deprecated.

[11]: Microsoft.Data.SqlClient v3.* is not supported on .NET Framework, due to issue. System.Data.SqlClient is supported from version 4.8.5.

[12]: Bytecode instrumentation is used only for context propagation, configurable by OTEL_DOTNET_EXPERIMENTAL_SQLCLIENT_ENABLE_TRACE_CONTEXT_PROPAGATION.

[13]: StackExchange.Redis versions ≥2.6.122 and <4.0.0 are supported on .NET, and versions ≥2.6.122 and <3.0.0 are supported on .NET Framework.

[14]: Bytecode instrumentation is used only for context propagation, configurable by OTEL_DOTNET_AUTO_NPGSQL_CONTEXT_PROPAGATION.

[15]: Quartz versions ≥3.4.0 and <4.0.0 are supported, but support for Quartz 3.x is deprecated. Versions ≥4.0.0 are supported on .NET 10+ only.

Metrics instrumentations

Status: Mixed. Metrics are stable, but particular instrumentation are in Experimental status due to lack of stable semantic convention.

[1]: The ASP.NET metrics are generated only if the AspNet trace instrumentation is also enabled.

[2]: System.Data.SqlClient is deprecated.

[3]: Microsoft.Data.SqlClient v3.* is not supported on .NET Framework, due to issue. System.Data.SqlClient is supported from version 4.8.5.

Logs instrumentations

Status: Experimental.

[1]: For ASP.NET Core applications, the LoggingBuilder instrumentation can be enabled without using the .NET CLR Profiler by setting the ASPNETCORE_HOSTINGSTARTUPASSEMBLIES environment variable to OpenTelemetry.AutoInstrumentation.AspNetCoreBootstrapper.

[2]: Instrumentation provides both trace context injection and logs bridge.

Instrumentation options

[1]: This feature is supported only by packages 23.26.200 and newer. It also requires an Oracle AI Database 26ai server.

[2]: Enables IL rewriting of SqlCommand on .NET Framework to ensure CommandText is present for SqlClient instrumentation, which is required for db.query.text and db.query.summary to be populated. Previously, CommandText was only available for stored procedures. With this setting enabled, it is also available for raw queries. This changes the behavior of events emitted by the SqlEventSource, which might impact other parts of the application if this mechanism is used.

[3]: The OpenTelemetry Collector Contrib PostgreSQL receiver exposes the value as postgresql.application_name on its db.server.query_sample event. Query-sample collection is disabled by default and requires pg_monitor; see the pinned receiver configuration. Propagation executes SET application_name through Npgsql’s synchronous ExecuteInternalCommand path before each traced operation. Npgsql flushes that command and waits for its CommandComplete and ReadyForQuery responses, so propagation adds one database round trip per traced operation. It does not alter, prefix, or combine the application’s SQL. As Npgsql ends the user action, while it still owns the connector, the instrumentation executes RESET application_name through the same path. This adds one cleanup round trip per propagated operation and resets the value to the session default configured when the connection was opened before control returns to the caller or the connector can be used for another operation. PostgreSQL RESET does not restore a value assigned later with SET; enabling this option can therefore overwrite changes made by application code to application_name at runtime. See Npgsql’s EndUserAction lifecycle. These internal commands use PostgreSQL’s Simple Query flow, which discards the previous unnamed statement and portal; Npgsql’s explicitly prepared and automatically prepared statements are named and remain associated with the physical connection. See the PostgreSQL extended-query protocol rules and Npgsql’s prepared-statement documentation. Because SET and RESET are real PostgreSQL statements, an observer polling during their short execution can theoretically sample them. Cleanup is deferred while a transaction is failed so that ROLLBACK can run first, then executed as the recovery action ends successfully. Npgsql 10+ COPY operations are covered through its TraceCopyStart lifecycle. Multiplexing is not supported: application_name is physical-session state, while Npgsql can write multiple logical commands to the same connector in one multiplexing loop. The instrumentation safely skips propagation and logs one warning when it detects a multiplexed connector.