Quelltext der Seite Check MK

'''Check_MK''' is a plugin and extending framework for [[Nagios]] which works also under [[Icinga|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 [http://mathias-kettner.de/checkmk_localchecks.html 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 [http://mathias-kettner.de/checkmk.html#H1:Multisite Multisite website].

== Tips and Tricks ==
See:
*[http://www.monitoring-portal.org/wbb/index.php?page=Thread&threadID=21787 Managing Hosts]
*[http://www.mail-archive.com/checkmk-en@lists.mathias-kettner.de/msg04586.html split ipaddresses]
*[http://www.mail-archive.com/checkmk-en@lists.mathias-kettner.de/msg02077.html notification intervals with host tags]

== Official Check_MK Websites ==
*[http://mathias-kettner.de/check_mk.html Check_MK]
*[http://mathias-kettner.de/checkmk.html Documentation]

Support:
*[http://www.mail-archive.com/checkmk-en@lists.mathias-kettner.de/info.html Mailinglist (en)]
*[http://www.mail-archive.com/checkmk-de@lists.mathias-kettner.de/info.html Mailinglist (de)]

Plugins / Extensions:
*http://exchange.check-mk.org

== Other Resources ==
*[https://www.heinlein-support.de/sites/default/files/slac-2013_it-monitoring-check-mk_vortrag.pdf Monitoring Check MK Vortrag] (PDF)

== See also ==
*[[Icinga]]
*[[Nagios]]

[[Category:Monitoring]]