Re: Event MIB Implementation Survey

>>>>> On Mon, 5 Apr 2004 12:28:01 -0700, "Randy Presuhn" <[email protected]> said:

Randy> Here is the Implementation Survey for RFC 2981, the Event MIB.

And here is a really really late response:

Randy> Module: DISMAN-EVENT-MIB
Randy> Implemtation Source:

Net-SNMP

Randy> Management Application / Agent:

Agent, plus configuration file tokens to make management easier.  It's
likely we'll be implementing a gui management interface "sometime".

GROUPs:
dismanEventResourceGroup (y/n): n
dismanEventTriggerGroup (y/n): y
dismanEventObjectsGroup (y/n): y
dismanEventEventGroup (y/n): y
  [SET events not yet implemented]
dismanEventNotificationObjectGroup (y/n): y
dismanEventNotificationGroup (y/n): y

OBJECTs:
mteTriggerTargetTag (ro/rw): rw
    [err...  but it won't do any good, we only look at
    self-management.  The tag is actually writable, but later on
    things will break if you set it.  Future goals are to make
    monitoring of other hosts available too, but it's not there now]

mteEventSetTargetTag (ro/rw): no
mteTriggerValueIDWildcard (ro/rw): rw
mteTriggerContextNameWildcard (ro/rw): rw
mteObjectsIDWildcard (ro/rw): rw
mteEventSetContextNameWildcard (ro/rw): no

Randy> Deployment / Operational Experience:

I implemented the majority of this on a plane ride a number of years
ago (to and from the last DC conference if I recall).  There are a
number of things that are incomplete in the implementation, such as
set events, monitoring of other hosts, etc.  We do support writable
tables everywhere (though in one case, the tables aren't yet
persistent which is sort of problematic ;-).

I can't even promise that I remember everything that was and wasn't
implemented properly I'm afraid, because the code is rather old (old
enough that I'd probably rewrite it at this point if I had to touch it
heavily again in order to make use of better APIs that now exist).

We also implemented a simple configuration file token wrapper around
the MIB tables that is a bit easier to use if you don't want to
understand the MIB.  EG,

  monitor -t 60 -u me -o sysUpTime.0 -o hrSWRunName "high process memory" hrSWRunPerfMem > 10000

for example monitors the hrSWRuntable for processes with too much
memory every 60 seconds using the security name "me" and adds in the
sysUpTime.0 and hrSWRunName objects into the notification that is
sent.

Similarly, notification events are easily added using a
"notificationevent" configuration token (see below for an example).

Over all, I think the management structure of the tables works fairly
well.  Most users don't make use of the actual mib infrastructure
(currently), and rely on the above configuration tokens.  However, we
follow the guidelines of the MIB for actually doing the monitoring and
that seems to work quite well.  We get a large number of requests
asking for how to send traps based on random MIB object monitoring,
and we point them to this support and they go away and don't come
back.  That either means it never works or it always works I guess ;-)

On a side note, our agent doesn't have hooks into all the operating
systems everywhere for determining when an interface goes up or down,
so for a very long time we didn't support the standard ifLinkUp/Down
notifications.  I recently thought, "you know I could simply configure
the event mib to do this for me and it word work on every system".
Thus, we now support the notifications in an extremely hacky way:

  monitor -r 60  -e linkUpTrap "send linkup