SNMP Checks

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 but provides access to vital data via SNMP. Most prominent member of those devices are network and Fibre Channel switches.

Check_MK supports monitoring via SNMP and ships a couple of 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:

• SNMP hosts have to be tagged with |snmp in all_hosts
• No Check_MK agent has to be installed on the target host.
• Data is fetched by Check_MK via UDP port 161 by calling snmpwalk or snmpbulkwalk as external program. Please make sure that you have those commands available (Debian/Ubuntu: package snmp, SUSE: package net-snmp).

Setting up SNMP checks with Check_MK

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 your Nagios server access via SNMP. Usually you have to configure:

• An IP address or network range that is allowed to retrieve SNMP data. Enter your Nagios server here.
• A read-only community for that address

What SNMP calls "community" is basically a password. The default is public. If you do not worry about security then you can use that; if that level of security is not enough for your environment, you can also use SNMPv3 which supports AES. Most devices support this by now and 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. Declaring hosts

When that works, you are ready to configure your host for Check_MK. Put it into all_hosts as usual, but add the host tag snmp the each SNMP based host. 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
]

3. The SNMP community

Check_MK needs to know your SNMP community. If that is "public", then you do not need to configure anything - that 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 sinde 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:

4. Inventory

The inventory of SNMP checks works very similar to the agent based checks. The internal process is a bit different but the handling by you is identical. Simply call cmk -I HOSTNAME - just as usual.

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. Here 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 check type in question for further information.

We also apologize for the fact that not all checks provide manual pages yet. We're working on that. Your contribution will be appreciated...

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:

• It supports 64 bit datatypes
• It supports bulk walk

The 64 bit datatypes are important for traffic monitoring on switch and FC ports if more than 2 GB of traffic goes over these ports per check interval, and important 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.

Activating SNMP v2c and bulk walk is done 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 ),
]

Hosts not supporting SNMP v2c can now easily be set to v1:

all_hosts += [
  "oldswitch01|nobulk",
  "oldswitch02|nobulk",
]

Using SNMP V3 with Check_MK

NEW in 1.1.7i1

SNMPv2c is the most commonly used version of SNMP these days. But the more secure version SNMPv3 becomes more popular. SNMPv3 can be used for all the SNMP check available in Check_MK now.

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 man-page of snmpcmd:

• The security level (option -l)
• The authentication protocol (option -a)
• The security name (option -u)
• The authentication password (-A)

As of version 1.1.8b1, it is possible to add two further arguments:

• The privacy protocol (DES or AES, option -x)
• The privacy pass phrase used for encrypted SNMPv3 messages (option -X)

We recommend first trying out a snmpwalk -v3 and manually probing the correct settings of those four options before setting up Check_MK. Once you know the correct values, integration in Check_MK is easy. Simply define a four- or six-tuple of strings instead of a community string for the hosts in question, when defining snmp_communities. 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 ),
]