Configuration for server-side observability

This topic explains how to configure the observability plugin for server-side SDKs. The observability plugin collects and sends observability data to LaunchDarkly, so you can review error monitoring, logs, traces, and more from within the LaunchDarkly UI. To get started with the observability plugin, read the observability reference guide for your SDK. Use the docs site navigation, or find your SDK under Observability SDKs. Details about each SDK’s configuration are available in the SDK-specific sections below:

Server-side SDKs

Network requirements

The observability plugin sends OpenTelemetry data to LaunchDarkly at https://otel.observability.app.launchdarkly.com:4318 by default. Port 4318 is the standard OpenTelemetry HTTP/Protobuf port. If your network restricts outbound traffic to port 443, override the OTLP endpoint to use HTTPS on port 443. You have two ways to override the endpoint:

* Use the configuration option for your SDK. For example, in .NET, call WithOtlpEndpoint("https://otel.observability.app.launchdarkly.com:443") when you build the plugin.

* Set the OTEL_EXPORTER_OTLP_ENDPOINT environment variable to https://otel.observability.app.launchdarkly.com:443. This variable works with all server-side SDKs except Java. In Java, use the otlpEndpoint option.

If your application emits OpenTelemetry data locally but none of it appears in LaunchDarkly, check whether your network allows outbound traffic to port 4318. A restrictive firewall is a common cause of missing backend observability data.

Server-side SDKs

This feature is available in the observability plugin for the following server-side SDKs:

.NET (server-side)
Go
Java
Node.js (server-side)
Python
Ruby

.NET (server-side)

Expand .NET (server-side) code sample

You can configure the observability plugin for the .NET (server-side) SDK through a mix of environment variables, OpenTelemetry configuration options, and plugin configuration options.Use the ObservabilityPlugin.ObservabilityPluginBuilder to set the options. In many cases, you can use an OpenTelemetry-specific environment variable instead, if you prefer. For example, if you want to set a custom OTLP endpoint, you can either set OtlpEndpoint in your ObservabilityPlugin.ObservabilityPluginBuilder, or you can set the OTEL_EXPORTER_OTLP_ENDPOINT environment variable.Here’s how:

var builder = WebApplication.CreateBuilder(args);

var config = Configuration.Builder("YOUR_SDK_KEY")
    .Plugins(new PluginConfigurationBuilder()
        .Add(ObservabilityPlugin.Builder(builder.Services)
            .WithServiceName("example-service")
            // we recommend setting service version to the latest deployed git SHA
            .WithServiceVersion("example-sha")
            .Build())).Build();

// Building the LdClient with the Observability plugin. This line will add services to the web application.
var client = new LdClient(config);

// Client must be built before your web application.
var app = builder.Build();

// Global.asax.cs
protected void Application_Start()
{
    // Other application specific code.

    var client = new LdClient(Configuration.Builder("YOUR_SDK_KEY")
        .Plugins(new PluginConfigurationBuilder().Add(ObservabilityPlugin.Builder()
            .WithServiceName("classic-asp-application")
            .Build()))
        .Build());
}

protected void Application_End() {
    Observe.Shutdown();
}

<!-- Web.config -->
<system.webServer>
  // Any existing content should remain and the following should be added.
  <modules>
  <add name="TelemetryHttpModule" type="OpenTelemetry.Instrumentation.AspNet.TelemetryHttpModule,
    OpenTelemetry.Instrumentation.AspNet.TelemetryHttpModule" preCondition="integratedMode,managedHandler" />
  </modules>
</system.webServer>

For a complete list of configuration options, read ObservabilityPlugin.ObservabilityPluginBuilder.

Go

Expand Go code sample

You can configure the observability plugin for the Go SDK through the plugin’s options.Use the functions in the Option type to set the options.Here’s how:

client, _ := ld.MakeCustomClient("YOUR_SDK_KEY",
  ld.Config{
    Plugins: []ldplugins.Plugin{
      ldobserve.NewObservabilityPlugin(
        ldobserve.WithServiceName("example-service"),
        // we recommend setting service version to the latest deployed git SHA
        ldobserve.WithServiceVersion("example-sha"),
      ),
    },
  }, 5*time.Second)

For a complete list of configuration options, read Option.

Java

Expand Java code sample

You can configure the observability plugin for the Java SDK through the plugin’s options. The Java plugin does not read OpenTelemetry environment variables such as OTEL_EXPORTER_OTLP_ENDPOINT or OTEL_SERVICE_NAME, so set these values through the plugin options instead.Use ObservabilityOptions.Builder to set the options.Here’s how:

ObservabilityPlugin plugin = new ObservabilityPlugin(
    new ObservabilityOptions.Builder()
        .serviceName("example-service")
        // we recommend setting serviceVersion to the latest deployed git SHA
        .serviceVersion("example-sha")
        .environment("production")
        .build()
);

This table lists the available options:

Option	Default	Description
`enabled`	`true`	When `false`, the plugin starts no providers, registers no flag evaluation hook, does not fetch sampling configuration, and `LDObserve` methods do nothing.
`serviceName`	Empty	The service name, set as the `service.name` resource attribute.
`serviceVersion`	Empty	The service version, set as the `service.version` resource attribute.
`environment`	Empty	The deployment environment name, set as the `deployment.environment.name` resource attribute.
`otlpEndpoint`	LaunchDarkly endpoint	A custom OTLP/HTTP endpoint.
`backendUrl`	LaunchDarkly endpoint	A custom URL for fetching sampling configuration.
`resourceAttributes`	Empty	Additional resource attributes. These are merged over the plugin’s defaults, which means they can override `service.name` and other default attributes.
`customHeaders`, `customHeader`	None	Headers to send with every OTLP export and sampling configuration request.
`proxySelector`, `proxyHostAndPort`	Java Virtual Machine (JVM) default	An egress proxy for exports and sampling configuration requests.
`logsApiLevel`	`INFO`	The minimum severity of exported logs. `NONE` turns off log export.
`debug`	`false`	Turns on debug logging.
`manualStart`	`false`	Delays provider startup until you call `LDObserve.start(sdkKey, options)`.
`shutdownHook`	`true`	Flushes and stops the providers from a JVM shutdown hook. Set this to `false` when a framework such as Spring Boot manages shutdown, and call `LDObserve.shutdown()` from its close callback.

The OTLP exporters and the sampling configuration request both use java.net.http.HttpClient, so they behave the same way behind an egress proxy. If you do not configure a proxy, the JVM default proxy selector applies. It honors the https.proxyHost, https.proxyPort, and http.nonProxyHosts system properties. To set a proxy or headers explicitly, use proxyHostAndPort and customHeader. To apply per-host proxy rules, pass a java.net.ProxySelector to proxySelector.Here’s how:

new ObservabilityOptions.Builder()
    .proxyHostAndPort("egress.example.com", 3128)
    .customHeader("X-Example-Header", "example-value")
    // export WARN, ERROR, and FATAL logs
    .logsApiLevel(ObservabilityOptions.LogLevel.WARN)
    .build();

The available log levels are TRACE, DEBUG, INFO, WARN, ERROR, FATAL, and NONE, matching the OpenTelemetry severity numbers. The plugin treats a log record with no severity as TRACE.For a complete list of configuration options, read Configuration Options in the plugin README.

Node.js (server-side)

Expand Node.js (server-side) code sample

You can configure the observability plugin for the Node.js (server-side) SDK through a mix of environment variables, OpenTelemetry configuration options, and plugin configuration options.

Environment variables

The environment variables specify where to enable instrumentation:

LAUNCHDARKLY_OTEL_NODE_ENABLE_FILESYSTEM_INSTRUMENTATION enables file system instrumentation. It defaults to false.
LAUNCHDARKLY_OTEL_NODE_ENABLE_OUTGOING_HTTP_INSTRUMENTATION enables outgoing HTTP instrumentation. It defaults to true. It only affects outgoing HTTP requests instrumented by @opentelemetry/instrumentation-http.

OpenTelemetry configuration options

If you are already using OpenTelemetry configuration options for Node in your application, you can continue to use them.When you use the observability plugin, the @opentelemetry/instrumentation-fs instrumentation behaves as follows:

The instrumentation will only be enabled if LAUNCHDARKLY_OTEL_NODE_ENABLE_FILESYSTEM_INSTRUMENTATION is true.
The instruction is unaffected by the OTEL_NODE_ENABLED_INSTRUMENTATIONS and OTEL_NODE_DISABLED_INSTRUMENTATIONS OpenTelemetry environment variables.

Plugin configuration options

To specify the observability plugin configuration options, use the NodeOptions interface to set the options.Here’s how:

const client = init(
  'YOUR_SDK_KEY',
  {
    plugins: [
      new Observability({
        serviceName: 'example-service',
        // we recommend setting serviceVersion to the latest deployed git SHA
        serviceVersion: 'example-sha'
      })
    ]
  }
)

For a complete list of configuration options, read NodeOptions.

Python

Expand Python code sample

You can configure the observability plugin for the Python SDK through a mix of environment variables, OpenTelemetry configuration options, and plugin configuration options.Use the ObservabilityConfig class to set the options. In many cases, you can use an OpenTelemetry-specific environment variable instead, if you prefer. For example, if you want to set a custom OTLP endpoint, you can either set otlp_endpoint in your ObservabilityConfig, or you can set the OTEL_EXPORTER_OTLP_ENDPOINT environment variable.Here’s how:

observability_config = ObservabilityConfig(
  # alternatively, set the OTEL_SERVICE_NAME environment variable
  service_name = "example-service",
  # we recommend setting service_version to the latest deployed git SHA
  service_version = "example-sha"
)

plugin = ObservabilityPlugin(observability_config)

For a complete list of configuration options, read ObservabilityConfig.

Ruby

Expand Ruby code sample

You can configure options for the Ruby observability plugin when you initialize the SDK, or using environment variables.

Plugin configuration options

The plugin constructor accepts optional keyword arguments for configuration.Here’s how:

plugin = LaunchDarklyObservability::Plugin.new(
service_name: 'example-service',
# we recommend setting service_version to the latest deployed git SHA
service_version: 'example-sha'
)

For a complete list of configuration options, read Plugin Options.

Environment variables

The environment variables specify where to enable instrumentation:

LAUNCHDARKLY_SDK_KEY provides the LaunchDarkly SDK key. This key is automatically extracted from the client during initialization.
OTEL_EXPORTER_OTLP_ENDPOINT provides a custom OTLP endpoint.
OTEL_SERVICE_NAME provides the service name, if not specified in plugin options.

Environment configuration is automaticThe environment associated with your SDK key is automatically determined by the backend, so you don’t need to configure it separately.

​Network requirements

​Server-side SDKs

​.NET (server-side)

​Go

​Java

​Node.js (server-side)

​Environment variables

​OpenTelemetry configuration options

​Plugin configuration options

​Python

​Ruby

​Plugin configuration options

​Environment variables

Network requirements

Server-side SDKs

.NET (server-side)

Go

Java

Node.js (server-side)

Environment variables

OpenTelemetry configuration options

Plugin configuration options

Python

Ruby

Plugin configuration options

Environment variables