Send OpenTelemetry Metrics to Sazabi

Last verified on Nov 8, 2026.

Metrics get their own source because Sazabi routes them to a separate intake path. The general OpenTelemetry source stores logs and traces and does not store metrics, so a service that exports all three signals needs this one as well.

What a metric record looks like in Sazabi

OpenTelemetry defines a metric as a measurement captured at runtime. Sazabi turns every data point of that measurement into a log record with structured fields: metric.name, metric.type, metric.unit and metric.value.

Histograms and summaries add metric.count, metric.sum, metric.min and metric.max. A histogram is a client-side aggregation of values such as request latencies, so one record describes many requests.

Because the data lands as records, you search it the way you search logs. Start a thread and search for metric.name to confirm data points are queryable.

Example: reading a latency histogram

This is an example record for a latency histogram. The values are made up to show the shape.

metric.name   = http.server.request.duration
metric.type   = histogram
metric.unit   = s
metric.count  = 1840
metric.sum    = 212.4
metric.min    = 0.004
metric.max    = 6.3
service.name  = checkout-api

The mean for this export window is metric.sum divided by metric.count, which is about 0.115 seconds. The max of 6.3 seconds is the more interesting number. A mean that looks fine next to a max that large usually means a small group of slow requests, and the trace source is the next place to look. Take the service name and the time window to the OpenTelemetry traces source and search for spans in that window.

Setting it up

Enable the metrics component of the OpenTelemetry SDK you already use, then set two variables where the process starts:

OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=<your intake URL>
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf

Set the metrics-specific variable rather than the general one. That keeps logs and traces free to use a different endpoint. OpenTelemetry's exporter specification says a per-signal endpoint takes precedence and is used exactly as written, so paste the whole intake URL.

If you run the Collector instead, add a prometheus or hostmetrics receiver and an otlphttp exporter. The Collector page covers the logs and traces side of the same deployment. Restart or redeploy afterward so the variables take effect.

Plan for record volume

One data point is one record, so volume follows from three numbers: how many series you emit, how many distinct attribute values each metric carries and how often you export. The SDK default export interval is 60000 milliseconds, which is once a minute.

As an example, 200 series exported every minute produce 12,000 records an hour. Give each of those 200 series an attribute with 50 distinct values and the same hour can produce up to 600,000. Keep attributes to values with bounded variety, such as route names and status classes, and leave out user IDs and request IDs. If you already export metrics that a log line or a span duration could replace, drop them.

Register the source from the CLI

If you prefer a terminal, create the source and print its URL:

sazabi log-sources create otel_metrics --mode manual

The URL has your public key embedded in its hostname, so it works as the credential. Keep it in an environment variable or a secret store, and commit only configuration that references it.

Metrics earn their place when they answer a question the logs can't. A counter of queue depth or a histogram of request time is much smaller than the log lines it summarizes. If a metric only restates something you already log, the log line usually carries more context.

Troubleshooting

• No records after a redeploy. Confirm the variable is set in the process that runs your app, not only in a build step. Look for SDK initialization errors in application output.
• Logs and traces arrive but metrics do not. You set only the general endpoint variable.
• Histogram fields are missing. Check that your SDK version exports those fields in OTLP.

Setup for the general OpenTelemetry source is on the OpenTelemetry integration page.