Letzte Aktualisierung: 18. Januar 2011
1. How Check_MK makes use of SNMP
A large class of hosts being monitored does not have an operating system where you can install a check_mk_agent. Instead, it provides access to vital data via SNMP. Most prominent member of those devices are network switches, but also routers, ups and power supply devices of many vendors can be accessed via SNMP.
Check_MK supports monitoring via SNMP and ships many SNMP checks for various devices ready to use. The basic principle is the same as with the Check_MK agent: Check_MK does not retrieve single values from the target host, but gets all data to be monitored at once. However, there are a few differences to the classical checks via TCP:
2. Setting up SNMP checks with Check_MK
2.1. 1. Configuring and trying out SNMP manually
Your first step should always be to try out if you can get data via SNMP manually. Most probably you will have to configure your SNMP device in order to allow access from your Nagios server via SNMP. Usually you have to configure:
What SNMP calls "community" basically is a password. The default is public. If you do not have to worry about security, you can use that; if that level of security is not enough for your environment, you might use SNMPv3 which supports AES. Most devices support this by now. For the Check_MK configuration check the snmpv3 section further down.
After your configuration is done, you should be able to retrieve the OID sysDescr.0 via snmpget. Here is an example for the host 10.1.0.17 with the community public:
user@host> snmpget -v1 -c public 10.1.0.17 sysDescr.0 SNMPv2-MIB::sysDescr.0 = STRING: Superduper Switch V34/A Version 11.02
2.2. 2. Declaring hosts
Now you are ready to configure your host for Check_MK. Put it into all_hosts as usual, but add the host tag snmp. Otherwise Check_MK would try to contact those hosts via TCP port 6556 when doing inventory. Here is an example:
all_hosts = [ "switch14a|snmp", # SNMP host "switch14b|test|snmp", # SNMP host "hostfoo17|othertag|linux", # agent based host (TCP port 6556) "hostfoo17|tcp|othertag|linux", # another agent based host "hostfoo17|tcp|snmp|othertag|linux", # host queried with TCP and SNMP "hostfoo18|ping", # PING-only host ]
2.3. 3. The SNMP community
Check_MK needs to know your SNMP community. If it is "public", you do not need to configure it - it is the default. Otherwise set your company-wide default community in main.mk with the variable snmp_default_community:
snmp_default_community = "this-is-secret"
If some devices have other communities, you need to configure them in the configuration list snmp_communities. It is compatible to datasource_programs. The easiest way is to use host tags. Lets assume you have switches with different communities in Munich and Berlin. First tag them accordingly in all_hosts
all_hosts = [ "switch14a|munich|snmp", "switch14b|munich|snmp", "switch14c|berlin|snmp", "switch14d|berlin|snmp", ]
Now you make use of these tags when assigning the communities. Please do not leave out the ALL_HOSTS and also make sure that you put the host tag into a Python-list (square brackets):
snmp_communities = [ ( "muc-secret", ["munich"], ALL_HOSTS ), ( "ber-secret", ["berlin"], ALL_HOSTS ), ]
Single hosts can more easily be configured without host tags. The following example defines an exception for the host switch14a. It shall have the SNMP community testpublic. Exceptions must always be put at the front of your list since the first match decides about the result:
snmp_communities = [ ( "testpublic", ["switch14a"] ), # This switch uses "testpublic" ( "muc-secret", ["munich"], ALL_HOSTS ), ( "ber-secret", ["berlin"], ALL_HOSTS ), ]
If you are unsure if your configuration is correct, you can use check_mk with -D in order to dump out the net result of main.mk:
2.4. 4. Inventory
The inventory of SNMP checks works very similar to the inventory of agent based checks. The internal process is a bit different, but the handling by the user is identical. Simply call cmk -I HOSTNAME - as usual.
2.5. 5. Supported checks
In order to learn which types of SNMP checks your version of Check_MK provides, please call check_mk -L and grep for snmp:
user@host> check_mk -L | grep snmp blade_bays snmp no yes BAY %s blade_misc snmp yes yes SENSOR %s blade_powerfan snmp yes yes Power Module Cooling Device %s blade_powermod snmp no yes Power Module %s bluecoat_diskcpu snmp yes yes %s bluecoat_sensors snmp yes yes %s cisco_fan snmp no yes %s cisco_locif snmp yes yes Port %s cisco_power snmp no yes %s cisco_temp snmp yes yes %s df_netapp snmp yes yes fs_%s fc_brocade_port snmp yes yes PORT %s fsc_fans snmp yes yes FSC %s fsc_subsystems snmp no yes FSC %s fsc_temp snmp yes yes FSC TEMP %s ifoperstatus snmp yes yes Interface %s ironport_misc snmp yes yes %s snia_sml snmp no yes SNMP %s
For more information about a specific check please refer to the check manual of the check type in question. Alternatively you can use the command cmk -M check_type to get the manpage of a specific check type. With the man pages, you'll also learn if you need to install a specific SNMP MIB file. Only a few checks need that. Because of copyright issued those MIB files are not shipped together with Check_MK. You hardware vendors should supply them for you. Please refer to the check type in question for further information.
3. Using SNMP V2c and bulk walk
Per default Check_MK uses SNMP Version 1, because this version is most widely supported. Most devices also support version 2c in these days. Using SNMP V2c has two advantages:
The 64 bit data types are important for traffic monitoring on switch- and FC-ports when more than 2 GB of traffic pre check interval goes over these ports. They are also needed for NetAPP filers with volumes larger then 2 TB.
The bulk walk saves CPU ressources on the Nagios host and also network bandwidth by packing several SNMP variables into a single UDP packet rather than sending one packet per variable.
You can cctivate SNMP v2c and bulk walk by configuring hosts in bulkwalk_hosts. The following example activates SNMP v2c and bulk walk for all hosts without the tag nobulk:
bulkwalk_hosts += [ ( [ "!nobulk" ], ALL_HOSTS ), ]
So hosts not supporting SNMP v2c need to get the tag nobulk and are then set to be queried with SNMP v1:
all_hosts += [ "oldswitch01|nobulk", "oldswitch02|nobulk", ]
4. Using SNMP V3 with Check_MK
NEW in 1.1.7i1
SNMPv2c is the most commonly used version of SNMP today. But the more secure version SNMPv3 becomes increasingly popular. Therefore, beginning with 1.1.7i1 SNMPv3 can be used for all the SNMP checks available in Check_MK.
Using SNMPv3 in Check_MK is easy! The main difference between V3 and the previous versions of SNMP lies in the authentication. When building up a SNMPv3 connection, instead of a community you need four parameters, which are documented in the system man-page of snmpcmd:
As of version 1.1.8b1, it is possible to add two further arguments:
We recommend to first try out a snmpwalk -v3 and manually probe the correct settings of those four options before setting up Check_MK. Once you know the correct values, integration in Check_MK is easy. When defining snmp_communities simply define a four- or six-tuple of strings instead of a community string. Here is an example for a single host using SNMPv3:
snmp_communities = [ # This host uses V3: ( ( "authPriv", "md5", "secname123", "x&ab%498" ), [ "switch0815" ] ), ]
As always, host tags can be handy here. If all your devices share the same secret, you could use a tag - say v3 - marking your SNMPv3 devices.
all_hosts = [ "switch0815|snmp|v3", # SNMPv3 switches "switch0816|snmp|v3", "switch0817|snmp|v3|priv", "switch0225|snmp", # SNMP v1 or v2 hosts "switch0226|snmp", ] snmp_communities = [ # Hosts not using V3 ( "notpublic" , [ "!v3" ], ALL_HOSTS ), # Hosts using V3 ( ( "authPriv", "sha", "secname123", "x&ab%498" ), [ "v3" ], ALL_HOSTS ), # Hosts using V3 and Encryption ( ( "authPriv", "sha", "secname123", "x&ab%498", "AES", "secPassphrase"), [ "v3", "priv" ], ALL_HOSTS ), ]