Recording metrics | LaunchDarkly

The observability plugin provides different functions depending on what kind of data you want to record.

The recorded data is available as an $ld:telemetry:metric event. To learn more, read Observability autogenerated metrics.

You can view all metrics sent to LaunchDarkly under Metrics in the LaunchDarkly user interface. To learn more, read Metrics.

How metrics are aggregated and exported

The observability SDK plugins use the OpenTelemetry SDK to aggregate and export metrics. Understanding when and how metrics are aggregated can help you tune performance and interpret metric data correctly.

Aggregation temporality

All LaunchDarkly observability SDKs use cumulative aggregation temporality, which is the OpenTelemetry SDK default. This means each export includes the cumulative value since the SDK was initialized, rather than a delta since the last export. LaunchDarkly’s backend handles the conversion to display rate-based or windowed views in the UI.

How metrics roll up

Metrics with the same name and identical attribute sets are automatically aggregated by the OpenTelemetry SDK before export. The aggregation strategy depends on the instrument type:

Metric type	OTel instrument	Aggregation
`recordMetric` / `recordGauge`	Gauge	Last value wins
`recordCount`	Counter	Sum of all recorded values
`recordIncr`	Counter	Sum of increments
`recordHistogram`	Histogram	Distribution (bucket counts, sum, min, max)
`recordUpDownCounter`	UpDownCounter	Net sum (increments and decrements)

This means if you record two recordCount calls with the name "page-views" and the same attributes within a single export interval, the SDK exports a single aggregated data point with the sum of both values.

To learn more, read the OpenTelemetry documentation about the Metrics Data Model.

Export intervals by SDK

Each SDK periodically flushes aggregated metrics to LaunchDarkly. The export interval varies by SDK:

SDK	Metrics export interval	Traces/logs export interval
JavaScript (browser)	30 seconds	30 seconds
Node.js (server-side)	5 seconds	5 seconds
Python	5 seconds	5 seconds
Go	5 seconds	1 second (traces)
.NET (server-side)	5 seconds	5 seconds
Ruby	60 seconds	1 second
React Native	10 seconds	500 milliseconds
Android	10 seconds	1 second

Browser SDKs use longer intervals

Client-side browser SDKs use a 30-second export interval to reduce network overhead for end users. Server-side SDKs use shorter intervals (typically 5 seconds) for more real-time visibility. These intervals are not currently configurable through the plugin options.

Using exemplars to link traces and sessions

LaunchDarkly stores references from a recorded measurement back to the trace or session that produced it. These references are called exemplars, and you can overlay them on a metric graph to open the span or session replay behind a given metric value. To learn more, read Metric exemplars.

There is no exemplar setting to configure, and you do not need to construct an OpenTelemetry MeterProvider of your own. The plugin owns the meter, and LaunchDarkly attaches whichever references are available when it ingests the metric. What you control is whether those references exist:

Session references are automatic, but require session replay in addition to observability. The browser, Android, and React Native plugins tag every metric they record with the current session identifier, and session replay creates the session that reference points to. The iOS plugin does not add a session identifier to metrics. Also, server-side metrics do not carry a session identifier unless your service receives one from the client that originated the request.
Trace references require that your application record the measurement inside an active span. Because the OpenTelemetry SDK samples the reference from the active context at the time of the measurement, a metric recorded outside of a span arrives with no trace reference. To learn more about creating spans, read Recording traces.

Trace references are the standard OpenTelemetry exemplar mechanism rather than a LaunchDarkly feature, so their availability and configuration depend on the OpenTelemetry SDK for your language. To learn more, read the OpenTelemetry documentation on exemplar filters and reservoirs.

Details about each SDK’s configuration are available in the SDK-specific sections below.

Client-side SDKs

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

iOS

Expand iOS code sample

When you record a metric with the observability plugin, it must include a name and value. Optionally, it can include attributes and a timestamp. To construct the attributes, use Attributes from the @opentelemetry/api.

Here are the options for recording metrics:

1   LDObserve.shared.recordMetric(metric: .init(name: "elapsedTimeMs", value: 2200))

To learn more, read Observe.

Android

Expand Android code sample

Here are the options for recording metrics:

1   LDObserve.recordMetric(Metric("elapsedTimeMs", 2200))

To learn more, read LDObserve.

JavaScript

Expand JavaScript code sample

Here are the options for recording metrics:

1 const onClick = () => {
2   const start = Date.now();
3   doInterestingWork();
4   const elapsed = Date.now() - start;
5   LDObserve.recordGauge({name: "elapsedTimeMs", value: elapsed});
6 };

To learn more, read Observe.

React Native

Expand React Native code sample

Here are the options for recording metrics:

1   LDObserve.recordMetric({name: "elapsedTimeMs", value: 2200});

To learn more, read Observe.

React Web

To record metrics with the React Web SDK, follow the example for JavaScript.

Vue

To record metrics with the Vue SDK, follow the example for JavaScript.

Server-side SDKs

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

.NET (server-side)

Expand .NET (server-side) code sample

Here are the options for recording metrics:

1   Observe.RecordMetric(name, value, attributes);

To learn more, read Observe.

Go

Expand Go code sample

To record a metric, pass the Go context.Context, as well as the name, value, and optional attributes of the metric to the appropriate Record* function. For example, you might want to record the value for a point-in-time measurement, such as the current CPU utilization percentage, or for a counter, such as the number of cache hits. The optional attributes may include any attributes from the OpenTelemetry specification.

Metrics with the same name and attributes are aggregated using the OpenTelemetry SDK. To learn more, read the OTel documentation on the Metrics Data Model.

Here are the options for recording metrics:

1   ldobserve.RecordMetric(ctx, "example-metric-name", 3.7)

To learn more, read RecordMetric, RecordCount, and RecordHistogram.

Node.js (server-side)

Expand Node.js (server-side) code sample

To record a metric, first create the metric within your application. The Metric interface includes a name, value, and optional tags. For example, you might create a metric for a point-in-time measurement, such as the current CPU utilization percentage, or for a counter, such as the number of cache hits.

Values with the same metric name and attributes are aggregated using the OpenTelemetry SDK. To learn more, read the OTel documentation on the Metrics Data Model.

Create OTel metric

1 const metric = {
2   name: "exampleMetric",
3   value: 42
4 }

Here are the options for recording metrics:

1   LDObserve.recordMetric(metric);

To learn more, read Observe.

Python

Expand Python code sample

To record a metric, pass the name, value, and optional attributes to the appropriate record_* function. For example, you might want to record the value for a point-in-time measurement, such as the current CPU utilization percentage, or for a counter, such as the number of cache hits. The optional attributes may include any attributes from the OpenTelemetry specification.

Metrics with the same name and attributes are aggregated using the OpenTelemetry SDK. To learn more, read the OTel documentation on the Metrics Data Model.

Here are the options for recording metrics:

1   observe.record_metric("example-metric-name", 3.7)

To learn more, read ldobserve.