On Thu, 18 Jun 2015, Tomas Heinrich 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.
I think it would also up the complexity in some core areas a lot as well.
I've worked around this problem with
$template manual,"$.custom\n"
and then used rainerscrpt to do things like
if foo then {
set $.custom = exec_template("a");
} else {
set $.custom = exec_template("b");
}
/var/log/bar;manual
I think the key thing is that we want to encapsulate the complexity to as small
an area as possible (both in the code and in what the user needs to do to use
it)
This is why I was thinking in terms of new string generators ("templates written
in C") that would allow overriding of some things.
Yes, properties are interconnected, but if you are overriding one becuse it's
wrong in the template, you just need the result for your output. The fact that
all the others are incorrect doesn't really matter.
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.
