Open Source log management solution with over a million global users, an enhanced syslog daemon: the Babel fish of event processing

Visit us on GitHub

Getting started

To get started with syslog-ng, it must be installed. Most GNU/Linux distributions ship with binary packages, so either apt-get install syslog-ng or yum install syslog-ng is enough to get started. For other distributions and operating systems, the third-party packages list may be of use. To compile from source, please consult the README.

Once installed, a simple configuration (to be placed in /etc/syslog-ng/syslog-ng.conf), that puts all system logs down into a single file, is presented below:

@version: 3.5
@include "scl.conf"

source      s_system { system(); internal();                 };
destination d_all    { file("/var/log/all.log");             };
log                  { source(s_system); destination(d_all); };

Get the source


Open source

Released under a combination of the GNU General Public License (GPL) and Lesser General Public License (LGPL) - contributor agreement not required. Developed in the open: code, issues, mailing list all available!


The syslog-ng application scales well within a single computer, utilizing all available cores. Thanks to its flexible configuration, you can also build an architecture that spans multiple computers.


The configuration is very expressive, flexible, yet, still human readable. From the discrete building blocks of sources, parsers, filters, rewrite rules, and destinations, you can build incredibly powerful systems.

Why syslog-ng?

RFC3164 or RFC5424?
Whether you want to work with legacy BSD syslog (RFC3164) or the enhanced RFC5424 protocol, syslog-ng has you covered. Its flexible parser can process pretty much any variant of these protocols that you find in the wild.

You have unstructured data?
You have data in an unstructured format? That's not a problem: syslog-ng comes with a set of built-in parsers, which you can combine to build very complex things.

Are your logs all over the place?
Even if the incoming events are all over the place, with syslog-ng's patterndb, you can correlate events together, and transform them into a much more useful structure.

Databases, you say?
If you need to store your log messages in a database, you don't need to look any further! We have SQL (MySQL, PostgreSQL, even Oracle!), MongoDB. We also support inserting messages into Redis, if that's what you are after.

Message queues?
No problem! We support the Advanced Message Queuing Protocol (AMQP) and the Simple Text Oriented Messaging Protocol (STOMP) too, with more in the pipeline.

You need something special?
Even if you need something unique, there's a good chance that syslog-ng, the swiss army knife (or Babel fish) of logging already has the tools to support you. But even if not, contributing is easy! With responsive users and developers all around the globe.


Google Summer of Code 2014: Midterm 2014-06-30

We are happy to share the good news that all students passed the mid-term evaluation, and they are all making good progress!

Google Summer of Code 2014: Accepted syslog-ng proposals 2014-04-23

We received a number of very strong proposals for this years Google Summer of Code programme, out of which, we were able to select four. Read here for further information.

Google Summer of Code 2014: syslog-ng ACCEPTED! 2014-02-25

After two years of participating in the Google Summer of Code programme under the umbrella of the openSUSE project, this year, we are accepted on our own! We have a list of ideas, students are encouraged to add their own ideas, or contact us if interested, or want to know more.

Google Summer of Code preparations 2014-02-10

As in previous years, we are applying to participate in the Google Summer of Code programme. We have a list of very interesting and worthwhile projects to pursue, great opportunities for any student to learn, and earn a name with contributing to software used world-wide.

Support of syslog-ng OSE versions

At the moment, we have three maintained branches of syslog-ng, but we are working on reducing that to two, once the next branch of syslog-ng development enters the beta stage.


The former stable branch, which receives critical bug fixes only. People are strongly encouraged to migrate from this to the stable one, but the branch is still supported to some extent, to make it easier for distributions, among others. Critical bugs are security issues, serious regressions, and so on - I reserve the right to decide which bugs to consider critical. Fixes from any other branch are not backported, unless they're critical.

Currently the 3.3 branch fills this role.

Expected end of life: 2014 September


The stable branch, receiving all kinds of bug fixes, including smaller fixes backported from newer branches (including the next feature release and the development branch too). It may also receive very small features too, which do not affect the package as a whole: things like the $(format-json) improvement to allow comma-separated scopes, or being able to specify a template for the JSON parser.

Currently the 3.4 branch fills this role.

Expected end of life: 2015 January


The next stable branch, which we consider stable enough, but has not received as wide testing as the stable branch yet. This gets the most attention, as the idea is to stabilise it as soon as possible. Other than being newer than the Stable branch, this is treated in exactly the same way.

The Incubator is built against this branch.

Currently the 3.5 branch fills this role.

Expected end of life: 2016 Q1

With the first beta release of 3.6, we intend to drop the Maintainance branch, and maintain only the Stable and Feature branches.