One of the most popular destinations in syslog-ng is Elasticsearch. Due to the license change of the Elastic stack, some people changed quickly to Grafana/Loki and other technologies. However, most syslog-ng users decided to wait and see. Version 1.0.0 of OpenSearch, a fork of the Elastic code base from before the license change is now available. Elastic also published a new release last week.
For this blog, I tested the latest and greatest from both product lines and I’m sharing my experiences. For the impatient: both work perfectly well.
Before you begin
To use Elasticsearch from syslog-ng, you need a recent enough version with HTTP support enabled. The one in FreeBSD ports has it enabled by default. For openSUSE you need the syslog-ng-curl sub-package, for Fedora syslog-ng-http, for Debian syslog-ng-mod-http. The syslog-ng version should be at least 3.23 – the version available in EPEL 8 is tested to work with Elasticsearch 7.X. If your distribution does not feature a recent enough version, you should check the 3rd-party packages page at https://www.syslog-ng.com/products/open-source-log-management/3rd-party-binaries.aspx
Version 1.0 of OpenSearch was released just a few weeks ago. I tested the RC earlier, and it worked fine: https://www.syslog-ng.com/community/b/blog/posts/opensearch-and-syslog-ng The current release has all traits of a 1.0.0 release: it works, but many things are still missing. The recommended installation method is still docker, but there are now various tar.gz releases and tools available and ARM64 became a supported platform. RPM and DEB packages are yet to come.
When using the Docker installation method, OpenSearch and OpenSearch Dashboards are secure by default. Connections are encrypted and password protected.
OpenSearch is now picked up by the community, there is even a FreeBSD port under preparation. I tested it and I got it working faster and easier than on Linux with docker-compose. The reason was that while running docker-compose up, there was an error and OpenSearch stopped, complaining that I should increase the value of vm.max_map_count. Of course, the message was well-hidden in a long list of log messages on the screen. When I set it to the given value and started again, it failed again. The reason was vm.max_map_count again, an even larger value was suggested. Once I set it, everything worked perfectly.
The OpenSearch Dashboards are a dream come true: an easy to use GUI for OpenSearch. Even for the first time, I could find everything quickly.
Recently there were many rumors floating around on Twitter that Elastic is intentionally breaking compatibility with 3rd-party tools. This is why I tested Elasticsearch 7.14 as soon as possible, once it was released.
As usual, I installed Elasticsearch and Kibana from RPM packages on CentOS 8. Once Elasticsearch started, I sent some log messages to it from syslog-ng. It worked perfectly well, just as all the time from version 2.X (most likely also 1.X, I just never tested that).
Even if I am a longtime Kibana user, it was not easy to find my way in it. Everything is changing drastically whenever I skip a few minor releases. In the end, I had everything configured and I could search and view logs sent by syslog-ng in Kibana.
Update: I learned after finishing my blog, that there were indeed changes. Tools and client libraries by Elastic now check the Elasticsearch version. The syslog-ng elasticsearch-http() destination does not use client libraries provided by Elastic, but are implemented as a simple wrapper around the http() destination. Thus, it works fine both with ElasticSearch and OpenSearch.
What is next?
There are no promises that I test each minor release, but I plan to keep an eye on both software. If I run into something interesting, I will keep you updated.
If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @PCzanik.