Ok...
So I think short term, array passing mode is the simplest approach for me
to take. I think it's less parsing on the plugin side, so not as much of a
performance hit as JSON parsing.
However, I also like David's thought, if I can construct the JSON the way I
would like from the config system. In any case, I'd like to understand the
new template commands better anyway, so.. if I wanted to construct
something along the lines of...
{ command : "HINCRBY", params: [ "progname_key", "nginx", 1] }
using the new template configs, where "progname_key" is a constant, "nginx"
is %programname%, and 1 is a constant, how would I go about that?
Thanks!
Brian
On Tue, Jan 8, 2013 at 2:37 AM, Rainer Gerhards <[email protected]>wrote:
> > -----Original Message-----
> > From: Brian Knox [mailto:[email protected]]
> > Sent: Monday, January 07, 2013 11:54 PM
> > To: rsyslog-users
> > Cc: Rainer Gerhards
> > Subject: Re: [rsyslog] working with list templates
> >
> > David - no, I have batch processing working already as part of the
> > patch I'm working on. That part was actually pretty easy using
> > rewriting the plugin to properly use dequeuebatchsize, etc.
> >
> > The issue is that the way the redis protocol constructs commands means
> > that I can't just put a message payload with spaces in it right into a
> > command. Additionally depending on which redis command is being run,
> > the argument list is variable length.
> >
> > This is handled one of two ways in the redis C api. The first way is
> > using a sprintf like interface:
> >
> > redisCommand("HINCRBY %s %s %d", stringvar, stringvar, intvar)
> >
> > Since I don't want to limit what commands a user of the output plugin
> > can use, I don't see this interface being usable for this purpose
> >
> > The second way is by passing a char ** to RedisCommandArgv with some
> > information about the number of elements in the char and their lengths.
> >
> > This seems like it would fit well, if I can figure out a convenient way
> > to pass what I want from the template to the output plugin.
>
> OK, I think I have finally understood. This actually sounds like array
> passing mode is exactly what you need. A prime reason for the idea to phase
> it out was that the only plugin using it is omoracle, and there are
> definitely better ways to do it in light of the past enhancements. HOWEVER,
> your use case seems to be quite different, and it actually makes sense to
> have no field names.
>
> So I would recommend using array passing mode. Once we have a valid use
> case, chances of phasing it out diminish. Even if so (and you don't speak
> up loudly enough ;)), phasing out rsyslog features is always a very slow
> process, taking several years. In that case, there would be ample time left
> to refactor that part of the redis plugin... So I wouldn't care too much
> about array passing mode being a bit under suspicion currently...
>
> Rainer
> >
> > In this case, each member of the char ** is either a redis protocol
> > keyboard or one of the arguments.
> >
> > So in that case "HINCRBY", "httpd", "pageviews", "1" could be elements
> > in the char **, and when passed to RedisCommandArgv, the correct
> > protocol message would get constructed to send to redis.
> >
> > As per Rainer's thought.. there may be a way I could potentially use
> > the string formatting options to "escape" the command into a redis
> > protocol command,which is a thought that hadn't occurred to me. I
> > don't know if I like that approach better yet than my original
> > thoughts, but it at the least merits some thought.
> >
> > Thanks for all the discussion on this by the way!
> >
> > Brian
> >
> >
> > On Mon, Jan 7, 2013 at 5:18 PM, David Lang <[email protected]> wrote:
> >
> >
> > On Mon, 7 Jan 2013, Rainer Gerhards wrote:
> >
> >
> >
> > The more I read, the more I think what you really want is a
> > single string. Are we just missing a shell escape property option?
> >
> >
> >
> > I think that what he is wanting is a single string for each
> > message, but he wants to shift to processing a batch of messages rather
> > than one at a time.
> >
> > David Lang
> >
> > _______________________________________________
> > rsyslog mailing list
> > http://lists.adiscon.net/mailman/listinfo/rsyslog
> > <http://lists.adiscon.net/mailman/listinfo/rsyslog>
> > http://www.rsyslog.com/professional-services/
> > <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.
> >
> >
>
>
_______________________________________________
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.
