What Is Log Forwarding?

Last verified on Nov 8, 2026.

Log forwarding is moving logs from where they are written to another system, usually a central store. A small agent reads the logs on each host or node, optionally parses or filters them, holds them in a buffer, and sends them over the network. "Log shipping" means the same thing. Forwarding is the transport step inside log aggregation.

What a Forwarder Does

1. Reads. It tails files, reads container output, or receives messages from the network, such as syslog.
2. Tracks position. Fluent Bit's tail input generates a record for each new line and can keep a database file of tracked files and offsets so it resumes after a restart.
3. Transforms. It can parse, filter, and add metadata. See log parsing.
4. Buffers. It holds data while the destination is slow or down.
5. Sends. It delivers over a protocol such as OTLP, HTTP, or syslog, ideally encrypted.

The Common Agents

Here is a Fluent Bit setup that tails a file and forwards it over OTLP, using the output settings from Sazabi's documentation (written here in Fluent Bit's YAML format):

pipeline:
  inputs:
    - name: tail
      path: /var/log/myapp/*.log
      db: /var/lib/fluent-bit/tail.db
  outputs:
    - name: opentelemetry
      match: '*'
      host: <your intake hostname>
      port: 443
      logs_uri: /v1/logs
      tls: on
      tls.verify: on

And the same job as an OpenTelemetry Collector config:

receivers:
  filelog:
    include: [/var/log/myapp/*.log]
    start_at: beginning

exporters:
  otlphttp:
    endpoint: <your intake URL>

service:
  pipelines:
    logs:
      receivers: [filelog]
      exporters: [otlphttp]

Where Logs Get Lost

Forwarding is a common place for log loss, so check each hop.

• Backpressure. Fluent Bit explains that data can arrive faster than it can be flushed. With memory-only buffering, some inputs can lose data once mem_buf_limit is reached, and its docs suggest filesystem buffering if you must avoid loss.
• Non-durable buffers. Vector's in-memory buffers are the fastest, but they are not durable, so events in them are lost if Vector or the host dies. Vector's disk buffers exist for when durability matters more than performance.
• UDP. NIST notes UDP provides no assurance that entries are received or arrive in order. TCP improves reliability for more bandwidth.
• Plain text on the wire. OWASP recommends a secure transport, such as the syslog format over TLS.
• Restarts. Without saved offsets, an agent either re-reads everything or skips what was written while it was down.

Practical Guidance

• Prefer a daemon or agent per host over having each app ship its own logs. OWASP suggests an application can send its event stream, unbuffered, to stdout and let the execution environment manage it.
• Send structured logs so the forwarder has less to parse. See JSON logging.
• Rotate source files so the agent does not chase unbounded files. See logrotate.
• Filter noise at the edge. See log sampling.
• Monitor the forwarder. A forwarder that stops without an error looks like quiet logs, so alert on missing data. On Kubernetes, see kubectl logs for checking what a pod is writing.

Forwarding to Sazabi

Sazabi, an AI-native observability and security platform, accepts forwarded logs over OTLP. For Fluent Bit v2.0 or later, add the built-in opentelemetry output pointing at your intake hostname on port 443 with TLS on. For the OpenTelemetry Collector, add an otlphttp exporter with your intake URL. Setup pages: Fluent Bit, Vector, and the OpenTelemetry Collector. Sazabi's Intake page then shows per-source volume and health.