| >This feels like they are trying very hard to avoid calling their syslog a syslog I _wish_ rsyslog and their friends were really that easy to extend, and I say this as a maintainer of Fluentd. Fluentd came about precisely because syslog family of data collectors fall short in certain ways: 1. tag-based data routing: as you get more and more data sources, it becomes very important to keep track of what goes where. In my view, this is one of the key reasons Fluentd is used at many companies, and why Kafka has become popular on the message queue side (topic-based stream modeling) 2. Extensibility: afaik, it's not all that intuitive for most programmers and sysadmins to extend and add new inputs, outputs, filters, etc. for rsyslog and/or syslog-ng. Admittedly, this is a subjective point, but looking at both Logstash and Fluentd's vast lists of plugins [1][2], I feel justified to make this claim. 3. Configurable transport logic: I've never met anyone who is happy with syslog's buffering and/or failovers. Because we've heard so much about this particular problem, when we were building Fluentd (...4 years ago), we took extra care to make buffering and failover easy to configure and extensible. Happy to answer more questions =D [1] https://www.fluentd.org/plugins/all [2] https://github.com/logstash-plugins |