30 September 2021
Rejecting Fluentd
My experience with Fluentd was a disappointment. Trying to use it in real production will either result in living with a lot less or spending what you’re saving to build what’s missing.
The other articles in this series:
First architecturally, the Fluentd client, written in Ruby, is fairly big, which is fine for back-ends dedicated to processing events, but can become costly when embedded in micro-servers or containers. The solution is to use the light weight FluentBit for forwarding, it is written in Go but has a different configuration format.
As an aside the approach they’ve taken clearly shows that Perl would have been a better choice than Ruby in this specific case. Perl would permit the light client and the full server to share the same code and configuration format. Although the Perl to C Compiler is difficult to use and imposes limitations, a super minimal non-extendable tail and forward client could be compiled, and would probably be even smaller than the FluentBit client.
Although the documentation was good, I found getting to a working configuration took quite a lot of effort. The configuration files quickly grew.
In its favor FluentD is a very plug-able architecture, and it is this flexibility that makes it attractive. You can write a custom parser for an unusual log, or find a plugin someone already wrote for it. There is a plugin for the backend storage to use every major SQL and NoSQL database you can think of. While there is a huge selection of Plugins I found that many of them are unmaintained, including important ones like the Postgres plugin!
I found a bug in and re-wrote the documentation for the Postgres plugin, submitted a PR, and had a favorable review of my PR from another developer. The owner of the Plugin never responded, despite repeated nudges. If you do decide that Fluend + Postgres is the right solution for you, then you’ll need to install the Postgres Plugin from my fork, which is unlikely to be maintained going forward. You can install Fluentd from binary packages or RubyGems, and I recommend using Gems, either way you are breaking with process to manually install a GEM from GitHub. Since, I decided to stick with Splunk free Tier for my personal logging, and I don’t do a lot with Ruby, I was not interested in trying to take over ownership of the Plugin.