Anonymous_User Absent Member.
Absent Member.
354 views

UniqueMatchingRule and Collector Startup Order

The UniqueMatchingRule portion of the syslog connection method in a
collector's package.xml tells the system which events should go to this
collector instead of through the generic collector when using Syslog. So
far so good; I have one of those rules, and it works just fine; in fact,
it created the collector immediately after I imported the plugin for the
first time, and the connector, and the event source nod... all in about
five seconds, so that was great. Everything works nicely.... almost.

If I restart the Generic Event Collector node on this CM then all events
that should go to this new collector of mine instead go to the generic
collector, losing all of my nice new parsing. The event source node
representing the source of events which are now going to the generic
collector is still located under my collector, but the events are
definitely going through the wrong one (severities are wrong, events lack
any fun fields, collectorid is wrong on the events, etc.). This is a
problem since the order of collector startup has not ever seemed to matter
before.

If I then do something like restart the event source node under my
collector, events still end up going to the generic collector. If I
restart the connector node under my collector, events correctly start
routing to my own collector again.

It seems like, in my case, that things work properly only if my pieces
start after the generic collector. Is this normal? I cannot find much
documentation on this feature at all in the SDK docs, and nothing
mentioning order requirements. Using the current 2011.1 SDK and Sentinel
7.0 SP2.

AB
0 Likes
1 Reply
Anonymous_User Absent Member.
Absent Member.

Re: UniqueMatchingRule and Collector Startup Order


Hmm... OK

So the description of how the Syslog Connector works is slightly off.
The way this works is that all events from all sources bound to the
Generic Event Collector (actually the one Collector with the property
UniversalSyslogCollector defined - there can be only ONE) are checked
against the UniqueMatchingRules for all installed Collectors. If a match
is found, the entire event source from whence that event came is moved
to the matching Collector (and a Collector/Connector instance created,
if necessary).

The reason this is relevant is that the same is NOT true for the
'Applications' property - all events are always matched against that
property, regardless of what Collector the sources are attached to (but
it's not a regex, just a list).

Now, to your specific problem - I've seen this happen before mostly when
the event source changes somehow and no longer "looks" like the original
event source. Remember that the sources are identified by their syslog
header information - IP or hostname - so in some cases I've seen that
change and the data get re-routed. That's a possibility, I suppose.

But assuming that you've checked and double-checked this, then it sounds
like a bug. So I should also mention that your issue has nothing to do
with the SDK or the Collector - it's the Syslog Connector that
determines the routing. And a brand-new Syslog Connector was released in
the last couple days. So I guess try the new one first, and if you can
replicate the issue then I'd file a bug.


--
DCorlette
------------------------------------------------------------------------
DCorlette's Profile: https://forums.netiq.com/member.php?userid=323
View this thread: https://forums.netiq.com/showthread.php?t=46390

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.