SNMP Checks

1. How Checkmk 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.

Checkmk supports monitoring via SNMP and ships many SNMP checks for various devices ready to use. The basic principle is the same as with the Checkmk agent: Checkmk 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 Checkmk agent needs to be installed on the target host.
  • Data is fetched by Checkmk via UDP port 161 by calling snmpwalk or snmpbulkwalk as external program. Please make sure that you have these commands available (Debian/Ubuntu: package snmp, SUSE: package net-snmp).

2. Setting up SNMP checks with Checkmk

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:

  • 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" 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 Checkmk 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 with the community public:

user@host:~$ snmpget -v1 -c public 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 Checkmk. Put it into all_hosts as usual, but add the host tag snmp. Otherwise Checkmk 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

Checkmk 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 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 = [

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

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 Checkmk 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 Checkmk. You hardware vendors should supply them for you. Please refer to the 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...

3. Using SNMP V2c and bulk walk

Per default Checkmk 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 data types
  • It supports bulk walk

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 += [

4. Using SNMP V3 with Checkmk

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 Checkmk.

Using SNMPv3 in Checkmk 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:

  • 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 to first try out a snmpwalk -v3 and manually probe the correct settings of those four options before setting up Checkmk. Once you know the correct values, integration in Checkmk 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
  "switch0225|snmp",      # SNMP v1 or v2 hosts

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 ),