[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

3801.0. "Collector event type" by CTHQ::WOODCOCK () Thu Sep 24 1992 20:08

Hello,

I have begun to 'think' about using data collectors for multiple purposes
with multiple management domains in mind...on the same system. This was kinda
discussed in note 2823 but I'd like to add this to the wish list. I need
event TYPES by which I can write wildcarded alarms against. I know the API is
open but this approach isn't for non-program types and I haven't the time to
persue it even if I were. I graciously request an extra field in the SEND_EVENT
command which can be specifically alarmed against as a 'type'. An example is 
that I currently have built a large monitor using dozens of collectors. I then
wrote an alarm rule which helps process the incoming events with an expression:
exp=(occurs(collector * any event) or something like it. Now if I begin to use 
other data collectors for other purposes (different networks) the previously 
defined rule picks up the unwanted events (not good). This means I must either 
write a seperate rule for each collector (thanks, no...) or put a hook in the 
procedure to exit if it is the wrong networks event (queue costly). With a 
new field the expression would look something like:
exp=(occurs(collector * WATN_NETWORK)) etc.

Without this function the data collector becomes a ONE SOLUTION ONLY widget
which I don't think was the plan.

kind regards,
brad...
T.RTitleUserPersonal
Name
DateLines
3801.1alarm rules on arguments of eventsMCC1::DITMARSPeteMon Sep 28 1992 19:2310
I think what you're requesting (at least on the alarms side)
has been asked for before:  to be able to alarm against the 
argument of an event.  I don't know where it stands presently 
in the priority list.  This would be useful in other situations
as well.

The syntax could be something like:

exp=(occurs(collector * any config event, 
	    with Event Type = "WATN_NETWORK"))
3801.2that's the oneCTHQ::WOODCOCKTue Sep 29 1992 12:0410
> The syntax could be something like:

> exp=(occurs(collector * any config event, 
>	    with Event Type = "WATN_NETWORK"))

That'll do it.

thanks for the ears,
brad...
3801.3good v1.2+ solutionCTHQ::WOODCOCKThu Dec 03 1992 19:3513
For anyone still interested in this subject I have new info for a workaround.
It does not appear this 'event type' support will make it into V1.3 but...

Although I didn't think partial wildcarding was supported at the global level
in v1.2 the following expression works:

express=(occurs(collector .watn.* any event))

Therefore a new directory for each set of functional data collectors allows
for a viable solution for seperating alarms for collectors so they don't walk
on each other.

brad...