3 ms·

This feels like they are trying very hard to avoid calling their syslog a syslog, probably with good reason. A lot of distributions provide a very minimalist bu

This feels like they are trying very hard to avoid calling their syslog a syslog, probably with good reason. A lot of distributions provide a very minimalist build of whichever syslog daemon they've decided to use, and as such, people get the idea that syslogs can't write to databases, or parse json, or listen on pipes or any other number of things modern syslogs can do.

kiyoto 11y ago
>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 https://www.fluentd.org/plugins/all [2] https://github.com/logstash-plugins https://github.com/logstash-plugins
dozzie 11y ago
Where did you get the idea that message transporter is a syslog derivative? syslog is meant to collect logs from daemons, which typically run locally. Remote logging (a.k.a. 514/udp) does not make syslog a general purpose transport. Fluentd, on the other hand, does very little to handle logs. It receives, processes and forwards structured messages. Those can be logs, of course, once you apply liblognorm or grok, but it's far from be the only thing. I wouldn't use, for example, syslog to transport monitoring data or inventory, but Fluentd matches the task very well.

kiyoto 11y ago

>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 https://www.fluentd.org/plugins/all [2] https://github.com/logstash-plugins https://github.com/logstash-plugins

dozzie 11y ago

Where did you get the idea that message transporter is a syslog derivative? syslog is meant to collect logs from daemons, which typically run locally. Remote logging (a.k.a. 514/udp) does not make syslog a general purpose transport. Fluentd, on the other hand, does very little to handle logs. It receives, processes and forwards structured messages. Those can be logs, of course, once you apply liblognorm or grok, but it's far from be the only thing. I wouldn't use, for example, syslog to transport monitoring data or inventory, but Fluentd matches the task very well.