The November syslog-ng newsletter is now on-line: Sending logs to Splunk using syslog-ng Developing a syslog-ng configuration Systemd-journald vs. syslog-ng It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2023-11-splunk-configuration-journald syslog-ng logo

Logging is not just syslog anymore. Still, many syslog-ng users stick to using one of the syslog protocols for log transport and flat files for log storage. While most SIEMs and log analytics tools can receive syslog messages or read them using their own agents, in most cases, you can use the http() destination of syslog-ng as well to send logs to them. You gain extreme performance and an architecture that is easier to maintain.

The October syslog-ng newsletter is now on-line: Why contribute to syslog-ng upstream? Accelerating single TCP connections in syslog-ng: parallelize() Backward compatibility in syslog-ng by using the version number in syslog-ng.conf It is available at https://www.syslog-ng.com/community/b/blog/posts/the-syslog-ng-insider-2023-10-contribute-parallelize-compatibility syslog-ng logo

Network traffic is expensive in the cloud, and even a single syslog-ng instance can easily saturate the full bandwidth of a network connection. Compressing HTTP traffic was introduced in syslog-ng Version 4.4.0 and depending on your use case, you can cut down on your expenses on your networking or send more logs using the same budget or bandwidth. Development of this feature was done using a locally installed OpenResty web server, and later tested using Sumologic.

You can read about many interesting syslog-ng features in my blogs. However, it can happen that when you want to try them at home, you fail because the feature is missing. How can you solve such problems? In this blog, I discuss some of the possible solutions from installing sub-packages through using unofficial repositories, to upgrading your OS. This blog focuses on RPM packages for openSUSE / SLES, Fedora / RHEL, and FreeBSD, because these are the packages I know – I am their maintainer.

OpenObserve has an Elasticsearch compatible API for log ingestion, but syslog-ng is not mentioned in the documentation. My plan was to document how to modify the syslog-ng elasticsearch-http() destination, based on API documentation. However, as it turned out, OpenObserve has a ready to use syslog-ng configuration example in the web UI. https://www.syslog-ng.com/community/b/blog/posts/sending-logs-to-openobserve-using-syslog-ng syslog-ng logo

This year I started publishing a syslog-ng tutorial series both on my blog and on YouTube: https://peter.czanik.hu/posts/syslog-ng-tutorial-toc/ And while the series was praised as the best possible introduction to syslog-ng, viewers also mentioned that one interesting element is missing from it: namely, it does not tell users how to develop a syslog-ng configuration. So, in this blog, learn how to develop a syslog-ng configuration from the ground up! I will explain not just the end result, but also the process and the steps to take to develop a configuration.

Even if most people ask me to compare systemd-journald vs. syslog-ng, I would say that they complement each other. Systemd-journald excels at collecting local log messages, including those of various system services. The focus of syslog-ng is on central log collection and forwarding the logs to a wide variety of destinations after processing and filtering. Combining the two gives you the most flexibility. Read more at https://www.syslog-ng.com/community/b/blog/posts/systemd-journald-vs-syslog-ng syslog-ng logo

Many users are annoyed by the version number included in the syslog-ng configuration. However, it ensures backward compatibility in syslog-ng. It is especially useful when updating to syslog-ng 4 from version 3, but also when updating within the same major version. Read more about it at https://www.syslog-ng.com/community/b/blog/posts/backward-compatibility-in-syslog-ng-by-using-the-version-number-in-syslog-ng-conf syslog-ng logo

One of the highlights of the syslog-ng 4.3.0 release is parallelize(). Normally, syslog-ng processes incoming messages from a TCP connection in a single thread. While this works fine with many connections, it is a bottleneck when using a single or very few high-traffic connections. Using parallelize() allows syslog-ng to process log messages from a single high-traffic TCP connection in multiple threads, thus increasing processing performance on multi-core machines. As you will see, parallelize() helps when you have a single high-traffic TCP connection.