Check MK
Check_MK is a plugin and extending framework for Nagios which works also under Icinga 1 . Check_MK implements a new method of gathering monitoring data from hosts like disk usage, processes, application status and much more. It can replace NRPE, check_by_ssh and check_snmp. But it also can be used in addition to these standard methods for a seamless integration or rather step-by-step migration of exiting checks.
Benefits and Challenges
Some benefits of check_mk:
- Check_MK implements only one active check per host. All other regular checks are passive. Therefore, system load on the Nagios/Icinga server is lower or even much more checks can be implemented on the same server.
- Check_MK makes configuration of mass-checks easier since it has a built-in automatic inventory method by querying each host for available checks. There is no need to define each service check on the Nagios/Icinga server. (This can also be a disadvantage since you need to trust that automatically defined checks are well done and that it fits to your needs, see below.)
- The check_mk agent comes with a lot of pre-defined system checks which can replace the standard Nagios plugins.
- There are also plugins available to be (manually) installed on remote hosts, that create output similar to the check_mk agent.
- It's also possible to add local checks to the remote hosts.
- Check_MK can also run standard Nagios plugins on remote hosts (MRPE method).
- Warning and critical thresholds of inventoried checks are configured centrally on the server. Only MRPE and logwatcher checks are defined locally on the hosts.
Some disadvantages and challenges:
- Check_MK is different to usual plugins, since it implements more than just a check. So, it needs time to get familiar with it.
- check_mk is flexible but some configuration items are hard to use when multiple teams shall have a split config, i.e. in order to monitor different hosts and services.
- One badly set config option can affect some or all checks on some or all hosts if the automated inventory is used. It's easy to re-define or overwrite a check_mk config variable by another sourced config file - without warning.
- Since all checks are passive it's not possible to schedule single checks on a host. All passive checks on a host are processed at the same time (depended of the active check_mk check).
- A logwatch check needs to be acknowledged by Multisite/Livestatus GUI.
Multisite GUI
Check_MK introduces Multisite - a new and innovative GUI for viewing Nagios/Icinga status information and controlling your monitoring system. It is based on MK Livestatus and aims at replacing the Nagios web GUI (also known as "the CGIs"). Multisite supports distributed monitoring in a very efficient way.
See more info on the official Multisite website.
Tips and Tricks
See:
Official Check_MK Websites
Support:
Plugins / Extensions: