Just a partial response (but quick ;)) > I confess to being a bit confused as to why the existing output module > interface wasn't readily extending to batching,
That would be the real solution (and David Lang suggested it long ago). The only problem is it takes quite some effort, as we need to make sure we do not lose messages along that way. It is still on my agenda, but without a sponsor I fear it'll stay there for quite a while. In most cases, rsyslog is simply too fast to see a bottleneck. > since I've tended to > see the output modules as more of thin, final-hop proxies. IMHO, > database output modules should still pretty much blindly execute > whatever SQL rsyslog hands them, be that wrapped in a transaction or > not. > > That said (and more a question for Rainer), do rsyslog templates have > support for a null character? If so, it may be a more viable approach > for delimiting simple fields than changing the output module API. Of > course the CSV approach works too, but seems easier to break out of > than null-delimiting. Nope, also on the agenda. Here sysklogd legacy bites. All C-strings internally, so while not complex, a *lot* of work is required to change that (basically all string operations must be touched, and that in a program that mostly does string operations...). Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
