On Mon, Jan 20, 2014 at 1:21 PM, Mauricio Tavares <[email protected]> wrote: > On Mon, Jan 20, 2014 at 12:19 PM, Radu Gheorghe <[email protected]> > 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: >>> >>> > What are we trying to accomplish? That's a good question. I'm guessing >>> > performance, reliability and related epithets are things that come to >>> mind, >>> > but the "vision" isn't clear to me. "The enhanced syslogd for Linux and >>> > Unix" is what rsyslog.com says, but it doesn't say much to me. IMO, it's >>> > already there and beyond, maybe we need a new goal. Or is there one and >>> I'm >>> > not aware of it? Rainer? >>> > >>> >>> Did I mention that we need someone who is good at public relations? ;) >>> >> >> Hehehe, that never crossed my mind :D I personally do what I can to raise >> awareness of what rsyslog can do for certain use-cases. But to call it PR >> would be a huge exaggeration. >> > Evangelist perhaps? >> >>> >>> Of course, we've moved far past this point. I even remember that I >>> rephrased the mission statement for a presentation, but guess what ... I >>> can't even find it! At least I admit my fatal fail ;) >>> >> >> I figured we need to think about it first. >> > I agree completely. Until we have an idea of the vision, the > feeling we are trying to convey with rsyslog, the logo might be > useless. Ok, we can come up with a cute logo (I am thinking on Adium), > but we might go the extra mile. > > BTW, do note that nothing is set in stone. Just because today we > decide rsyslog is, say, as essential as a good bathroom (not a > Japanese one because they are just creepy) it does not mean we cannot > change that view 3 days from now. > >> >>> >>> >>> > >>> > To me, it's not only about syslog, >>> >>> >>> right ... since long... >>> >>> >>> > 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. >> > I dunno; I think it depends on how you see flexibility. IMHO, if > I find a device that sends out logs in some odd way and then I can > make rsyslog, by writing a module, grab those logs and massage them to > look nice and consistent with the ones it usually expects to get, that > is flexible. Remember my post about a switch I have that spits logs at > an almost-but-not-quite rsyslog format; I was told all it needed was > to write a module for rsyslog to write pretty logs. > >> 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. >> > But, can it do that provided a module is made to act as middleman? > >> 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 like to put thoughts in bullets so we do not need to be > complete and proper. Then we can flesh it out. > > So I have the following features, please correct adjust it as needed. > > o Portable? (which platforms can you compile it on) > o Reliable > o Customizable (user can create (or pay to have them done) new modules > to talk to new devices) > o Lightweight (CPU/memory/whatnot) > o User can control how many resources it does use > o Supported (business can pay to get proper support) > o Plays nice with other packages (nagios and others) > o Networkable (large scale deployment with centralized logging) > o Secure > o Actively being developed > o Backwards compatible > o Has been deployed in more than 2 machines ;) > BTW, what I am trying to do it put out all the things we want to think on when we mention rsyslog to others. Later on we can pick the really important ones, the ones that make rsyslog unique and special and loveable like Bender.
>> 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. >> >> >>> >>> >>> > Back to the original question, I'm available for a short Skype next week >>> if >>> > I'm needed. I can send my Skype name via personal Email to anyone who >>> > requests it. >>> > >>> >>> Yup, obviously the same with me ... but mind of the mission statement >>> question. Guess that needs to go first - and we really should try to gain >>> agreement, shouldn't we? >>> >> >> Yes, mission statement first. I think it's more important for the community >> to have a sense of direction, than for PR/logo reasons. If there's one >> person to decide about the mission, I guess that would be you, Rainer. But >> maybe a short call with some more people would work better? If so, who >> wants to participate? I'm in. Rainer, David, Mauricio? Anyone else? Should >> I take this off-list, exchange Skype names and schedule a call? >> >> >>> >>> Thanks again to everyone. This list is really enlighning. >>> >> >> Yep, I have the same feeling :) >> >> >>> >>> Rainer >>> >>> PS: I may put up a form of the current logo on github as a temporary >>> measure... Just so that you know. Doesn't mean it's solved ;) >>> >> _______________________________________________ >> 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. _______________________________________________ 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.
