On Fri, 27 Sep 2013, Rainer Gerhards wrote:
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.
ahh, ok. that makes sense.
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
that helps
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 ;)).
yes, documentation is an ongoing problem.
In the case of rsyslog, the conversion to the new syntax has actually ended up
with the documentation getting worse, not because the information isn't around,
but because the details aren't linked in to the root, too many things are
independant documents or blog entries :-(
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.
thanks.
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.
I'm hoping that it's fairly easy.
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 ;)
They are probably two halves of the same problem.
The first thing would be to document the problems, and from there nibble at the
problem.
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.
