On Thu, Sep 26, 2013 at 10:50 PM, David Lang <[email protected]> wrote: > > oops... I thought it migrated into the official doc, but doesn't look so. >> Here is the relevant blog entry: >> >> http://blog.gerhards.net/2012/10/how-to-use-rsyslogs-ruleset-and-call.html >> > > Ok, now I'm really confused. This doesn't seem to replacing rulesets, is > it just replacing omruleset with call? >
jupp - that's it. omruleset was a hack that made calling rulesets possible within the constraints of the old engine. "call" is the clean solution for the new engine. Especially for rulesets without associated queues, it has *zero* overhead (really!). omruleset always needs to duplicate messages, which usually means at least ~250 bytes of memory writes, some allocs and frees. > > Is there still a way to define a queue for a ruleset? (or for a call) That part of the doc is really messy. A couple of days ago, at least the queue params were added (very roughly): http://www.rsyslog.com/doc/queue_parameters.html These parameters apply to rulesets and actions. Also, call is briefly mentioned here: http://www.rsyslog.com/doc/rsyslog_conf_basic_structure.html Unfortunately, nobody wants to sponsor doc development nor contribute to it. So with limited time, it's falling behind. I try as good as I can, but my time is currently constrained and I am obviously not the best person to write that part of the doc (at least, I assume way too much ;)). > > > 3. how to manipulate the raw message buffer in parsing modules (I have >>>>> this archived in e-mail, I'll dig it up) >>>>> >>>>> >>>>> That's somewhat tricky at the moment and not properly encapsulated. >>>>> >>>> Important question: do you really mean rawmsg or just the msg part of >>>> the >>>> message (rawmsg is even tricker due to the low-level optimizations >>>> made). >>>> >>>> >>> I was talking about rawmsg, the type of changes that I was doing in the >>> cleanup type parser modules (that tweak the incoming file to make it sane >>> before letting it fall through to a 'normal' parser) >>> >>> >> I still don't believe in that approach ;) As you've seen, I've modelled >> all >> new parsiong modules via the action interface. Doesn't mean I am totally >> opposing it. One caveat is that there currently is no new-style interface >> for parser modules (again, not opposing this, but definitely not high >> priority work). >> > > defining a stack of parser modules in order is actually something that the > old syntax did well. I don't see any push to change it. Yes, as long as the parsers don't need config parameters. If they do, there is no vehicle for providing them (except the legacy stuff). > > I'm thinking that while I'm between jobs I may be able to work on rsyslog > code. > > :-) > a few things I've got in mind. > > table lookups (since the two companies seem so messed up, they have each > spent far more money in labor for people discussing the issue and arguing > over who would pay for it than they would have to just pay) > The comment in braces is what makes me really frustrated at time. Also in other cases, like companies that have their folks spent weeks on optimizing where we could help do them that in much less of the time. But they seem to have too much money ;) Seen many cases like this. > > look at modifying mmjsonparse and mmnormalize to see about making them > about to output to a prefix (something other than $!), that's good for starters, it's fairly easy. I think I must add this top mmpstrucdata if it is not there. So you can use that as sample. Will post the commit when done. > be able to parse a variable or template instead of just $msg, and for > mmjsonparse, accept things without cee: (I really hate having to 'claim' > cee format compliance just to get the json parsed, because I know the > messages are not really cee messages) > Yup, that would be very useful. > > look into the performance of string creation for cee/json messages and see > if there's a need to create a string generation module or not. > > If you have the time to do so, looking at json-c would probably even more benefitial. Or maybe replace it with a high performance solution. I have briefly looked at the code and know that there is much (performance-intense) that we don't need in rsyslog. But again... no funding for serious work on it and tons of other things to do. add "no complaints about current state" to this picture and you know what happens ;) Rainer _______________________________________________ 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.
