OpenTelemetry.AutoInstrumentation
1.9.0
Prefix Reserved
dotnet add package OpenTelemetry.AutoInstrumentation --version 1.9.0
NuGet\Install-Package OpenTelemetry.AutoInstrumentation -Version 1.9.0
<PackageReference Include="OpenTelemetry.AutoInstrumentation" Version="1.9.0" />
paket add OpenTelemetry.AutoInstrumentation --version 1.9.0
#r "nuget: OpenTelemetry.AutoInstrumentation, 1.9.0"
// Install OpenTelemetry.AutoInstrumentation as a Cake Addin #addin nuget:?package=OpenTelemetry.AutoInstrumentation&version=1.9.0 // Install OpenTelemetry.AutoInstrumentation as a Cake Tool #tool nuget:?package=OpenTelemetry.AutoInstrumentation&version=1.9.0
Using the OpenTelemetry.AutoInstrumentation NuGet package
When to use the NuGet package
Use the NuGet package in the following scenarios:
- You control the application build but not the machine/container where the application is running.
- Support instrumentation of
self-contained
applications. - Facilitate developer experimentation with automatic instrumentation through NuGet packages.
- Solve version conflicts between the dependencies used by the application and the automatic instrumentation.
Limitations
While NuGet packages are a convenient way to deploy automatic instrumentation, they can't be used in all cases. The most common reasons for not using NuGet packages include the following:
- You can't add the package to the application project. For example, the application is from a third party that can't add the package.
- Reduce disk usage, or the size of a virtual machine, when multiple applications to be instrumented are installed in a single machine. In this case you can use a single deployment for all .NET applications running on the machine.
- A legacy application that can't be migrated to the SDK-style project.
Using the NuGet packages
To automatically instrument your application with
the OpenTelemetry .NET Automatic Instrumentation add
the OpenTelemetry.AutoInstrumentation
package to your project:
dotnet add [<PROJECT>] package OpenTelemetry.AutoInstrumentation
If the application references packages that can be instrumented, but require other packages for the instrumentation to work, the build will fail and prompt you to either add the missing instrumentation package or to skip the instrumentation of the corresponding package:
~packages/opentelemetry.autoinstrumentation.buildtasks/1.1.0/build/OpenTelemetry.AutoInstrumentation.BuildTasks.targets(29,5): error : OpenTelemetry.AutoInstrumentation: add a reference to the instrumentation package 'MongoDB.Driver.Core.Extensions.DiagnosticSources' version 1.3.0 or add 'MongoDB.Driver.Core' to the property 'SkippedInstrumentations' to suppress this error.
To resolve the error either add the recommended instrumentation package or skip
the instrumentation of the listed package by adding it to the SkippedInstrumentation
property. For example:
<PropertyGroup>
<SkippedInstrumentations>MongoDB.Driver.Core;StackExchange.Redis</SkippedInstrumentations>
</PropertyGroup>
The same property can be also specified directly using the terminal.
Notice that the ;
separator needs to be properly escaped as '%3B':
dotnet build -p:SkippedInstrumentations=StackExchange.Redis%3BMongoDB.Driver.Core
To distribute the appropriate native runtime components with your .NET application,
specify a Runtime Identifier (RID)
to build the application using dotnet build
or dotnet publish
. This might
require choosing between distributing a
self-contained or a framework-dependent
application. Both types are compatible with automatic instrumentation.
Use the script in the output folder of the build to launch the application with automatic instrumentation activated.
- On Windows, use
instrument.cmd <application_executable>
- On Linux or Unix, use
instrument.sh <application_executable>
If you launch the application using the dotnet
CLI, add dotnet
after the script.
- On Windows, use
instrument.cmd dotnet <application>
- On Linux and Unix, use
instrument.sh dotnet <application>
The script passes to the application all the command-line parameters you provide.
Learn more about Target Frameworks and .NET Standard.
-
.NETFramework 4.6.2
-
net6.0
- OpenTelemetry.AutoInstrumentation.AspNetCoreBootstrapper (>= 1.9.0)
- OpenTelemetry.AutoInstrumentation.BuildTasks (>= 1.9.0)
- OpenTelemetry.AutoInstrumentation.Loader (>= 1.9.0)
- OpenTelemetry.AutoInstrumentation.Runtime.Managed (>= 1.9.0)
- OpenTelemetry.AutoInstrumentation.Runtime.Native (>= 1.9.0)
- OpenTelemetry.AutoInstrumentation.StartupHook (>= 1.9.0)
NuGet packages (9)
Showing the top 5 NuGet packages that depend on OpenTelemetry.AutoInstrumentation:
Package | Downloads |
---|---|
Splunk.OpenTelemetry.AutoInstrumentation
Splunk Distribution of OpenTelemetry .NET package with all required components to enable automatic instrumentation. |
|
AWS.Distro.OpenTelemetry.AutoInstrumentation
Package Description |
|
AElf.OpenTelemetry
An OpenTelemetry module for use in ABP and Orleans framework. |
|
Highlight.ASPCore
Session replay, error monitoring, logging, and tracing: stop guessing why bugs happen! |
|
VRSPRO.Common.Web
A set of internal generic classes and extensions for working with caches, databases, queues, message brokers, files, reflection, errors, , pagination, collections, strings, and ASP NET CORE. You can use this code in your projects as is. You can copy, modify and distribute it without any restrictions. You do not need to provide any copyrights or references. |
GitHub repositories (1)
Showing the top 1 popular GitHub repositories that depend on OpenTelemetry.AutoInstrumentation:
Repository | Stars |
---|---|
elsa-workflows/elsa-core
A .NET workflows library
|
Version | Downloads | Last updated |
---|---|---|
1.9.0 | 7,286 | 11/6/2024 |
1.8.0 | 30,307 | 9/27/2024 |
1.7.0 | 162,924 | 6/18/2024 |
1.6.0 | 43,504 | 4/29/2024 |
1.5.0 | 51,516 | 4/9/2024 |
1.4.0 | 59,331 | 2/12/2024 |
1.3.0 | 76,222 | 1/18/2024 |
1.2.0 | 48,929 | 11/22/2023 |
1.1.0 | 17,542 | 10/20/2023 |
1.0.2 | 60,998 | 9/27/2023 |
1.0.1 | 2,197 | 9/21/2023 |
1.0.0 | 6,879 | 9/7/2023 |
1.0.0-rc.2 | 18,189 | 8/3/2023 |
1.0.0-rc.1 | 4,277 | 6/27/2023 |