Hi, On Mon, Jan 20, 2014 at 5:24 PM, David Lang <[email protected]> wrote:
> On Mon, 20 Jan 2014, Radu Gheorghe wrote: > > 2014/1/20 Rainer Gerhards <[email protected]> >> >> Folks, you are great! >>> >>> >> Thanks! :) >> >> >> On Sun, Jan 19, 2014 at 3:49 PM, Radu Gheorghe <[email protected] >>> >>>> wrote: >>>> >>> >>> >>> expecially since the likes of imfile and >>>> imjournal have been introduced. It looks like rsyslog is more a generic >>>> performance-oriented tool for gathering, buffering, processing and >>>> delivering application logs. But it's just how I see it. >>>> >>>> >>> If I try to put my vision into a single phrase, I'd say rsyslog intends >>> to >>> be the "swiss army knife of monitoring". Actually, we coined that vision >>> looooooong ago (15 years?) for Adiscon's Windows tools, and when I began >>> to >>> work on rsyslog I had that very same idea on my mind. In a somewhat >>> longer >>> text, this means to me that rsyslog should be able to accept, transform, >>> convert, process, forward and emit all types of event logs, making it a >>> kind of universal translator of "logging languages". >>> >>> Thinking about this, would it make to have a mission goal discussion >>> before >>> we go down to the logo question? ;) >>> >>> >> Yes, I think the logo has to express the mission, so we need the mission >> first. >> >> Regarding the mission itself, I'd rather go with something like "fast and >> lightweight log processing daemon", I wouldn't go for swiss-army knife. I >> think that's where rsyslog is and where it seems to go. It's processing >> logs, it has a slim&fast core core and powerful modules that let it >> process >> your stuff. >> >> To me swiss-army knife is flexibility. Even with all the progress that >> rsyslog made lately, rsyslog isn't and doesn't look like it has the >> potential to be as flexible as the likes of Logstash, Fluentd or even >> Apache Flume. >> >> By flexibility, I'm thinking about how easy it is to make it do various >> things (eg: take stuff from journal, parse it, send to MongoDB), and how >> easy it is to extend it. And rsyslog doesn't seem to be flexible nor does >> it seem to have the potential to be flexible as one of its main qualities. >> Compared to other tools in this space, of course. >> > > rsyslog is flexible, but since it is a high performance solution, it > requires that the modules be written in C, which scares a bunch of folks > away. > > it's actually very easy to take stuff from the journal and send it to > MongoDB, we have an imjournal module and an ommongodb module, just use them > and things work. There's quite a bit of capabilities to reformat the > message in the middle as well. > > Rsyslog has a much higher emphisis on speed than the other tools. > > > I'm not saying rsyslog shouldn't do flexibility. I think it's >> uberimportant >> and it's worth investing in. I'm saying we should go with one of the >> directions where rsyslog is pushed to that: >> - is already partially accomplished (so it's credible) >> - has the potential to go >> - last but not least, where we want it to go :) >> >> I thought something that includes the words fast, light and processing >> will >> do, given the history of rsyslog and where it seems to go now with v8. >> > > I see rsyslog as being the core of a logging system, it gathers logs from > (almost) anything, and delivers them to (almost) anything. It can modify > and filter the messages along the way. > Logstash is much closer to that description than Rsyslog. I guess that doesn't mean Rsyslog should not try to be like that, too, or be better at something else, like speed. Re "delivers them to (almost) anything", I think this is where Rsyslog has to do something about making itself either more pluggable or maybe existing mechanism needs to be better documented or evangelized or something. If you watch Logstash, you'll see *external* contributors are delivering *numerous* input/output/filter modules on a daily basis. Because these input/output/filter modules are the core of the system they take the central place in Logstash docs, for example: http://logstash.net/docs/1.3.2/ . Eyeballing those 4 columns of items, it looks like about 100 of them. This has nothing to do with the logo any more, but I think figuring out how to make in/om/etc. writing simple is one of the keys to Rsyslog future success. I'm not sure where/if there is documentation for Logstash inputput/output/etc. developers, but the ones I looked at are extremely simple and easy to write. For example: https://github.com/logstash/logstash/blob/v1.3.3/lib/logstash/outputs/elasticsearch.rb Interestingly, the way I got to the above link was from the doc: http://logstash.net/docs/1.3.3/outputs/elasticsearch -- so docs and sources are nicely linked. Otis -- Performance Monitoring * Log Analytics * Search Analytics Solr & Elasticsearch Support * http://sematext.com/ _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
