Hello,
yes, the xcc schema does not enforce patterns to have at least one
matchfield, but the code called from xcc does. Some motivation for
"default patterns: it became useful with introduction of netsted
patterns.
<?xml version="1.0" encoding="UTF-8"?>
<patterndb>
<group>
<id>1</id><name>comware_group</name>
<pattern>
<id>11</id><name>comware</name>
<matchfield>
<name>Message</name>
<type>regexp</type>
<value>^%%10(.*?)/</value>
<capturedfield>
<name>Module</name><type>string</type>
</capturedfield>
</matchfield>
<pattern>
<id>111</id><name>comware_ntp</name>
<matchfield>
<name>Module</name>
<type>exact</type>
<value>NTP</value>
</matchfield>
...
</pattern>
<!-- patterns 112, 113, ... -->
<pattern>
<id>119</id><name>comware_default</name>
... <!-- code to be evaluated for unknown Comware modules -->
</pattern>
</pattern>
</group>
...
</patterndb>
HP switches (those based on Comware firmware) send syslog events with
text ($Message) always starting with "%%10", followed by module name
(Comware module), followed by '/' etc. In this configuration, there is
group 1 without matchfields containing single pattern 11. The pattern
11 <matchfield> matches all Comware events and extracts module name
from them. Then, subpatterns are evaluated, which can already match
the module name in $Module - as is the pattern 111 (and, possibly,
patterns 112, 113, ...). But I needed to write rules for events that
come from yet unknown Comware modules. This is the default subpattern
119.
Without the "default pattern" patch, it would be quite complicated to do so:
1) it is not possible to write pattern 119 as
<matchfield><name>Module</name><type>regexp</type><value>.*</value>,
because of MRU reordering, the pattern 119 would be in runtime
eventually moved before one of the patterns 111-118 and would override
it,
2) so the code "(...) to be evaluated for unknown Comware modules" can
only be moved to another <Processor> (i.e. pm_pattern -> pm_another),
and prepended with "if ($PatternID == 11) ...", however, this confuses
the configuration a lot,
3) last option would be to add another group, group 2 -> pattern 21,
test the %%10 regexp again, and move to code for unknown Comware
modules to it: even less effective and even more confusing when you
have tens of patterns.
So, basically, the "default pattern" patch allows for (1) by disabling
MRU reordening on "default" patterns, which are recognized not as
"regexp .*", but as having no matchfields at all. Such patterns
(without matchfields) were not allowed before, so the extension is
compatible with older configurations.
Milan
On Sun, Jan 17, 2016 at 4:15 PM, Botond Botyanszki <b...@nxlog.org> wrote:
> Hi Milan,
>
> On Mon, 11 Jan 2016 00:36:25 +0100
> Milan Krčmář <milan.krc...@gmail.com> wrote:
>
>> one little message before falling asleep. When creating hierarichies
>> of nested patterns, I needed to define a "catch-all" pattern, a
>> default match.
> What's the purpose of having a default pattern? Patterns without any
> <matchfield> elements don't make much sense because we use patterns to
> match event records - though it looks like the current xcc schema does
> not enforce this.
>
> Regards,
> Botond
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
nxlog-ce-users mailing list
nxlog-ce-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nxlog-ce-users
