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.
Rainer, do you have that picture from the rsyslog t-shirt that we can point
people at?
David Lang
_______________________________________________
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.
