OpenTelemetry in server-side SDKs
Overview
This topic explains how to enable OpenTelemetry in server-side SDKs.
Looking for information on OpenTelemetry in client-side SDKs?
For information on using OpenTelemetry in LaunchDarkly’s client-side SDKs, read OpenTelemetry in client-side SDKs.
About OpenTelemetry
OpenTelemetry (OTel) is an open source observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logs. You can use LaunchDarkly’s OpenTelemetry protocol (OTLP) endpoint to send OpenTelemetry traces to LaunchDarkly.
We recommend enabling OpenTelemetry in LaunchDarkly server-side SDKs if you use LaunchDarkly’s Observability, Experimentation, or Guarded rollouts features, or if you use third-party observability tools that support the OpenTelemetry framework.
Because OpenTelemetry is vendor- and tool-agnostic, you can reuse the instrumentation that may already exist in your code to create LaunchDarkly metrics without changing application code.
Viewing OpenTelemetry data in LaunchDarkly
In the LaunchDarkly UI, OpenTelemetry data is used in the Observability, Experimentation, and Guarded rollouts features.
OpenTelemetry metrics, logs, and traces are available in the Observability features.
OpenTelemetry traces generate LaunchDarkly metrics, which are available in the Experimentation and Guarded rollouts features. Specifically, when LaunchDarkly receives OpenTelemetry trace data, it processes and converts this data into events that LaunchDarkly metrics track over time. When trace data contains spans that carry both metrics and feature flag evaluation events, LaunchDarkly correlates these and uses the result to power guarded rollouts. To learn more, read Metrics autogenerated from OpenTelemetry data.
Sending OpenTelemetry data to LaunchDarkly
To configure and send OpenTelemetry data to LaunchDarkly when you are using LaunchDarkly server-side SDKs:
- (Optional) Add flag evaluation information to OpenTelemetry spans in your application. To learn how, read the section for your SDK under Server-side SDKs, below.
- This step is optional but highly recommended, as it means that flag-specific details are available when you review your OTel data in the LaunchDarkly UI.
- You might choose to skip this step, at least temporarily, if you have already instrumented OpenTelemetry in your application and only want to send your existing OTel data to LaunchDarkly.
- Configure your application or OpenTelemetry collector to use LaunchDarkly’s OTel endpoints:
- For HTTP, use
https://otel.observability.app.launchdarkly.com:4318
orhttps://otel.observability.app.launchdarkly.com:443
- For gRPC, use
https://otel.observability.app.launchdarkly.com:4317
. - You may need to update your infrastructure to make sure your application can reach this domain. To learn more, read Accessing LaunchDarkly by domain.
- For HTTP, use
- (Optional) Include your LaunchDarkly SDK key as a resource attribute in your telemetry data.
- This step is required if you are using OpenTelemetry SDKs. To learn how, read Setting resource attributes, below.
- This step is not required if you are using LaunchDarkly server-side SDKs. If you use LaunchDarkly SDKs, this is set automatically.
- Send the OpenTelemetry data to LaunchDarkly. LaunchDarkly supports traces, metrics, and logs. Only traces data generates LaunchDarkly metrics. You can view metrics and logs in the LaunchDarkly UI when you use the Observability features.
- You can use the OpenTelemetry Collector to pre-filter and aggregate this data. To learn how, read Configuring the collector, below.
- Alternatively, you can send data directly from your application using OpenTelemetry SDKs.
Setting resource attributes
Expand Setting resource attributes
If you use LaunchDarkly SDKs, resource attributes are set automatically. You do not need set the resource attributes yourself, and you can skip this section.
If you use only OpenTelemetry SDKs, you must include your LaunchDarkly SDK key as a resource attribute in your telemetry data, so that the data is correctly associated with your LaunchDarkly project and environment. You have several options for how to set the resource attribute.
To set the resource attribute using an environment variable, use the OTEL_RESOURCE_ATTRIBUTES
environment variable:
To set the resource attribute in your OpenTelemetry collector configuration, use the resource
processor:
For a complete example of a collector configuration, read Configuring the collector, below.
To set the resource attribute programmatically in your application code, use the OpenTelemetry resource available for your language. Here are a few examples:
Configuring the collector
Expand Configuring the collector
To configure a pipeline to send trace data to LaunchDarkly, modify the collector’s config file, otel-collector-config.yaml
, as follows:
Server-side SDKs
LaunchDarkly processes metrics, logs, and traces from your OpenTelemetry data:
- LaunchDarkly processes OpenTelemetry metrics and logs and displays them in the LaunchDarkly UI under Observability
- LaunchDarkly processes two types of data from OpenTelemetry traces:
- HTTP span attributes, including latency, 5xx occurrences, and other errors, where the span has or overlaps with another span that has at least one feature flag span event. This includes nested spans.
- Exception span events that occur after a feature flag span event on the same trace. If the exception occurs before the feature flag event, LaunchDarkly does not capture it.
A feature flag span event is defined as any span event that contains a feature_flag.context.key
attribute. LaunchDarkly ignores traces that do not include span events with this attribute.
In most server-side SDKs, the OTel traces are specific to the LaunchDarkly project and environment that you specify in the collector configuration, described above. In the .NET (server-side) and Node.js (server-side) SDKs, you can provide the LaunchDarkly client-side ID in the tracing hook. This enables you to send traces for multiple projects and environments using one collector.
The following sections describe, for each supported SDK, how to ensure your spans have compatible feature flag events.
Sending feature flag event data requires feature flag evaluation
The OpenTelemetry tracing hook automatically attaches feature flag event data to your OTel traces for you. Feature flag event data, including the feature_flag.context.key
attribute, is only generated when your application uses the LaunchDarkly SDK to evaluate a feature flag.
This feature is available in the following SDKs:
.NET (server-side)
Expand .NET (server-side) code sample
To add flag evaluation information to OpenTelemetry spans, first add the Telemetry package from NuGet:
Next, import the LaunchDarkly.Sdk.Server.Hooks
and LaunchDarkly.Sdk.Server.Telemetry
namespaces. Then you can create a new tracing hook and reference it in the configuration options when you initialize the SDK client.
Here’s how:
When this configuration is set, the SDK adds span events for each call to a *Variation*
method to your active span. The span event information contains details of each flag evaluation, including the flag key and the context key. You can collect this information in Guarded rollouts or other observability tools.
Optionally, you can configure the tracing hook to:
- create new spans that contain span events with flag evaluation information, rather than adding the events to the active span. The new spans are nested in the current active span, and are not active.
- include the flag’s evaluated flag value in the span event.
Here’s how:
Starting with v1.1 of the LaunchDarkly.Sdk.Server.Hooks
package, which requires v8.7+ of the .NET (server-side) SDK, LaunchDarkly automatically decorates any OpenTelemetry spans with project and environment information.
When you create the hook, you can optionally pass in a client-side ID to specify the environment. Use the builder’s .EnvironmentId()
method and pass in the client-side ID. To learn more about client-side IDs, read Keys.
Because LaunchDarkly automatically decorates the OpenTelemetry spans, you should not need to call this method explicitly. The exception is if you are using persistent stores, in which case you must either call .EnvironmentId()
or use the single-environment OpenTelemetry Collector configuration to ensure that your OpenTelemetry spans have correct project and environment information.
Here’s how:
In the .NET (server-side) SDK, the tracing hook is implemented using Microsoft’s System.Diagnostics APIs. Therefore, some of the terminology it uses differs from the OpenTelemetry standard. For example, the tracing hook in the .NET (server-side) SDK uses the method CreateActivities()
, rather than CreateSpans()
, to enable child spans.
To learn more, read TracingHookBuilder
and ConfigurationBuilder
.
Go
Expand Go code sample
To add flag evaluation information to OpenTelemetry spans, import the ldhooks
package. Then, create a new tracing hook and reference it in the configuration options when you initialize the SDK client.
Here’s how:
When this configuration is set, the SDK adds span events for each call to a *Variation*Ctx
method to your active span.
The span event information contains details of each flag evaluation, including the flag key and the context key. You can collect this information in Guarded rollouts or other observability tools.
The *Variation*Ctx
methods are the same as the *Variation*
methods, except that they also require a Go context. For example, BoolVariationCtx
and BoolVariationDetailCtx
are the same as the BoolVariation
and BoolVariationDetail
methods, except that they also require a Go context. This Go context is used in the hook implementation. If you are using hooks, you must update your variation calls to use the Ctx
methods.
Optionally, you can configure the tracing hook to:
- create new spans that contain span events with flag evaluation information, rather than adding the events to the active span. The new spans are nested in the current active span, and are not active.
- include the flag’s evaluated flag value in the span event.
Here’s how:
To learn more, read Config
.
Java
Expand Java code sample
To add flag evaluation information to OpenTelemetry spans, import the LaunchDarkly Java Otel Hook package. Then, create a new tracing hook and reference it in the configuration options when you initialize the SDK client.
Here’s how:
When this configuration is set, the SDK adds span events for each call to a *Variation*
method to your active span. The span event information contains details of each flag evaluation, including the flag key and the context key. You can collect this information in Guarded rollouts or other observability tools.
Optionally, you can configure the tracing hook to:
- create new spans that contain span events with flag evaluation information, rather than adding the events to the active span. The new spans are nested in the current active span, and are not active.
- include the flag’s evaluated flag value in the span event.
Here’s how:
To learn more, read LDConfig.Builder
.
Node.js (server-side)
Expand Node.js (server-side) code sample
To add flag evaluation information to OpenTelemetry spans, import the TracingHook
package. Then, create a new tracing hook and reference it in the configuration options when you initialize the SDK client.
Here’s how:
When this configuration is set, the SDK adds span events for each call to a *Variation*
method to your active span. The span event information contains details of each flag evaluation, including the flag key and the context key. You can collect this information in Guarded rollouts or other observability tools.
Optionally, you can configure the tracing hook to:
- create new spans that contain span events with flag evaluation information, rather than adding the events to the active span. The new spans are nested in the current active span, and are not active.
- include the flag’s evaluated flag value in the span event.
Here’s how:
Starting with v1.2 of the @LaunchDarkly/node-server-sdk-otel
package, which requires v9.9+ of the Node.js (server-side) SDK, LaunchDarkly automatically decorates any OpenTelemetry spans with project and environment information.
When you create the hook, you can optionally pass in a client-side ID to specify the environment. Use the environmentId
option when you create the new TracingHook
. To learn more about client-side IDs, read Keys.
Because LaunchDarkly automatically decorates the OpenTelemetry spans, you should not need to set this option explicitly. The exception is if you are using persistent stores, in which case you must either set the environmentId
or use the single-environment OpenTelemetry Collector configuration to ensure that your OpenTelemetry spans have correct project and environment information.
Here’s how:
To learn more, read LDOptions
.
Python
Expand Python code sample
To add flag evaluation information to OpenTelemetry spans, first install the package:
Next, import Hook
and HookOptions
from the package. Then you can create a new tracing hook and reference it in the configuration options when you initialize the SDK client.
Here’s how:
When this configuration is set, the SDK adds span events for each call to a *variation*
method to your active span. The span event information contains details of each flag evaluation, including the flag key and the context key. You can collect this information in Guarded rollouts or other observability tools.
Optionally, you can configure the tracing hook to:
- create new spans. The new spans are nested in the current active span, and are not active. The span events with flag evaluation information are still added to the parent span.
- include the flag’s evaluated flag value in the span event.
Here’s how:
To learn more, read Config
.
Ruby
Expand Ruby code sample
To add flag evaluation information to OpenTelemetry spans, first install the gem:
Then, you can create a new tracing hook and reference it in the configuration options when you initialize the SDK client.
Here’s how:
When this configuration is set, the SDK adds span events for each call to a *Variation*
method to your active span. The span event information contains details of each flag evaluation, including the flag key and the context key. You can collect this information in Guarded rollouts or other observability tools.
Optionally, you can configure the tracing hook to:
- create new spans. The new spans are nested in the current active span, and are not active. The span events with flag evaluation information are still added to the parent span.
- include the flag’s evaluated flag value in the span event.
Here’s how:
To learn more, read Config
.