Skip to main content
This topic describes metrics that LaunchDarkly autogenerates from OpenTelemetry events. The LaunchDarkly server SDKs support instrumentation for OpenTelemetry traces. Traces provide an overview of how your application handles requests. For example, traces may show that a feature flag was evaluated for a particular context as part of a given HTTP request. When LaunchDarkly receives OpenTelemetry trace data containing certain span events, it processes and converts the data into metric events that LaunchDarkly metrics track over time. There are two types of events that LaunchDarkly creates from OpenTelemetry traces: route-specific events and global events. Route-specific events are useful when you are experimenting with a change that is known to impact a small subset of your server’s HTTP routes. Global events are useful when you believe your change may impact all routes, or when you are not sure of the impact of your change. To learn more, read OpenTelemetry for server-side SDKs. Autogenerated OpenTelemetry metric events are prefixed with otel. LaunchDarkly generates the following metrics from the events that LaunchDarkly produces from your OpenTelemetry trace data. This trace data includes the feature flag and the context for which you evaluated the flag. You can also create these metrics manually if you wish. These expandable sections explain the metrics that LaunchDarkly autogenerates from OpenTelemetry traces:
Metric kind: Custom conversion binarySuggested analysis unit: UserDefinition: Percent of user units that sent the event where Lower is betterUnits without events: Include units and set the value to 0Description: Measures the percentage of users that encountered an error inside HTTP spans at least once, as reported by OpenTelemetry. Useful when running a guarded rollout.
Metric kind: Custom conversion binarySuggested analysis unit: UserDefinition: Percent of user units that sent the event where Lower is betterUnits without events: Include units and set the value to 0Description: Measures the percentage of users that encountered an HTTP 5XX response at least once, as reported by OpenTelemetry. Useful when running a guarded rollout.
Metric kind: Custom conversion binarySuggested analysis unit: UserDefinition: Percent of user units that sent the event where Lower is betterUnits without events: Include units and set the value to 0Description: Measures the percentage of users that encountered an exception outside of HTTP spans at least once, as reported by OpenTelemetry. Useful when running a guarded rollout.
Metric kind: Custom numericSuggested analysis unit: RequestDefinition: Average event values per request, then compute the Average of those values where Lower is betterUnits without events: ExcludedDescription: Measures the average request latency, as reported by OpenTelemetry. Useful when running a guarded rollout. For best results, use a ‘request’ analysis unit and send ‘request’ contexts.
Metric kind: Custom numericSuggested analysis unit: RequestDefinition: Average event values per request, then compute the P95 of those values where Lower is betterUnits without events: ExcludedDescription: Measures the 95th percentile request latency, as reported by OpenTelemetry. For many applications, this represents the experience for most requests. You can adjust the percentile to fit your application’s needs. Useful when running a guarded rollout. For best results, use a ‘request’ analysis unit and send ‘request’ contexts.
Metric kind: Custom numericSuggested analysis unit: RequestDefinition: Average event values per request, then compute the P99 of those values where Lower is betterUnits without events: ExcludedDescription: Measures the 99th percentile request latency, as reported by OpenTelemetry. For many applications, this represents the worst-case experiences. You can adjust the percentile to fit your application’s needs. Useful when running a guarded rollout. For best results, use a ‘request’ analysis unit and send ‘request’ contexts.