Send Prometheus metrics to Sazabi through the OpenTelemetry Collector

Last verified on Nov 8, 2026.

Prometheus tells you how a system behaves over time. Counters grow, gauges rise and fall, and histograms record how long things took. Sazabi, the AI-native observability and security platform, takes those numbers in so the agent can read them next to the logs from the same incident.

What Sazabi reads from Prometheus

Prometheus does not speak OTLP, so the OpenTelemetry Collector sits in the middle. Its prometheus receiver scrapes a Prometheus server, and an otlphttp/sazabi exporter forwards the result to your intake. You need the Contrib build of the Collector, because the Core build has no prometheus receiver. The exporter takes metrics_endpoint, which must be the full URL ending in /v1/metrics.

Each scraped data point becomes a log record with structured fields for the metric name, type and value. Labels stay as record attributes. Histograms and summaries add count, sum, min and max. Sazabi ingests OpenTelemetry metrics (Prometheus metrics through an OpenTelemetry Collector) and OTLP traces through the same intake as your logs. It stores each metric data point and each span as a log record that its agent queries alongside your logs, so there is no separate metrics store to run.

Questions it answers

• Did request volume or error counts change at the minute the incident started?
• Which label values, such as code="500", account for a jump in a counter?
• Does a gauge for queue depth or memory move before the first error log?
• What was the slowest histogram bucket for this service during the deploy?
• Are metrics arriving at all, or did the scrape job stop?

A worked example: a counter and a histogram

The Sazabi example scrapes the Prometheus server at localhost:9090, and that endpoint returns Prometheus's own metrics. To forward an application's series, add the application's /metrics target to the receiver's scrape_configs, the same static_configs block the example uses; the receiver takes standard Prometheus scrape configuration. Prometheus documents a text exposition format. A scrape of that application might return lines like these:

# TYPE http_requests_total counter
http_requests_total{method="post",code="200"} 1027
http_requests_total{method="post",code="500"} 41
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.05"} 24054
http_request_duration_seconds_bucket{le="0.1"} 33444
http_request_duration_seconds_bucket{le="+Inf"} 144320

A counter can only increase or reset to zero on restart, so a single value tells you little. What matters is the change between two scrapes. With the Collector's scrape_interval set to 30s, as in the Sazabi example, you get a data point every half minute, and each one lands as its own record. The code and method labels are attributes you can filter on.

Search for the metric by name, then ask the agent to compare:

Compare http_requests_total with code="500" across the last ten scrapes.
Did the count jump, and which logs from checkout-api were written in that window?

A drop to a lower value means the process restarted and the counter reset, so do not read it as a recovery. A steady climb in the 500 series with no matching log line points to a service that is failing without logging, and that is the next place to look. If nothing shows up, check that targets in the receiver points at the right Prometheus host and port, and that the endpoint ends in /v1/metrics.

How it fits with other integrations

Prometheus is a source of numbers, and the Collector is the same one described on the OpenTelemetry page. If you use Grafana Cloud for dashboards over Prometheus, the Grafana integration lets the Sazabi agent query it directly. For log forwarders on the same hosts, see Vector and Fluent Bit. Browse telemetry pipelines for more.