Send Fluent Bit container and host logs to Sazabi over OTLP

Last verified on Nov 8, 2026.

Fluent Bit sits on the node. It tails container logs, reads host files and journald, and ships them somewhere else. When that somewhere is Sazabi, the AI-native observability and security platform, the whole job is one output block. The built-in opentelemetry plugin speaks OTLP, so nothing else needs installing on Fluent Bit v2.0 or later.

What Sazabi reads from Fluent Bit

Fluent Bit sends container and host logs to Sazabi over OTLP/HTTPS. This is a single manual log source, and the Sazabi docs describe it for Kubernetes clusters and for plain infrastructure alike.

Fluent Bit's own docs say the plugin defaults to OTLP/HTTP with Protocol Buffers, and that logs_uri defaults to /v1/logs. The plugin can also send metrics and traces. The Sazabi page configures it for logs, so that is what this source is for. Records flush in batches. batch_size caps a flush at 1000 log records by default, and compress accepts gzip or zstd if you want smaller payloads.

Questions it answers

• Which pods on this node were logging errors when the deploy rolled out?
• Did the DaemonSet restart drop logs, or did the app go quiet?
• Are the host logs from the nodes arriving next to the container logs?
• Which service wrote the first error line, and what came right before it?
• Is one namespace missing because the match pattern skips its tags?

A worked example: choosing what becomes the log body

Raw container records often carry the useful text under one key, with the rest as metadata. Fluent Bit's plugin has logs_body_key, a record accessor that selects the value used as the OTLP log body. With logs_body_key_attributes turned on, the remaining fields in the record are kept as attributes instead of being thrown away. The output below uses Fluent Bit's YAML config format. It starts from the Sazabi settings and adds those two keys plus the severity and trace ID keys Fluent Bit documents:

pipeline:
  outputs:
    - name: opentelemetry
      match: kube.*
      host: intake.example.com
      port: 443
      logs_uri: /v1/logs
      tls: on
      tls.verify: on
      logs_body_key: $log
      logs_body_key_attributes: on
      logs_severity_text_message_key: $level
      logs_trace_id_message_key: $trace_id
      compress: gzip

A record such as {"log": "upstream timed out after 30s", "level": "error", "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736", "namespace": "payments"} would then leave Fluent Bit with the message as its body, error as its severity text, the trace ID set and namespace kept as an attribute. Your own keys will differ, so check what your parser produces first.

To confirm it works, open the Intake page in the Sazabi dashboard and look for records from the Fluent Bit source within a minute or two. If you only see some namespaces, the match value is the first thing to check. The Sazabi troubleshooting notes also flag host with a scheme or slash in it, and a Fluent Bit older than v2.0.

How it fits with other integrations

Fluent Bit is one of several senders that end at the same intake. Vector does the same job with a different config language, and Grafana Alloy uses Collector-style components. If you run a Datadog Agent on the same nodes, the two can coexist. For the standard behind all of them, see OpenTelemetry, or browse telemetry pipelines.