Forward Grafana Alloy logs and traces to Sazabi with otelcol

Last verified on Nov 8, 2026.

Grafana Alloy is OpenTelemetry-native, and its otelcol.* components speak OTLP. That makes Sazabi, the AI-native observability and security platform, one more exporter you wire into a pipeline you already run. Existing exporters keep receiving data.

What Sazabi reads from Alloy

One manual log source covers Alloy. You add an otelcol.exporter.otlphttp "sazabi" block, and logs and traces from any otelcol.* receiver flow to Sazabi. Grafana documents that component as a wrapper over the upstream OpenTelemetry Collector otlphttp exporter. Its logs_endpoint argument defaults to client.endpoint plus /v1/logs, encoding is proto unless you set json, and the sending_queue and retry_on_failure blocks control buffering and retries.

Metrics are not stored by this source. A hostmetrics receiver in the same pipeline will not produce records here. Sazabi points to its OpenTelemetry Metrics source for that.

Questions it answers

• Which pods on this node logged errors in the minute before the restart?
• Do the traces Alloy received through otelcol.receiver.otlp line up with those logs?
• Is a service silent because the app stopped, or because its pipeline stopped exporting?
• Which receiver in the config is the source of the records I see?
• What did the logs from this DaemonSet say around the deploy?

A worked example: moving pod logs off loki.source.file

Many Alloy configs tail pod logs with loki.source.* and write to Loki. The Sazabi docs state that those components are not OTLP-compatible and cannot feed otelcol.exporter.otlphttp. The fix is a parallel otelcol path. Sazabi's page names otelcol.receiver.filelog pointed at /var/log/pods as the pod-log option. Grafana's reference gives that receiver an include list, a start_at choice, and an output block:

otelcol.receiver.filelog "pods" {
  include  = ["/var/log/pods/*/*/*.log"]
  start_at = "end"

  output {
    logs = [otelcol.processor.batch.default.input]
  }
}

otelcol.processor.batch "default" {
  output {
    logs = [otelcol.exporter.otlphttp.sazabi.input]
  }
}

otelcol.exporter.otlphttp "sazabi" {
  client {
    endpoint = "https://intake.example.com"
  }
}

start_at = "end" is the default: the receiver reads only lines written after it starts, so a restart doesn't send pod logs it already shipped. beginning backfills what's on disk, and without a storage handler from an otelcol.storage component to keep file offsets, it rereads those files after every restart. Leave the Loki pipeline where it is and add this one beside it. Both read the same files, so you get the logs in both places while you compare. In the batch processor, send_batch_size is a trigger threshold, so the actual batch can be larger when data arrives in big chunks.

If logs appear but traces do not, check that the traces output of your receiver or processor references otelcol.exporter.otlphttp.sazabi.input. The component's name appears in the error messages in Alloy's logs, so search for it there. After a redeploy, look for the Grafana Alloy source on the Sazabi Intake page.

How it fits with other integrations

Alloy sends the same OTLP that any OpenTelemetry Collector would, so the destination settings carry over. If your cluster runs another forwarder, compare Fluent Bit and Vector. If you also use Grafana Cloud, the Grafana page covers how the Sazabi agent can query it separately. See the telemetry pipelines category for more senders.