Jens’ BLOG

A rather short post on check_mk today. Sometimes it is necessary to adjust warning and critical levels or disable automatically discovered checks.

The following example shows how to adjust warning and critcal levels for one of our servers:


check_parameters += [
( { "levels" : (90, 95)}, [ "www.example.com" ], [ "fs_/" ] ),
]

This example shows how to disable a check completely:


ignored_services = [
( [ "www.example.com" ], [ "Vmalloc address space" ] )
]


After a short introduction too check_mk we’ll now continue configuring our monitoring system. I’ll only use Icinga for this example, but everything should work with Nagios as well.

In the previous part of this tutorial we defined three hosts:

* router.example.com
* www.example.com
* www.example.net

Read more…

As mentioned in a previous last post I’m currently moving my monitoring setup from Nagios to Icinga and check_mk. This is the first of a series of articles about check_mk. I assume you are already have a running Nagios / Icinga setup.

Check_mk generates a Nagios / Icinga configuration for a given set of hosts and makes configuring large Setups quite easy. There is also a check_mk agent which allows it to automatically discover informations on the host where the agent is installed. Last but not least check_mk makes it quite easy to check host via SNMP.

After installing check_mk on your Nagios / Icinga Host you’ll add your host to the check_mk configuration file called main.mk.

On Debian (Squeeze) you can install via apt-get. I assume that you’ll want to monitor the monitoring server as well (This might lead to some problems if you haven’t installed Nagios / Icinga via apt-get.):


apt-get install check-mk-server check-mk-client


After the installation you can edit the main configuration file /etc/check_mk/main.mk Here is a small example:


all_hosts = [
'router.example.com|snmp|net',
'www.example.com|linux',
'www.example.net|PING',
]


There is a group all_hosts which contains the host which might be followed by one or more tags. Tags can be used to deiced how a host is queried (either PING, SNMP or using the check-mk agent. The check_mk client is the default method). Tags can also be used to create host and service groups, define legacy check (read classic Nagios checks) and so on.

So router.example.com will be quiried via SNMP, www.example.com via the check_mk agent and www.example.net will only be pinged.

After editing main.mk you can use check_mk -II to discover services on all the hosts specified in main.mk. After that check_mk -O generates the Nagios / Icinga configuration and restarts Nagios.

The agent is available for different operating system, including different Linux distributions, Solaris, Windows. The agent needs xinetd which should be installed automatically when you install the check_mk_agent with your distributions package management system. At least on Debian check_mk is disabled in /etc/xinetd.d/check_mk . Change it (one of the last lines) and restart xinetd.

So now all you have to do is install agents on different host and add those hosts to your main.mk.

Next up:

Part II: SNMP configuration and service checks, check_mk Options
Part III: Adjusting warning and critical levels and disabling checks
Part IV: Host and service groups and contacts
Part V: check_mk and monitoring of dual stacked hosts
Part VI: check_mk livestatus and the check_mk GUI

Today is the date. A lot more of content should be available via IPv6 today than before.

In my current project I helped the customer to get ready for this day. Was it hard? No. Where there problems? Yes. Is everything working? No.

So whats working:
* Network Routing (BGP, OSPFv3)
* Network Filtering
* Loadbalancer (Citrix Netscaler)
* Web (Apache) / Mail (Postfix) / DNS (Bind)
* The customers web portal (most of it)

And the problems during the implementation?
* Cisco IOS Bug(s) which lead to router crashes
* lack of IPv6 in some external resources used
* some config done years ago and then forgotten (well it took about
an hour or two to find it.)

So given the right people (sys-/netadmins, developers, management) it all was quite easy to move the website to dualstack setup.

Knowing your part of the infrastructure (network, servers, code) helps an so does talking to each other.I know places where something like this is impossible given the short amount of time used for implementing IPv6.

Nice idea: Create a customer support page, e.g. www.example.com/cs where you gather all relevant informations a customer might have to give to your support. Add some warnings for people using Teredo (2001::/32) or 6to4 (2002::/16).