# 4. The Log Pipeline: Inputs → Rulesets → Actions

Understand rsyslog’s core architecture: logs enter through inputs, are processed by rulesets, and end up in one or more actions (outputs). This flow is called the log pipeline — historically known as the message pipeline.

## 4.1. Goal

Build a correct mental model of rsyslog’s architecture using the log pipeline. This helps you predict where to add filters, which actions will run, and why your snippets behave as they do.

## 4.2. The three core components

1. Inputs – how logs arrive. Examples: `imuxsock` (syslog socket), `imjournal` (systemd journal), `imfile` (text files).

2. Rulesets – the logic in between. They hold filters and actions and decide what happens to each message.

3. Actions – where logs go. Examples: files (`omfile`), remote syslog (`omfwd`), or modern targets like Kafka (`omkafka`).

## 4.3. Visual model

            flowchart LR
      A["Inputs"]:::input --> B["Ruleset"]:::ruleset
      B --> C1["Action 1"]:::action
      B --> C2["Action 2"]:::action

      classDef input fill:#d5e8d4,stroke:#82b366;
      classDef ruleset fill:#dae8fc,stroke:#6c8ebf;
      classDef action fill:#ffe6cc,stroke:#d79b00;

## 4.4. Explanation

- Inputs feed messages into rsyslog.

- Each message enters a ruleset, which decides what to do with it.

- Actions are destinations that execute in order by default (serial). Concurrency is possible through per-action queues or worker threads, but that’s an advanced topic.

## 4.5. Example: add a second destination

Write messages tagged `tut04` to a file and forward them:

    if ($programname == "tut04") then {
        action(type="omfile" file="/var/log/mypipeline.log")
        action(type="omfwd" target="logs.example.com" port="514" protocol="udp")
    }

Restart and test:

    sudo systemctl restart rsyslog
    logger -t tut04 "hello from rsyslog tutorial 04"
    sudo tail -n 20 /var/log/mypipeline.log

Note

Forwarding requires a second machine or another rsyslog instance listening on a port. Without a reachable target and without an action queue, rsyslog will retry and may appear “stuck” for a short time before the next attempt. For a proper walkthrough, see Forwarding Logs.

## 4.6. Action order and config sequence

- Actions execute serially in the order they appear.

- Earlier actions can modify or discard messages before later ones run.

- Include snippets in `/etc/rsyslog.d/` are processed in lexical order (e.g., `10-first.conf` runs before `50-extra.conf`).

- Concurrency can be introduced by giving an action its own queue (`action.queue.*`) or by using separate rulesets/workers.

See Order Matters: Config and Include Files for a hands-on demo of ordering effects.

## 4.7. Verification checkpoint

You should now be able to:

- Sketch Input → Ruleset → Actions from memory.

- Recognize where your distro-provided inputs attach to the flow.

- Understand that actions are sequential by default.

- Name at least one modern output (e.g., Kafka).

## 4.8. See also / Next steps

You now understand the basic architecture — the log pipeline. To explore more advanced pipeline concepts (branching, staging, queues), see:

- Pipeline Stages

- Pipeline Design Patterns

- Forwarding Logs - how forwarding and queues interact.

- Order Matters: Config and Include Files - ordering and include file sequence.

- The Log Pipeline - conceptual overview

Tip

🎬 Video idea (2–3 min): show the diagram, then run `logger -t tut04 "…"` and watch the message hit both the file and the forwarder; highlight that actions execute sequentially by default.

Support: rsyslog Assistant | GitHub Discussions | GitHub Issues: rsyslog source project

Contributing: Source & docs: rsyslog source project

© 2008–2025 Rainer Gerhards and others. Licensed under the Apache License 2.0.