On Fri, Jun 14, 2013 at 7:30 AM, David Lang <[email protected]> wrote: > On Fri, 14 Jun 2013, Rainer Gerhards wrote: > > On Wed, Jun 12, 2013 at 10:42 PM, David Lang <[email protected]> wrote: >> >> On Wed, 12 Jun 2013, Roberto Giordani wrote: >>> >>> >>> 2) I can't use the OWNER variable into ACTION >>> >>>> >>>> >>> This sounds like it's a bug, we'll need to have Rainer take a look at >>> that. >>> >> > It would be useful to document what fields in an action can take variables > and what ones can't. > > yup, that's right. Wasn't originally done as at the time of this writing we had no variables outside of templates... In a nutshell, almost all parameters do not accept variables. Tech reason below...
> > This feature is simply not present (and was never before asked for). It >> also has quite some runtime implications, as the lookup is costly. So some >> kind of caching needs to be put in place. In other words: not something to >> quickly add. >> > > I'm not sure I understand why it's an issue? as long as the same owner is > used with the same file it shouldn't be an issue. Using a different owner > with an action than the file was origionally created with is a problem even > if there are no variables involved. > well, if we permit a variable, that variable can change with each message - just like the filename can change with each message in dynafiles. Currently, I resolve the owner during config load. If that is made dynamic, for each message I need to check if the owner has changed (it does on the first time from NULL to real owner) and, if so, resolve it. The latter "should" happen via cache lookup, else you get extremely worse performance. > > what would happen if someone were to do the following on the same log line? > > > action(type="omfile" DirOwner="tom" DirCreateMode="0750" > FileCreateMode="0444" DynaFile="filename" ) > > action(type="omfile" DirOwner="robert" DirCreateMode="0750" > FileCreateMode="0444" DynaFile="filename" ) > > good questions. I'd say "first writer wins" (we never change owners one the file is created - another subtle issue to look at if we support dynamic owners. Bottom line: is this use case really justifying all that complexity? Especially given the fact that noone else has asked for it in the past 10 years? > > >> >>> >>> You told me about output ruleset but reading documentation it seems it >>> >>>> doesn't useful for my purpose. >>>> >>>> >>> well, they would possibly be useful to short-circuit the long series of >>> if >>> statements. >>> >>> >>> a word on ruleset use: it is NOT primarily an optimization tool (it was >> in >> previous releases). It is a tool for complex configurations, where you >> would either like to have something like subroutines or - and this is >> probably the most important use case - where you want to bind listeners to >> specific rulesets to keep message processing simple. >> > > those sound like optimizations to me :-) > > In this context, I read "optimization" as "peformance optimization". I agree they are "usability optimizations". > This configuration will be a bit faster than your original in that logs >>> from client1 only go through one fromhost-ip test, the 'stop' causes >>> rsyslog to skip all the remaining tests. >>> >>> >> I am still trying to find some more time to look in-depth at this. With >> sufficient different inbound connections, core utilization is usually much >> more even. I wonder why not here... >> > > His problem wasn't on the input side, it was on the output side. With the > enormous number of rules, rsyslog was spending all it's time processing the > conditions trying to write the data out. > > I am probably mixing this up with another posting... Rainer > > 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.
