[syslog-ng] setting facility/level of source log messages ?

[Balazs Scheidler]

On Wed, 2009-03-11 at 11:15 +0100, Xavier Lapie wrote:
> On Wed, Mar 11, 2009 at 08:20:03AM +0100, Balazs Scheidler wrote:
> > > So from now on, it is possible to do things like:
> > > 
> > > source aaa { udp(facility(syslog) level(emerg)); };
> > > 
> > > And if the message does not have a proper syslog header containing the
> > > above values, it'll use the ones specified in the configuration file.
> > > 
> > > Now as I think of it, it might be better to really use a separate
> > > keyword for this, e.g. default-facility() and default-level()
> > > Any opinions?
> 
> Hi,
> 
> Thanks ! I think it's better to have a separate keyword for this case.

Right, I'll change that.

> 
> 
> > Hmm.. I was thinking about this feature a bit more, and it occurred to
> > me that it would be possible to implement this also as a rewrite
> > function, e.g.
> > 
> > source src { ... };
> > 
> > rewrite r_fac { set("syslog" value("FACILITY")); set("crit" value("LEVEL")); };
> > 
> > I'm not sure that we need both features:
> >  * to specify the default priority value for any kind of log source
> >  * to make it possible to rewrite the value
> > 
> > I find the 2nd more general. What do you all think?
> 
> I had not though about the rewrite thing, but it sounds good too.
> 
> The two features look good to me.
> At first I just wanted to set a value facility/level to messages who did
> not have one. But it could be usefull to have the more general one, with
> the rewrite rule. I just hope it is not a performance penalty to call a
> rewrite rule instead of just setting the facility/level when the
> LogMessage structure is created.

sure the above example would be somewhat slower, as set() is operating
on strings, thus the 'syslog' value would have to be converted to a
numeric value at runtime. a less general rewrite() object would be quite
fast though. e.g.

rewrite r_fac { set-facility("syslog"); set-level("crit"); };

> 
> By the way, talking about performance, I have started looking for using
> polling instead of follow-freq(). I'll really have many source log files
> to check.
> The more files are to be checked, the more stat() and lseek() are
> called by syslog-ng. It could be a performance gain to use poll() or
> epoll() (on linux at least for this one) on the source files to check
> for new messages.
> 
> It seems that polling is only applicable on /proc/kmsg for now.
> Am I wrong or did I miss something (or both !) ?

poll() does not work for files, as regular files are always indicated as
readable. And since epoll() uses the same infrastructure I doubt it
would give you useful input.

-- 
Bazsi