Send traces to Cloud Observability with .NET

• Be sure to set the LS_ACCESS_TOKEN environment variable Cloud Observability access token before running your application: export LS_ACCESS_TOKEN=<LS_ACCESS_TOKEN>.
• AddOtlpExporter sets up OpenTelemetry to send data to Cloud Observability using the OpenTelemetry Protocol (OTLP). I recommend sticking with OTLP in your clients.
• SetResourceBuilder creates resources: key-value pairs which describe your service. It’s important to add as many relevant resources as you can, as this improves the quality of your tracing data. See Semantic Conventions for ideas on what to add. The two that are most important to add are service.name and service.version. If you don’t name your service, it will get named unknown_service by default.
• AddAspNetCoreInstrumentation() enables .NET Core instrumentation. This does not apply to Console applications.
• AddHttpClientInstrumentation() enables instrumentation for HTTP requests. If you want to instrument gRPC requests instead, use AddGrpcClientInstrumentation().

It is important to add instrumentation for every supported library. You can find all of the available instrumentation here.

To use HTTP instead of gRPC, the AddOtlpExporter configuration would be altered as follows:

1
2
3
4
5
6
7
8
9
10
.AddOtlpExporter(opt =>
{
	opt.Endpoint = new Uri("https://ingest.lightstep.com/traces/otlp/v0.9"); //US data center
	// opt.Endpoint = new Uri("https://ingest.eu.lightstep.com/traces/otlp/v0.9"); //EU data center
	opt.Headers = new Metadata
	{
		{ "lightstep-access-token", Environment.GetEnvironmentVariable("LS_ACCESS_TOKEN")}
	};
	opt.Credentials = new SslCredentials();
})

More info on using OtlpExportProtocol.HttpProtobuf can be found here.

If you wish to use an OpenTelemetry Collector, the configuration for AddOtlpExporter would look like this:

1
2
3
4
5
6
...
.AddOtlpExporter(opt =>
{
	opt.Endpoint = new Uri("http://0.0.0.0:4317");
})
...

1
2
3
4
5
6
7
...
.AddOtlpExporter(opt =>
{
	opt.Protocol = OtlpExportProtocol.HttpProtobuf;
	opt.Endpoint = new Uri("http://0.0.0.0:4318/v1/traces");
})
...

End code tabs

Symptom
Operation names in Cloud Observability are not clear or are very long and unhelpful.

This feature requires a Satellite upgrade to the June 2020 release.

This can happen because the auto-installer is getting the name from a parameter in Datadog that might not be appropriate for your language. You can set that parameter to different values to see if that results in better operation names.

You can use either the resource or the name parameter, or both.

Which to use (or if using the both, the order to use) depends on the language of the installer. Refer to the Datadog docs for more info.

To configure how the operation name is set, add the following parameter to your Microsatellite configuration:

1
2
3
4
5
receivers:
  datadog:
	operation_name_extractors:
  	  - resource
  	  - name

If you set both, the order of the values matters. Cloud Observability tries to extract a name from the first variable value. If one isn’t found, it looks for the second value and uses that.

If multiple versions of OpenTelemetry are installed, traces are not created or propagated correctly. Check your dependencies to ensure that only a single version of OpenTelemetry is installed.

Cloud Observability’s public Microsatellites only accept spans via a secure endpoint. If you see security related errors (e.g., Netty TLS errors with Java), you may not have the necessary root certificate installed on the machine where the tracer is running. To add a root certificate, see the documentation about encrypted connections.

Not seeing metrics come through the OpenTelemetry Collector? Make sure that you have defined a Metrics pipeline in your Collector’s YAML config file.