OMD and check_mk with self-services – first technical experience (mainly SNMP devices)

If you are not into technical details watch out for my summary post (soon to come)!

In the last days I had some time to test out the new OMD beta (1.2.0b3).  Compared to the old version (1.1.x) there is one major change: WATO – the configuration interface of check_mk – is offering more functions. This is crucial to me, since my goal is that the administrators add their own hosts with WATO in the future.

Before the implementation of WATO you had to configure hosts manually in text files, which made it impossible to offer self-services (Note: “self-services” mean that every administrator is able to configure their own hosts and services – including warning and critical levels).

The installation of the OMD beta was done within minutes (one command!!!) – it is now running on a SuSE Linux Enterprise Server 11 with Service Pack 2.

Then I added several hosts to the test configuration including our Core-Switch (Cisco 6500 series), an Aggregation-Switch (Cisco 4500 series), an AKCP Environmental sensor, an old and new Access Switches (Cisco 2950/2960 series), a SAN Fiber Switch (Brocade), Loadbalancers (F5 and Kemp) and a few websites (check_http).



First I created a handful host folders in order to organize my hosts. Host folders have nothing to do with Nagios host groups – they just offer an opportunity to organize your hosts in folders. Since rules are put on folders, you may want to invest some time in planning those.

After adding the folders you are able to add hosts. And here is why check_mk is so special: it offers a self-inventory. Check_mk is shipped with a bunch of different check-plugins. These are not only able for querying the check_mk client on the remote servers, but also giving preconfigured SNMP checks. Long story short: It is absolutely amazing how much functionality you get out-of-the-box. Following is a short summary of my experiences with the above mentioned network devices (which most of them are SNMP devices).



As said before, I added different switches from different layers of our network: 6500 series Core Switches, 4500 series Concentration/Aggregation switches and 2950/2960 series Access Switches.

Before doing that, you should take a look at the Global Options in WATO: There a 7 options which might be interesting for you. For me the last 3 ones are very useful:

  • “Use alias as service name for network interface checks” is very useful since the inventory of a cisco switch will show you all interfaces but not the descriptions (which makes it hard to keep overview).
  • “Network interface port states to inventorize”: Without setting “yes” the inventory will only offer to monitor interfaces which are in up stage. This was a little bit confusing in the beginning.
  • “Network interface port types to inventorize”: Here you can set for which types of interfaces check_mk will watch out. For testing purposes I marked all types.

The inventory of the switches worked perfectly. All interfaces were recognized, aswell as the statuses of fans and temperature sensors. Additionally it was possible to monitor PortChannel (link aggregation). This might be interesting for you, since PortChannels are most likely used for the interconnections between the core devices.

After adding the interfaces you get following information: State, Port-Description (or alias), MAC, Port Speed, last check up/down bandwidth and average bandwidth (for a custom set ti

switchport monitoring

Cisco Switchport Monitoring

me range). However, port description was not available for the old Cisco 2950, which makes it harder to identify particular ports. Alle other devices (6500/4500/2960 series) worked perfectly. In the screenshot you can see what it looks like – the last column shows the perf-o-meter, a short visualization of the load.



For testing purposes I also added our Loadbalancers (Kemp Loadmaster and F5 BigIP) to the Test configuration.

Kemp: Out-of-the-box the inventory offered the following functions: monitoring of interfaces, cpu_load and some additional snmp information like uptime and firmware version.


Unfortunately it is not possible to monitor the health status of the Kemp´s virtual servers and services – well, at least it is not possible with the out-of-the-box configuration. What you can do is adding classical Nagios checks to check_mk. This can be done in the WATO configuration are und the bullet host & services parameters.

In the screenshot you can see how I added the check_loadmaster script mentioned in antoher article ( to check_mk and assigned it to the loadbalancers. After applying the configuration, check_mk adds the assigned services. It works as good as on a classical nagios installation – which is actually a big advandtage when you have to monitor devices which are not totally common in the it environment. This way you have the advantages both worlds: The easiness of check_mk paired with the wide variety of nagios plugins.

Inventory output for a Kemp loadmaster

Inventory output for a Kemp loadmaster. Checks are based on SNMP.

F5 BigIP: From the pricing of a F5 Loadbalancer you can tell: It´s a premium enterprise product. This I why my expectations are pretty high when it comes to SNMP monitoring. Check_MK is shipped with a bunch of onboard plugins. Some of them are specialized in monitoring F5 loadbalancers – so it was not a big surprise that the inventory gave me a big output. You can monitor fans, pools, temperature, PSU, virtual servers, file system, memory, interfaces and the usual snmp information. However, some fans seem to give back the wrong speed (or they are misinterpretated by the plug-in) as they have a value of 0 rpm. I also noticed that the memory usage is usually between 150 and 200 % – I may get  back to this problems later.


Other devices

Monitoring of the Brocade SAN switches is as easy as for the cisco ones – absolutely perfect.

Check_Http implementation

check_http configuration dialog.

AKCP environmental sensors where also recognized by the inventory and work great.

Check_http: WATO offers a very good configuration for the plug-in and it´s variables. For example you can set the behaviour for redirects, scanning for particular strings or authorization.


On last thing  I want to report about is the possibility of monitoring Riverbed WAN optimizer. Probably the most surprising feature so far: After the inventory I was able to monitor cpu load, connections, interfaces and memory usage. This is really cool – but even cooler is that the checks are shipped with amazing pnp templates. Maybe one of the big differences between classical nagios plugins and check_mk. Check_MK is not only about monitoring, it´s a complete product which also includes the pnp templates for suitable visualization of the performance data.


That is it for now. If you wonder why I didn´t add servers to my configuration, here´s the answer: I already know that check_mk is doing a great job monitoring servers. The goal of this first test was to verify if check_mk can handle special devices in our environment, because some of them even have more impact or value (environmental sensors for example) then a server itself.

Next step will be to do some paper work such as project structure and writing down project requirements.



About sitweak
Monitoring, Network, Firewall, Mobile Security. I´m totally into that stuff!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: