Configuration Formats#

rsyslog supports four configuration formats. For modern configurations, choose RainerScript or YAML based on workflow fit: RainerScript for direct rsyslog authoring, YAML for YAML-centric environments and automation.

Rsyslog has evolved over several decades. For this reason, it supports four different configuration formats:

basic - previously known as the sysklogd format. Best for simple, one-line configurations matching on facility/severity and writing to a log file.
advanced - previously known as the RainerScript format. The recommended format when you author rsyslog logic directly. First available in rsyslog v6, it handles advanced filtering, forwarding, queueing, and custom actions.
yaml - an additional syntax for YAML-centric environments such as Kubernetes, Ansible, GitOps workflows, generated config, or other tooling that already speaks YAML. Every YAML key maps directly to the equivalent RainerScript parameter, so both formats share the same feature set and core rsyslog model. See YAML Configuration Format for full reference.
obsolete legacy - previously known as the legacy format. This format is obsolete and must not be used in new configurations.

Which Format Should I Use?#

For Modern Configurations#

Choose between advanced and yaml based on environment fit, not ideology:

Use advanced when your team already works effectively with RainerScript, when you author rsyslog logic directly, or when that is the clearer fit for your workflow.
Use yaml when rsyslog is part of a broader YAML-centric deployment or automation workflow and you want to avoid conversion layers or embedded RainerScript text.

The two formats are functionally equivalent for the base configuration model. You can also mix them: a YAML main config may include RainerScript .conf fragments and vice versa.

Existing Configurations in Basic Format#

Some distributions ship default configurations in basic format. Converting them to advanced is straightforward and recommended if you plan to add complex constructs such as rulesets or queued actions.

Retaining Basic Format#

Continue using the basic format if there is a strong reliance on external documentation or many existing configurations in that format.

Example - Basic Format#

mail.info /var/log/mail.log
mail.err @@server.example.net

Advanced Use Cases#

For direct authoring beyond basic logging, advanced remains an excellent fit:

Fine control via advanced parameters
Easy-to-follow block structure
Safe for use with include files

Example - Advanced Format#

mail.err action(type="omfwd" protocol="tcp" queue.type="linkedList")

Deprecated Format#

Do not use obsolete legacy format. It is obsolete and will make your life difficult. It exists solely for backward compatibility with very old configurations.

Conclusion#

Use advanced for new configurations, or the YAML format when rsyslog lives inside a YAML-centric workflow. The basic format is acceptable for simple, existing configurations. Never use obsolete legacy.

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

Contributing: Source & docs: rsyslog source project