syslog-ng: what the log daemon does and how to configure it

What syslog-ng solves, and who ends up running it

The README describes syslog-ng as an enhanced log daemon that accepts syslog, unstructured text, message queues, and databases as input and output. The practical problem is a daemon that sits on a host and does not merely append everything to one file. It can receive RFC3164 and RFC5424 syslog, receive and send JSON, and route each message to a different destination depending on what it contains. That is a different job from a plain syslog sink.

The audience is infrastructure and platform engineers who own log collection on Linux and BSD hosts. The README states that syslog-ng is integrated into almost all Linux distributions and BSDs, and that it is also incorporated into a number of products, so many readers will meet it as a dependency rather than install it deliberately. If your requirement stops at "write everything to /var/log/syslog", the default configuration of most distributions already does that and you do not need to learn the configuration language.

The source, filter, destination model behind syslog-ng configuration

A syslog-ng configuration is a set of log paths. Each path names one or more sources, optional filters and parsers, and one or more destinations. The README's first example is exactly that shape: a source block calling system() and a destination block writing to a file. Adding network() to the same source block is how the daemon starts accepting TCP traffic, and the README notes that network() defaults to TCP port 514.

Processing happens between source and destination. The feature list names csv-parser(), db-parser() and kv-parser() for classifying and structuring logs, and says logs can be normalized and processed as they flow through the system. Output can go to files, message queues such as AMQP, databases such as PostgreSQL or MongoDB, or big data tools such as Elasticsearch, Apache Kafka and Apache Hadoop. The README also states that some functionality is compiled only when the required development libraries are present, and that the configure script prints a summary of enabled features at the end of its run. That summary is the real description of what a given build can do.

On throughput, the README claims performance comparable to a large cluster on a single node, scaling to 600-800k messages per second in the simplest use case, while classification, parsing and filtering still produce several tens of thousands of messages per second. Those are the project's own numbers for its own scenarios, not a measurement you can assume for your message shapes.

Installing syslog-ng on Ubuntu and sending a first structured log

On Debian and Ubuntu the README gives a single command, run as root:

apt install syslog-ng

The README says the latest versions are available for a wide range of Debian and Ubuntu releases from the project's APT repository, and lists supported distribution versions with a sources.list component name per release, for example ubuntu-resolute for Ubuntu 26.04 on x86-64 and ubuntu-resolute-arm64 for arm64. For RHEL and other distributions the README does not give a package command; it says binaries are available in various Linux distributions and that contributors maintain packages. Check your distribution's own repository rather than assuming the project ships one.

If you prefer to build, the README points at dbld, a Docker based build infrastructure inside the source tree, documented in dbld/README.md. The plain path is the usual autotools drill:

./configure && make && make install

The README notes that if you cloned from git and have no configure script, you run ./autogen.sh first, and that the extra effort compared with dbld is fetching and installing all build dependencies.

The quickstart configuration accepts system logs from /dev/log, whether written by applications or forwarded by systemd, and writes them to one file:

@version: current
@include "scl.conf"

log {
	source { system(); };
	destination { file("/var/log/syslog"); };
};

To accept network traffic as well, the README adds network() to the same source block. For structured application logging it gives a destination that writes key=value using a template:

@version: current
@include "scl.conf"

log {
	source { system(); };
	destination { file("/var/log/app.log" template("$(format-welf --subkeys .cim.)\n")); };
};

The README's accompanying example sends a JSON payload through logger with a @cim: prefix, and states the resulting message is name1=value1 name2=value2. That is the round trip to check first: submit one message, confirm the file contains the flattened key=value line, then add filters and further destinations.

Where syslog-ng is the wrong tool

The README carries no rollback or migration guidance, so treat configuration changes as edits to a live daemon's behaviour with no documented undo path. Version the file yourself before you touch it.

Platform coverage is the sharper limit. The README discusses Linux distributions and BSDs, an APT repository, and source builds. It does not document a Windows agent, and the repository layout is an autotools and CMake C project with modules, scl and packaging directories. If your fleet is Windows, nothing here tells you how syslog-ng would collect from it.

Parsing depth has a cost the README states plainly: the 600-800k figure applies to the simplest use case, and classification, parsing and filtering drop to several tens of thousands of messages per second. A configuration that runs db-parser() over every message is not the configuration that hits the headline number. There is also a build-time constraint: features compile only when their development libraries are present, so two hosts on the same distribution can behave differently if one was built with fewer libraries. If you need a parser that does not exist, you are writing C in modules, not a script.

Finally, the licence is marked NOASSERTION at the repository level, while COPYING, GPL.txt and LGPL.txt sit in the root. The README does not resolve which parts fall under which. For redistribution or embedding, read those files and your distribution's packaging metadata rather than relying on the repository label.

syslog-ng versus rsyslog: the difference in configuration approach

rsyslog is the obvious comparison and the one people search for. Both are C daemons that receive syslog and forward it, and both have configuration languages rather than a single config file of one-line rules.

The difference that matters in daily work is the shape of the configuration. syslog-ng builds explicit log paths: a source, optional filters and parsers, and a destination, each declared as a named block and then wired together in a log statement, as the README examples show. That makes routing decisions readable when you have several inputs and several outputs, and it is why the parser and destination modules plug into the same path structure. rsyslog's model is closer to rules and actions with its own module set and a different syntax lineage. Neither is a superset of the other, and the parsers, output modules and packaging differ, so a configuration is not portable between them. If your team already knows one, the migration cost is a rewrite of every rule, not a translation.

Maintenance, releases and the real upgrade cost

The repository is not archived, and the last push was on 2026-09-28. Recent releases are syslog-ng-4.12.0 on 2026-06-16, syslog-ng-4.11.0 on 2026-02-24 and syslog-ng-4.10.2 on 2025-10-14, so the release cadence has been a few months between minor versions. The README states the project is developed by a community of volunteers, contacted through the GitHub project page, a Gitter channel and a mailing list. Balabit, the original commercial sponsor, was acquired by One Identity in 2018, and One Identity offers a commercial edition called the syslog-ng Premium Edition. Axoflow is described as the company of Balazs Scheidler, the original creator and main developer. A commercial edition alongside the open source one means some features and support sit outside this repository; check whether what you need is in the open source build before planning around it.

The upgrade cost is not the package. It is the configuration. The @version directive at the top of every file pins the configuration language version, and the README's examples use @version: current. Configurations are not automatically forward compatible across major version jumps, and the README does not document a compatibility matrix. Budget time for reading release notes and testing a config against a new version before rolling it across hosts. On the licence side, the repository is labelled NOASSERTION while GPL.txt and LGPL.txt are both present at the root, so the split between the daemon and its modules has to be established from those files and the packaging of your distribution. This is a description of what the repository contains, not legal advice.

Editorial conclusion

Adopt syslog-ng if you need to receive RFC3164 or RFC5424 messages on a host, parse and rewrite them, and forward to files, message queues, SQL or NoSQL databases, or Kafka, and you are willing to write configuration in its own language. Do not adopt it if you want a managed service, a Windows agent, or a parser you can extend without writing C. Before committing, check the configure summary for the features your build actually enables, confirm the licence files in the repository root against your distribution, and test one log path end to end with a single source and destination.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. syslog-ng/syslog-ng on GitHub