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:

• No Check_MK agent has to be installed on the target host.
• Data is via UDP port 161 (SNMP), not via TCP port 6556.
• Data is fetched 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).
• Inventory with alltcp does not find new checks - please see below.
• Fetched data is not cached.

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. In most cases 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.

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",   # normal host
 "hostfoo18",                  # normal 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

A speciality of SNMP checks is that the inventory must always be done explicitely. A check_mk -I alltcp will not scan for SNMP based checks. The reason is that for performance issues Check_MK will never retreive the complete SNMP tree of a device, but only those subtrees that are relevant for the configured checks.

The following example will scan the devices switch14a and switch14b for new checks of the type ifoperstatus:

root@linux# check_mk -I ifoperstatus switch14a switch14b
ifoperstatus          27 new checks

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 SNMPv3 with Check_MK

NEW in 1.1.7i1

SNMPv2 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:

1. The security level (option -l)
2. The authentication protocol (option -a)
3. The security name (option -u)
4. The authentication password (-A)

We recommend first trying out a snmpwalk -v3 and manually checkout 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-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",
  "switch0225|snmp",      # SNMP v1 or v2 hosts
  "switch0226|snmp",
]

snmp_communities = [
  # Hosts not using V3
  ( "notpublic", [ "!v3" ], ALL_HOSTS ), ),

  # Hosts using V3
  ( ( "authPriv", "md5", "secname123", "x&ab%498" ), [ "v3" ], ALL_HOSTS ),
]