Yeah - I think a performance decrease would have to be incurred only when using this feature. There would need to be a way to still use static templates as well. I know I'd personally whether work around things the way I do now than take a performance hit across all templates.
On Thu, Jun 18, 2015 at 11:05 AM, Tomas Heinrich <[email protected]> wrote: > TL;DR: Extending the current output-formatting capabilities would be > great, but, to me, the proposal seems half-hearted. I'd prefer a more > powerful solution. > > On 06/18/15 08:31, David Lang wrote: > >> There are so many cases where someone needs to override something in the >> default template (bad hostname, bad programname, etc) that having to >> create a custom tempalte for each thing gets to be a hassle. >> > > Agreed; been there and it's not just a hassle, it doesn't work very well. > > I'd like to propose that we have some templates that are exactly the >> > <...> > > I don't think extending templates this way is the right approach. > It feels like a kludge, using the instruments at hand, to get this use > case working. It would be a code that has to be maintained and I'd hope > that if something in this area gets implemented, it would be a more > flexible solution. > > A less flexible solution would be to allow overriding properties of > messages when some condition is met. But that doesn't solve all the needs > and some property values are interdependent. > > > I've recently dealt with a scenario where an omfile template had to be > tweaked depending on the message content. This doesn't work well for omfile > because you get two actions with different templates writing into the same > file. > > So I think there are actually two problems (or limitations): > * the first is that templates are a static property (can't switch between > templates dynamically) > * the second is that they're a property of the output action ONLY instead > of a message + output action / output module / ... combinations. (Here I'm > treading on thin ice...) > > > With static templates, what changes are the values of the referenced > properties - which can't be overridden, AFAIK. If you want to change the > static bits or use different properties, you have to duplicate the action > with a different template. > > It would feel natural to have an action that switches/assigns a template > to a particular message on a particular path. You can construct arbitrarily > complex conditions in rainerscript for calling these actions. > > > The downside is that all this would probably decrease the performance > quite a bit. > > Tomas > > > _______________________________________________ > 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. > _______________________________________________ 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.
