Telemetry Pipeline and Log Pipeline Sources for Sazabi

Last verified on Nov 8, 2026.

If you already run a pipeline, adding Sazabi is a configuration change rather than a project. The pipeline sits between your services and wherever telemetry ends up, so one new destination reaches every service behind it.

What a pipeline source tells you

A pipeline source carries whatever the pipeline carries. Container and host logs from every node, spans from every service that exports to it, anything you collected with a receiver. It adds no new signal of its own. What it adds is reach. A Collector DaemonSet that reads pod log files covers every workload on a node, including the ones nobody instrumented.

Sazabi supports four tools: the OpenTelemetry Collector, Grafana Alloy, Vector and Fluent Bit. All four end at the same OTLP/HTTP intake, so the choice follows what you run today.

Limits to know first

The constraints differ by tool, and each one has caught people out.

• Collector. Logs and traces are stored. Metrics are not.
• Grafana Alloy. Only otelcol.* components work with the Sazabi exporter. Loki sources such as loki.source.* are not OTLP compatible and can't route through otelcol.exporter.otlphttp.
• Vector. Version 0.51.0 or later is required for the otlp encoding codec. Metrics sent through Vector are accepted at intake and silently dropped, so no error tells you.
• Fluent Bit. The built-in OpenTelemetry output plugin works from v2.0 with no extra plugin installed.

The Vector behavior is the one to remember. Silent drops look like a working setup in which a chart is flat.

How teams use a pipeline with Sazabi

Most teams add Sazabi as a second destination first. Their current backend keeps receiving everything, and Sazabi gets a copy to evaluate. Once they trust it, they either remove the old exporter or filter what each destination gets. Because a Collector fans out to every exporter listed in a pipeline, nothing in the services changes during the trial.

A pipeline is also the right place for cost control. Dropping debug lines, removing health-check noise and trimming oversized attributes before the data leaves your network cuts volume for every destination at once.

Example: Alloy fan-out to Sazabi

This is an example Alloy fragment based on the Sazabi docs. It receives OTLP, batches and sends logs and traces on to Sazabi.

otelcol.receiver.otlp "default" {
  grpc { endpoint = "0.0.0.0:4317" }
  http { endpoint = "0.0.0.0:4318" }

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

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

otelcol.exporter.otlphttp "sazabi" {
  client {
    endpoint = "<your intake URL>"
  }
}

To keep an existing backend, list its exporter input next to the Sazabi one in each output block. Alloy routes to every input in the list. Keep the intake URL in a secret store and reference it from the config.

What to watch across pipelines

• Each pipeline needs the exporter. Adding it to logs but not traces gives you logs and no spans.
• Restarts matter. A changed config does nothing until the agent restarts or redeploys.
• Backpressure. If the destination is slow, buffers fill and data drops. Watch your own pipeline's queue metrics, not only the destination.
• Credential hygiene. The intake URL is the credential. Put it in an environment variable or secret and commit only configuration that references it.
• Duplicates. Two agents on one host reading the same files send each line twice.

Choosing between the four

Choose the tool you already run. A Kubernetes platform team on the OpenTelemetry Collector should add an exporter to it, and a team that standardized on Vector should use Vector. Switching shippers to get Sazabi is rarely worth it.

If you are starting fresh, compare the four on what you need on the collection side: which sources you read, which transforms you want to run and which version constraints you can meet. In every case the Sazabi side is one OTLP/HTTP endpoint with no authentication header, so the decision stays on your side of the wire.

Detections

The detections below are what Sazabi runs on the logs your pipeline delivers. Checks such as watching queue depth or alerting when a node stops sending are things you set up in your own tooling. For metrics, use the OpenTelemetry metrics source, and for SDK-level export see OpenTelemetry with Sazabi.