2014/1/22 Rainer Gerhards <[email protected]>
> On Wed, Jan 22, 2014 at 2:22 PM, Boylan, James <[email protected] > >wrote: > > > I agree with many of the points about the mission statement. I would > > really like to see Rsyslog continue on the path of becoming one of the > > defacto unified data transport solutions. To me, a true unified data > > transport needs to not just be able to send the messages to a > destination, > > but control how it arrives there as well. I need to dig into it more, but > > things like the log normalization functionality appears to play a strong > > role in that part as well. > > > > I would note that I think the idea of trying to add the ability to use > > another language as part of the process to build modules or plugins to > be a > > bad idea. I know this wasn't specifically what Radu was suggesting, but > it > > has been suggested before. One of the fundamental strengths, in my > opinion, > > of Rsyslog is the speed it is able to process the materials being passed > to > > it. Like it or not, no other language is going to be able to parse at the > > levels that C can handle. That is just a simple reality. > > > > > I (think I ;)) have a relaxed approach and I guess this is what Radu means. > Performance is critical, but probably not for every case. If we find a way > to support non-C modules in a way that *does not slow down* the native > code, I think this would be a big improvement. > > Let's say someone needs to output to an xyz destination. He doesn't even > need a lot of performance, just a couple of thousand messages per second. > He doesn't know C but python and he knows how to connect to the xyz source > via python. If we now provide an easy enough way to connect that python to > rsyslog, and do so without affecting other users AND other output sources, > that user will probably write the small connector and hopefully contribute > it to the project. His problem is solved, and rsyslog got a new > second-class (performance wise) output module. > > Now think someone else comes in and needs that exact functionality, but at > a much higher pace. Then there are basically two options: a) port it (or > have it port) to C or b) use some other tool. From what I have read and > heard in the past month, b) does not seem to be a vital option. So we may > get a), and thus get a first-class output plugin (except he uses option c > and invests that money in more hardware ;)). In any case, the second-class > plugin may be *the* tool to motivate someone to actually carry out the > port. > > I think this is doable - already via omprog. A related improg is also not > hard to write and we could also create a generic message modification > module interface (though probably with a somewhat higher performance > impact). > > I totally agree with what you said here! _______________________________________________ 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.
