Manual Instrumentation
Manual instrumentation is the process of adding observability code to your application.
A note on terminology¶
.NET is different from other languages/runtimes that support OpenTelemetry. The
Tracing API is implemented by the
System.Diagnostics
API, repurposing existing constructs like ActivitySource
and Activity
to be
OpenTelemetry-compliant under the covers.
However, there are parts of the OpenTelemetry API and terminology that .NET
developers must still know to be able to instrument their applications, which
are covered here as well as the System.Diagnostics
API.
If you prefer to use OpenTelemetry APIs instead of System.Diagnostics
APIs,
you can refer to the OpenTelemetry API Shim docs for tracing.
Initializing tracing¶
There are two main ways to initialize tracing, depending on whether you're using a console app or something that's ASP.NET Core-based.
Console app¶
To start tracing in a console app, you need to create a tracer provider.
First, ensure that you have the right packages:
And then use code like this at the beginning of your program, during any important startup operations.
This is also where you can configure instrumentation libraries.
Note that this sample uses the Console Exporter. If you are exporting to another endpoint, you'll have to use a different exporter.
ASP.NET Core¶
To start tracing in an ASP.NET Core-based app, use the OpenTelemetry extensions for ASP.NET Core setup.
First, ensure that you have the right packages:
Then you can install the Instrumentation package
Note that the --prerelease
flag is required for all instrumentation packages
because they are all dependent on naming conventions for attributes/labels
(Semantic Conventions) that aren't yet classed as stable.
Next, configure it in your ASP.NET Core startup routine where you have access to
an IServiceCollection
.
This is also where you can configure instrumentation libraries.
Note that this sample uses the Console Exporter. If you are exporting to another endpoint, you'll have to use a different exporter.
Setting up an ActivitySource¶
Once tracing is initialized, you can configure an
ActivitySource
, which will be how you
trace operations with Activity
s.
Typically, an ActivitySource
is instantiated once per app/service that is
being instrumented, so it's a good idea to instantiate it once in a shared
location. It is also typically named the same as the Service Name.
You can instantiate several ActivitySource
s if that suits your scenario,
although it is generally sufficient to just have one defined per service.
Creating Activities¶
To create an Activity
, give it a name
and create it from your
ActivitySource
.
Creating nested Activities¶
If you have a distinct sub-operation you'd like to track as a part of another one, you can create activities to represent the relationship.
When you view spans in a trace visualization tool, ChildActivity
will be
tracked as a nested operation under ParentActivity
.
Nested Activities in the same scope¶
You may wish to create a parent-child relationship in the same scope. Although
possible, this is generally not recommended because you need to be careful to
end any nested Activity
when you expect it to end.
In the preceding example, childActivity
is ended because the scope of the
using
block is explicitly defined, rather than scoped to DoWork
itself like
parentActivity
.
Creating independent Activities¶
The previous examples showed how to create Activities that follow a nested hierarchy. In some cases, you'll want to create independent Activities that are siblings of the same root rather than being nested.
Creating new root Activities¶
If you wish to create a new root Activity, you'll need to "de-parent" from the current activity.
Get the current Activity¶
Sometimes it's helpful to access whatever the current Activity
is at a point
in time so you can enrich it with more information.
Note that using
is not used in the prior example. Doing so will end current
Activity
, which is not likely to be desired.
Add tags to an Activity¶
Tags (the equivalent of
Attributes
in OpenTelemetry) let
you attach key/value pairs to an Activity
so it carries more information about
the current operation that it's tracking.
We recommend that all Tag names are defined in constants rather than defined inline as this provides both consistency and also discoverability.
Adding events¶
An event is a human-readable
message on an Activity
that represents "something happening" during its
lifetime.
Events can also be created with a timestamp and a collection of Tags.
Adding links¶
An Activity
can be created with zero or more
ActivityLink
s that are causally
related.
Set Activity status¶
A status can be set on an
activity, typically used to specify that an activity has not completed
successfully - ActivityStatusCode.Error
. In rare scenarios, you could override
the Error
status with Ok
, but don't set Ok
on successfully-completed
spans.
The status can be set at any time before the span is finished:
Next steps¶
After you've set up manual instrumentation, you may want to use instrumentation libraries. As the name suggests, they will instrument relevant libraries you're using and generate spans (activities) for things like inbound and outbound HTTP requests and more.
You'll also want to configure an appropriate exporter to export your telemetry data to one or more telemetry backends.
You can also check the automatic instrumentation for .NET, which is currently in beta.