-
Notifications
You must be signed in to change notification settings - Fork 2
TUT:DisMan_Monitoring
The DisMan (Distributed Management) working group in the IETF produced RFC:2981, which defines a set of MIB tables describing an Event Management System. With this system employed, devices are able to monitor themselves and neighboring devices for problems and report the problems via SNMP notifications. This can greatly relieve the amount of traffic a network management station needs to send to every device on the network.
The snmpd.conf manual page describes this feature at length.
Because it's the most typical usage, the remainder of this page discusses self-management (the agent querying itself) as opposed to querying other external devices. This document also specifies how to perform self-management using snmpd.conf configuration directives. It is actually possible to completely configure an agent using SNMP SETs to the EVENT-MIB tables themselves.
The internal monitoring actually makes its internal queries through SNMP itself. Thus you need to "authorize" the service to actually browse the data from the agent.
The first requirement is that you define a SNMPv3 username to use when performing self-management. First, we must define a user, add access control for it, and create it. PLEASE PICK A NAME DIFFERENT THAN myMonitorName and mysecretepassword, which is used below. Any name unique to your institution will work just fine.
createUser myMonitoringName SHA mysecretpassword AES
rouser myMonitoringName
iquerySecName myMonitoringName
We'll assume a simple trap receiver with only SNMPv2c support:
trap2sink myhost.example.com myCommunity
Now you need to define exactly what you want to monitor. We can't tell you what is important to actually monitor, so we'll just give you some examples of popular things to monitor.
Lets say you want to be notified when your processor load goes over 90%. You can do this by examining the HOST-RESOURCES-MIB::hrProcessorLoad column from the hrProcessorTable. First a simple expression just to do this:
monitor machineTooBusy hrProcessorLoad > 90
The machineTooBusy token is a name we've given to this particular monitor line. It is
This will generate a notification like this (reformatted output from snmptrapd):
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (6539) 0:01:05.39
SNMPv2-MIB::snmpTrapOID.0 = OID: DISMAN-EVENT-MIB::mteTriggerFired
DISMAN-EVENT-MIB::mteHotTrigger.0 = STRING: machineTooBusy
DISMAN-EVENT-MIB::mteHotTargetName.0 = STRING:
DISMAN-EVENT-MIB::mteHotContextName.0 = STRING:
DISMAN-EVENT-MIB::mteHotOID.0 = OID: HOST-RESOURCES-MIB::hrProcessorLoad.769
DISMAN-EVENT-MIB::mteHotValue.0 = INTEGER: 92
The mteTriggerFired is the notification that is actually sent. The machineTooBusy part comes from our own name for the monitoring event. And the actual values that triggered this notification were from the hrProcessorLoad.769 OID instance which had a value of 92.
Another notification will be triggered after it falls back down below the 90% mark later.
The agent won't monitor endless for the values because it would take up all your processing time! But you can control how frequently it does check for problems. The default is every 600 seconds (10 minutes), but you can change this with the -r switch:
monitor -r 30 machineTooBusy hrProcessorLoad > 90