1 year of AxoSyslog

AxoSyslog is binary compatible with syslog-ng: you can use it as a drop-in replacement that uses the same service names and configuration files, making the upgrade from syslog-ng to AxoSyslog completely a non-issue.

A whole year has passed since we forked syslog-ng™, and six months since we last checked the progress of the projects, so it’s high time for another status check. For the sake of simplicity, we checked the statistics for the 1-year period, between 17-05-2024 and 17-05-2025, using the main branches of the projects.

During this year:

AxoSyslog has released 4 minor and 2 patch release (2 minor and 1 patch release since the 6-months checkpoint), while ‍
syslog-ng had 1 minor and 3 patch releases (2 patch releases since the 6-months checkpoint).

Day 365

AxoSyslog statistics

98% of the AxoSyslog commits are coming from Axoflow employees, which is not all that surprising. We’ve also ported a few bugfixes (~2%) from the syslog-ng project.

The next figure shows the overall activity in the AxoSyslog repository since Balazs started developing syslog-ng. Obviously, this covers 12 months of AxoSyslog development, and the 17 and half years of activity of the syslog-ng repository. This figure shows that the development activity of AxoSyslog is higher than ever before, even surpassing the all-time-high of syslog-ng (which peaked in 2018-19, then slowed significantly after 2019, hitting its low point in 2021).

Syslog-ng statistics

As you can see, the activity in the syslog-ng project during the year was somewhat sporadic, including over a quarter where it practically became standstill.

AxoSyslog: 1538 commits, 28 (~2%) backported from syslog-ng

syslog-ng: 759 commits, 339 (~44%) backported from AxoSyslog

Looking deeper into the commits, you can see that over 40% of the syslog-ng commits are backports from AxoSyslog (mostly new drivers and bugfixes). So given that the overall activity in syslog-ng is ~50% of AxoSyslog, and even from that activity ~44% is backport from AxoSyslog, I think it’s pretty clear where the actual development and progress is done.

Feature comparison

Feature-wise, the following main changes happened in the projects.

syslog-ng, first six months

New documentation site
Wildcard file source fine-tuning
Numerical severity filter
Proxy protocol for the syslog() and network() source drivers

syslog-ng features backported from AxoSyslog

Amazon S3 destination
elasticsearch-datastream() destination
Features for gRPC-based destinations (opentelemetry, loki, bigquery): headers, compression, etc.
no-piggyback-errors for syslog-parser
tls(): expose the key fingerprint of the peer

syslog-ng, second six months

Only some bugfixes.

AxoSyslog, first 6 months

FilterX - a replacement for syslog-ng filter statements, parsers, and rewrite rules. It has a syntax and rich set of operators similar to popular scripting languages that allows you to filter, parse, manipulate, and rewrite variables and complex data structures.
Log tapping into the outputs and internal logs
Amazon S3 destination
elasticsearch-datastream() destination
ClickHouse destination
Features for gRPC-based destinations (opentelemetry, loki, bigquery): headers, compression, dynamic header values, etc.

AxoSyslog, second 6 months:

Documentation for the Webhook source.

New destinations:
- Azure Monitor and Microsoft Sentinel
- Google Pub/Sub gRPC destination to send logs and data to Google Pub/Sub via gRPC.
The syslog() source driver can now auto-detect RFC6587-style octet-count based framing.
New macros: PEERIP, PEERPORT, SOURCEPORT.
New gRPC option response-action() for the bigquery(), clickhouse(), google-pubsub-grpc(), loki(), and the opentelemetry() destinations.
Lots of FilterX updates, including:
- Switch-case expressions in FilterX to better organize the code instead of using multiple if, elif, else blocks. Using switch-case expressions also improves performance.
- A new =?? Operator.
- Several new functions:

Summary

We’re still going strong with the development of AxoSyslog, and intend to keep it that way, to make sure that it’s a modern and versatile tool for both on-premises and cloud-based deployments. If you’re a syslog-ng user and would like to try it, see the How to upgrade syslog-ng to AxoSyslog blog post (or the How to install AxoSyslog on RHEL and AlmaLinux if you’re not).

Also if you need help with syslog-ng or AxoSyslog, don’t forget that you can reach out to us and talk to myself and our devs using our Discord server, or if you need help in troubleshooting data loss or scaling issues, book a free interactive consultation session.