On Thu, 26 Sep 2013, Rainer Gerhards wrote:
On Thu, Sep 26, 2013 at 6:14 PM, David Lang <[email protected]> wrote:
On Thu, 26 Sep 2013, Rainer Gerhards wrote:
On Tue, Sep 24, 2013 at 8:00 PM, David Lang <[email protected]> wrote:
Rainer, is there an example of a simple module being converted to the new
config syntax?
I'm thinking that it would be useful to start collecting examples of
commits that do fairly simple things as documentation for programmers
trying to create/improve modules
a few of simple ones to start off with:
1. add a config parameter (I think I can dig this up from the imfile
changes where we implemented the multi-line mode)
I'll see if I can dig out something. But usually, there is more in a
single
commit - because new params get added for new functionality and so this is
always intermixed.
If we can pick something that adds fairly trivial functionality, that
would be a good example.
Have you seen my other message with omfile?
Yes, that looks like a good pick.
2. change a new style parameter
I'm looking at omruleset and it looks like it may not support the new
config format yet, but I'm not sure. If it does, I'd like to understand
how
it does, if not, it looks like it would be a tiny change and a good
example
case
Actually not, because this is a deprecated module, carried within the
source tree just for backward compatibility. The "call" statement can do
anything omruleset does, but in a much higher performance way.
But I think ommail is also missing the new style config. I'll check and,
if
so, it would make sense to convert it. When doing so, I could do baby-step
commits that show things being done individually.
Ok, I'm not easily finding documentation on 'call' (it's too common a
word), pointer please
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?
Is there still a way to define a queue for a ruleset? (or for a call)
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.
What I'm hoping to generate here is a document that can become a 'getting
started hacking rsyslgo' guide that will show the right way to do some of
these things.
There is the template module code, which is a good start, but as I've
learned the hard way, adding functionality requires hooks elsewhere in the
code, and I'm thinking that the easiest way to document some of these
things is just to point to commits in git that add the right thing.
so when adding new optional functionality, you need to
1. implement the functionality
2. add the old-style parameter for it
nope, you shouldn't add new legacy parameters.
Ok.
3. add the new-style parameter for it
4. add the documentation for it
5. add a test for it
I don't think any of my contributions have gotten all of these right (or
even all except the new style parameters)
I begun to do this with my omfile change today. All in all, I agree.
good.
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)
look at modifying mmjsonparse and mmnormalize to see about making them about to
output to a prefix (something other than $!), 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)
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.
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.
