In diesem Artikel wird noch nicht die grafische Benutzeroberfläche der Checkmk Version 2.0.0 gezeigt und beschrieben. Wir werden diesen Artikel so schnell wie möglich aktualisieren.
1. Einleitung
Die Services sind das eigentliche Fleisch im Monitoringsystem. Jeder Einzelne von ihnen repräsentiert ein wichtiges Rädchen ihn Ihrer komplexen IT-Landschaft. Die Nutzen des ganzen Monitorings steht und fällt damit, wie treffsicher und sinnvoll die Services konfiguriert sind. Schließlich soll das Monitoring zuverlässig melden, wenn sich irgendwo ein Problem abzeichnet, aber auf der anderen Seite falsche und nutzlose Alarme unbedingt vermeiden.
Bei der Konfiguration der Services zeigt Checkmk seine vielleicht größte Stärke: Es verfügt über ein einzigartiges und sehr mächtiges System für eine automatische Erkennung und Konfiguration von Services. Sie müssen mit Checkmk nicht jeden einzelnen Service über Schablonen und Einzelzuweisungen definieren. Denn Checkmk kann die Liste der zu überwachenden Services sehr zuverlässig automatisch ermitteln und vor allem auch aktuell halten. Das spart nicht nur sehr viel Zeit — es macht das Monitoring auch genauer. Denn es stellt sicher, dass die täglichen Änderungen im Rechenzentrum auch immer zeitnah im Monitoring abgedeckt werden und kein wichtiger Dienst ohne Monitoring bleibt.
Die Serviceerkennung in Checkmk basiert auf einem wichtigen Grundprinzip: der Trennung des Was vom Wie:
Was soll überwacht werden? → Das Dateisystem
/varauf dem Host `lnxsrv015`Wie soll es überwacht werden? → Bei 90% belegtem Platz WARN, bei 95% CRIT
Das Was wird bei der Serviceerkennung automatisch ermittelt. Es
setzt sich aus dem Hostnamen (lnxsrv015), dem
Check-Plugin (df: Dateisystemcheck
unter Linux) und dem Item (/var) zusammen. Check-Plugins, die auf
einem Host maximal einen Service erzeugen können, benötigen kein Item
(z.B. das Check-Plugin für die CPU-Ausnutzung). Das Ergebnis der Erkennung
ist eine Tabelle, die Sie sich so vorstellen können:
| Host | Check-Plugin | Item |
|---|---|---|
lnxsrv015 | df | / |
lnxsrv015 | df | /var |
lnxsrv015 | cpu.util | |
… | … | … |
app01cz2 | hr_fs | / |
… | … | … |
Das Wie — also die Schwellwerte/Checkparameter für die
einzelnen Services — wird unabhängig davon über Regeln
konfiguriert. Sie können z.B. eine Regel aufstellen, dass alle Dateisysteme mit
dem Mountpunkt /var mit den Schwellwerten 90%/95% überwacht werden,
ohne sich dabei Gedanken machen zu müssen, auf welchen Hosts denn nun
überhaupt so ein Dateisystem existiert. Das ist es, was die Konfiguration mit
Checkmk so einfach und übersichtlich macht!
Einige wenige Services können nicht über eine automatische Erkennung eingerichtet werden. Dazu gehören z.B. Checks, die per HTTP bestimmte Webseiten abrufen sollen. Diese werden per Regeln angelegt; wie, erfahren Sie weiter unten.
2. Services eines Hosts in WATO
2.1. Host neu aufnehmen
Nachdem Sie einen neuen Host in WATO aufgenommen haben, ist der nächste Schritt, die Liste der Services aufzurufen. Hierbei läuft bereits das erste Mal die Serviceerkennung für den Host. Sie können diese Liste auch jederzeit später wieder aufrufen, um die Erkennung neu zu starten oder Anpassungen an der Konfiguration vorzunehmen. Sie erreichen die Serviceliste auf verschiedene Arten:
über die Knöpfe
und 
in den Details eines Hosts in WATOüber das Symbol
in der Liste der Hosts in einem Ordner in WATOüber den Eintrag
Edit services im Kontextmenü des Services Check_MK Discovery eines Hosts
Wenn der Host gerade neu aufgenommen wurde, ist noch kein Service konfiguriert und daher erscheinen alle gefundenen Services in der Rubrik Undecided services (currently not monitored:
Der übliche Weg ist nun einfach das Hinzufügen der Services über 
. Danach ein
Activate changes und schon ist der Host samt Services im Monitoring.
2.2. Fehlende Services hinzufügen
Bei einem Host, der bereits überwacht wird, sieht diese Liste anders aus. Anstelle von Undecided services (currently not monitored sehen Sie Monitored services. Sollte Checkmk allerdings feststellen, dass es auf dem Host etwas gibt, das aktuell nicht überwacht wird, aber überwacht werden sollte, dann sieht das etwa so aus:
Ein Klick auf fügt abermals alle fehlenden Services hinzu, so dass
die Überwachung wieder vollständig ist. Wenn Sie nur manche der fehlenden
Services aufnehmen möchten, können Sie diese alternativ über die Checkboxen auswählen
und ebenfalls mit speichern.
2.3. Verschwundene Services
Im Rechenzentrum können Dinge nicht nur neu auftauchen, sondern auch verschwinden. Eine Datenbankinstanz wird abgeschafft, eine LUN ausgehängt, ein Dateisystem entfernt u.s.w. Checkmk erkennt solche Services dann automatisch als verschwunden (vanished). In der Serviceliste sieht das z.B. so aus:
Der einfachste Weg um diese Services loszuwerden ist ein Klick auf den in so einem Fall
erscheinenden Knopf 
. Achtung: Der Grund für das Verschwinden
kann durchaus auch ein Problem sein! Das Verschwinden eines Dateisystems kann ja auch
bedeuten, dass dieses aufgrund eines Fehlers nicht gemounted werden konnte. Und für solche
Fälle ist das Monitoring schließlich da! Sie sollten den Service also nur dann entfernen,
wenn Sie wissen, dass hier eine Überwachung auch wirklich keinen Sinn mehr macht.
2.4. Ungewünschte Services loswerden
Nicht alles, was Checkmk findet, möchten Sie auch unbedingt überwachen. Zwar arbeitet die Erkennung durchaus zielgerichtet und kann schon viel Unnützes im Vorfeld ausschließen. Doch woher soll Checkmk z.B. wissen, dass eine bestimmte Datenbankinstanz nur zum „Herumspielen“ eingerichtet wurde und nicht produktiv ist? Sie können solche Services auf zwei Arten loswerden:
Vorübergehendes Abschalten von Services
Setzen Sie einfach bei den Services, die nicht überwacht werden sollen,
die Häkchen in den Checkboxen und deaktivieren Sie sie mit 
oder setzten Sie sie mit 
auf den Status Unentschieden/Neu.
Und natürlich, wie immer Activate changes nicht vergessen …
Das Ganze ist allerdings nur für vorübergehende und kleinere Maßnahmen gedacht. Denn die so abgewählten Services werden von Checkmk dann wieder als missing angemahnt. Und der Discovery Check (den wir Ihnen weiter unten zeigen) wird ebenfalls nicht glücklich damit sein. Außerdem ist das in einer Umgebung mit ein paar zigtausend Services einfach zu viel Arbeit und nicht wirklich praktikabel …
Permanentes Abschalten von Services
Viel eleganter und dauerhafter ist das permanente Ignorieren von Services mit Hilfe des Regelsatzes Disabled services. Hier können Sie nicht nur einzelne Services vom Monitoring ausschließen, sondern Regeln wie „Auf dem Host myhost sollen keine Services überwacht werden, die mit backup beginnen.“ formulieren.
Sie erreichen die Regel über WATO > Host & Service Parameters > Monitoring Configuration.
Wenn Sie die Regel speichern und erneut auf die Serviceliste des Hosts gehen, finden Sie die stillgelegten Services gemeinsam mit manuell deaktivierten Services unter Disabled Services.
2.5. Services auffrischen
Es gibt einige Check-Plugins, die sich während der Erkennung Dinge merken. So merkt sich z.B. das Plugin für Netzwerkinterfaces die Geschwindigkeit, auf die das Interface während der Erkennung eingestellt war. Warum? Um Sie zu warnen, falls sich diese ändert! Es ist selten ein gutes Zeichen, wenn ein Interface mal auf 10MBit, mal auf 1GBit eingestellt ist — eher ein Hinweis auf eine fehlerhafte Autonegotiation.
Was aber, wenn diese Änderung gewollt ist und von nun an als OK gelten soll?
Entfernen Sie entweder den Service via Checkbox und fügen Sie Ihn anschließend
wieder hinzu. Dazu müssen Sie nach dem Entfernen einmal Speichern. Oder Sie
drücken 
. Dann werden alle Services des
Hosts aufgefrischt und neu erkannt. Das ist natürlich viel bequemer — geht
aber nur, wenn Sie nicht einzelne Services im Fehlerzustand behalten wollen.
2.6. Besonderheiten bei SNMP
Bei Geräten, die per SNMP überwacht werden, gibt es ein paar Sonderheiten. Diese erfahren Sie im Artikel über SNMP.
3. Serviceerkennung für viele Hosts gleichzeitig
Wenn Sie die Erkennung für mehrere Hosts auf einmal machen wollen, können Sie sich die Arbeit mit WATOs Bulkoperationen erleichtern. Wählen Sie zunächst aus, auf welchen Hosts die Erkennung durchgeführt werden soll. Dazu haben Sie mehrere Möglichkeiten:
In einem Ordner die Checkboxen bei einzelnen Hosts ankreuzen und
drückenMit der Hostsuche Hosts suchen und beim Suchergebnis
drückenIn einem Ordner auf
klicken
Bei der dritten Variante können Sie die Serviceerkennung auch rekursiv in allen Unterordnern ausführen lassen. In allen drei Fällen gelangen Sie im nächsten Schritt zu folgendem Dialog:
Im Mode finden Sie genau die verschiedenen Möglichkeiten, die Sie auch in der Serviceliste in WATO haben und die wir schon weiter oben erläutert haben.
Unter Selection können Sie die Auswahl der Hosts noch mal steuern. Das ist vor allem dann sinnvoll, wenn Sie diese nicht per Checkboxen, sondern über den Ordner ausgewählt haben. Die meisten Optionen zielen auf eine Beschleunigung der Discovery hin:
Only include hosts that failed on previous discovery | Hosts, bei denen eine frühere Serviceerkennung per Bulkoperation fehlgeschlagen ist (z.B. weil der Host zu dem Zeitpunkt nicht erreichbar war), werden von WATO mit dem Symbol |
[.guihint]#Only include hosts with a failed discovery check # | Dies schränkt die Erkennung auf solche Hosts ein, bei denen der Discovery Check angeschlagen hat. Wenn Sie mit dem Discovery Check arbeiten, ist das eine gute Methode, um das Discovery von vielen Hosts massiv zu beschleunigen. Die Kombination mit der Option Refresh all services (tabula rasa) macht hier allerdings weniger Sinn, da dies den Status von bestehenden Services verfälschen kann. |
Exclude hosts where the agent is unreachable | Hosts, die nicht erreichbar sind, verursachen beim Discovery Wartezeiten durch Verbindungstimeouts. Dies kann das Discovery einer größeren Zahl von Hosts stark verlangsamen. Wenn die Hosts aber schon im Monitoring sind und dieses weiß, dass die Hosts DOWN sind, können Sie diese hiermit überspringen und die Timeouts somit vermeiden. |
Die Performance Options sind so voreingestellt, dass bei SNMP-Geräten immer ein Full Scan gemacht wird. Wenn Sie nicht auf neue Plugins aus sind, können Sie die Erkennung durch Wegnahme der Option beschleunigen. Das Arbeiten ohne Cachedateien ist nur in Ausnahmefällen ratsam. Insbesondere bei Hosts, die per Checkmk-Agent überwacht werden, kann es dann sogar dazu kommen, dass, wenn es der Zufall will, neue Logmeldungen quasi von der Discovery „verbraucht“ werden und nicht mehr beim eigentlichen Check ankommen.
Die eingestellte 10 unter Number of hosts to handle at once
bedeutet, dass immer zehn Hosts auf ein mal bearbeitet werden. Intern geschieht
das mit einem HTTP-Request. Sollten Sie Probleme mit Timeouts haben, weil
einzelne Hosts sehr lange zum Discovern brauchen, können Sie versuchen,
diese Zahl kleiner einzustellen (zulasten der Gesamtdauer).
Sobald Sie den Dialog bestätigen geht es los und Sie können den Fortschritt beobachten:
4. Checkparameter von Services
Viele der Check-Plugins können über Parameter konfiguriert werden. Die häufigste Anwendung ist das Setzen von Schwellwerten für WARN und CRIT. Parameter können aber auch deutlich komplexer aufgebaut sein, wie das Beispiel der Temperaturüberwachung mit Checkmk zeigt:
Die Checkparameter für einen Service werden in drei Schritten gebildet:
Jedes Plugin hat Defaultwerte für die Parameter.
Manche Plugins setzen Werte während der Erkennung (siehe oben).
Parameter können über Regeln gesetzt werden.
Dabei haben Parameter aus Regeln Vorrang vor den bei der Erkennung gesetzten und diese wiederum Vorrang für den Defaultwerten. Bei komplexen Parametern, bei denen per Checkbox einzelne Unterparameter festgelegt werden (wie im Beispiel mit der Temperatur), gilt diese Vorrangregel für jeden einzelnen Unterparameter separat. Wenn Sie also per Regel nur einen der Unterparameter anpassen, bleiben die anderen auf ihren jeweiligen Defaultwerten. So können Sie z.B mit einer Regel die Trendberechnung der Temperatur aktivieren und mit einer anderen die Temperaturschwellwerte für einen konkreten Sensor einstellen. Der komplette Parametersatz wird dann aus beiden Regeln zusammengesetzt.
Welche Parameter ein Service am Ende genau hat, erfahren Sie in
der Parameterseite des Services. Diese erreichen Sie in der Serviceliste
eines Hosts über das Symbol 
. Wenn Sie die Parameter
von allen Services direkt in der Servicetabelle sehen möchten, können
Sie diese mit dem Knopf 
einblenden.
Das sieht dann etwa so aus:
5. Anpassen der Serviceerkennung
Wie Sie die Serviceerkennung konfigurieren, um nicht erwünschte Services auszublenden, haben wir bereits weiter oben gezeigt. Es gibt aber für etliche Check-Plugins noch weitere Regelsätze, die das Verhalten der Discovery bei diesen Plugins beeinflussen. Dabei gibt es nicht nur Einstellungen zum Weglassen von Items, sondern auch solche, die positiv Items finden oder zu Gruppen zusammenfassen. Auch die Benennung von Items ist manchmal ein Thema — z.B. bei den Switchports, wo Sie sich entscheiden können, anstelle der Interface-ID dessen Description oder Alias als Item (und damit im Servicenamen) zu verwenden.
Alle Regelsätze, die mit der Serviceerkennung zu tun haben, finden Sie unter
Host & Services parameters > Parameters for discovered services > Discovery - automatic service detection.
Bitte verwechseln Sie diese Regelsätze nicht mit denen, die zum Parametrieren
der eigentlichen Services gedacht sind. Etliche Plugins haben in der Tat zwei
Regelsätze — einen für die Erkennung und einen für die Parameter. Dazu gleich
ein paar Beispiele.
5.1. Überwachung von Prozessen
Es wäre wenig sinnvoll, wenn Checkmk einfach für jeden Prozess, den es auf einem Host findet, einen Service für die Überwachung einrichten würde. Die meisten Prozesse sind entweder nicht interessant oder sogar nur vorübergehend vorhanden. Und auf einem normalen Linux-Server laufen mindestens hunderte von Prozessen.
Zum Überwachen von Prozessen müssen Sie daher mit manuellen Checks arbeiten oder — und das ist viel eleganter — der Serviceerkennung mit dem Regelsatz Process discovery sagen, nach welchen Prozessen sie Ausschau halten soll. So können Sie immer dann, wenn auf einem Host bestimmte interessante Prozesse gefunden werden, dafür automatisch eine Überwachung einrichten lassen.
Folgende Abbildung zeigt eine Regel im Regelsatz Process discovery,
welche nach Prozessen sucht, die das Programm /usr/sbin/apache2
ausführen. In diesem Beispiel wird für jeden unterschiedlichen
Betriebssystembenutzer, für den ein solcher Prozess gefunden wird,
ein Service erzeugt (Grab user from found processes). Der Name des Services
wird Apache %u, wobei das %u durch den Benutzernamen ersetzt
wird. Als Schwellwerte für die Anzahl der Prozessinstanzen werden 1/1 (untere)
bzw. 30/60 (obere) verwendet:
Bitte beachten Sie, dass die festgelegten Schwellwerte Default parameters for detected services heißen. Denn Sie können diese — wie bei allen anderen Services auch — per Regel überdefinieren. Zur Erinnerung: Obige Regel konfiguriert die Erkennung der Services — also das Was. Sind die Services erst mal vorhanden, so ist eigentlich die Regelkette State and count of processes für die Schwellwerte zuständig.
Die Tatsache, dass Sie schon bei der Erkennung Schwellwerte festlegen können, ist nur der Bequemlichkeit geschuldet. Und es gibt auch einen Haken: Änderung in der Erkennungsregel haben erst bei der nächsten Erkennung Einfluss. Wenn Sie also Schwellwerte ändern, müssen Sie die Erkennung nochmal ausführen. Wenn Sie aber die Regel nur zum eigentlichen Finden verwenden (also das Was), und den Regelsatz State and count of processes für das Wie verwenden, haben Sie dieses Problem nicht.
Um bestimmte oder einzelne Prozesse auf einem Windows-Host zu überwachen, muss im Feld Executable tatsächlich nur der Dateiname ohne Pfad angegeben werden. In Windows finden Sie diese Namen im Reiter Details des Windows Task Managers. In der Regel Process Discovery könnte das für den Prozess svchost dann wie folgt aussehen:
Weitere Details zur Prozesserkennung finden Sie in der 
Onlinehilfe dieses Regelsatzes.
5.2. Überwachung von Windows-Diensten
Das Erkennung und Parametrieren der Überwachung von Windows-Services geht analog zu den Prozessen und wird über die Regelsätze Windows Service Discovery (Was) bzw. Windows services (Wie) gesteuert. Hier ist ein Beispiel für eine Regel, die nach zwei Diensten Ausschau hält:
Genau wie bei den Prozessen ist auch hier die Serviceerkennung nur eine Option. Wenn Sie anhand von Hostmerkmalen und Ordnern präzise Regeln formulieren können, auf welchen Hosts bestimmte Dienste erwartet werden, können Sie auch mit manuellen Services arbeiten. Das ist dann unabhängig von der tatsächlich vorgefundenen Situation — allerdings kann das deutlich mehr Aufwand sein, da Sie unter Umständen viele Regeln brauchen, um genau abzubilden, auf welchem Host welche Dienste erwartet werden.
5.3. Überwachung von Switchports
Checkmk verwendet für die Überwachung von Netzwerkschnittstellen von Servern und für die Ports von Ethernetswitchen die gleiche Logik. Vor allem bei den Switchports sind die vorhandenen Optionen für die Steuerung der Serviceerkennung interessant, auch wenn (im Gegensatz zu den Prozessen und Windowsdiensten) die Erkennung auch erst mal ohne Regel funktioniert. Per Default überwacht Checkmk nämlich automatisch alle physikalischen Ports, die gerade den Zustand UP haben. Der Regelsatz dazu heißt Network Interface and Switch Port Discovery und bietet zahlreiche Einstellmöglichkeiten, die hier nur gekürzt dargestellt sind:
Am wichtigsten sind folgende Möglichkeiten:
Verwendung der Description oder des Alias im Servicenamen
Einschränken oder Ausweiten der überwachten Interfacetypen oder -namen
6. Services manuell einrichten
Es gibt einige Situationen, in denen eine automatische Serviceerkennung nicht sinnvoll ist. Das ist immer dann der Fall, wenn Sie das Einhalten einer bestimmte Richtlinie erzwingen möchten. Wie Sie im vorherigen Kapitel gesehen haben, können Sie Überwachung von Windows-Diensten automatisch einrichten lassen, wenn diese gefunden werden. Was ist aber, wenn schon das Fehlen eines solchen Diensts ein Problem darstellt? Beispiele:
Auf jedem Windows-Host soll ein bestimmter Virenscanner installiert sein.
Auf jedem Linux-Host soll NTP konfiguriert sein.
In solchen Fällen können Sie Services manuell anlegen. Der Einstiegspunkt
dafür ist das WATO-Modul 
Manual Checks.
Dahinter verbirgt sich eine Sammlung von Regelsätzen, welche
exakt die gleichen Namen haben, wie diejenigen Regelsätze, mit denen auch
Parameter für diese Checks konfiguriert werden.
Die Regeln unterscheiden sich jedoch in zwei Punkten:
Es sind Regeln für Hosts, nicht für Services. Die Services werden ja erst durch die Regeln erzeugt.
Da keine Erkennung stattfindet, müssen Sie selbst das Check-Plugin auswählen, das für den Check verwendet werden soll.
Folgendes Beispiel zeigt den Rumpf der Regel State of NTP time synchronisation unter Manual Checks:
Neben den Schwellwerten legen Sie hier auch das Check-Plugin fest
(z.B. chrony oder ntp.time). Bei Check-Plugins, die ein
Item benötigen, müssen Sie auch dieses angeben. Dies ist z.B. beim Plugin
oracle_processes notwendig, welches die Angabe der zu überwachenden
Datenbank-SID benötigt:
Der so definierte manuelle Service wird auf allen Hosts angelegt, auf die diese Regel greift. Für die eigentliche Überwachung gibt es jetzt drei Fälle:
Der Host ist korrekt aufgesetzt und der Service geht auf OK.
Der Agent liefert die Information, dass der gefragte Dienst nicht läuft oder ein Problem hat. Dann geht der Service auf CRIT oder auf UNKNOWN.
Der Agent stellt überhaupt keine Informationen bereit, z.B. weil NTP überhaupt nicht installiert ist. Dann bleibt der Service auf PEND und der Checkmk-Service geht auf WARN, mit dem Hinweis, dass die entsprechende Sektion in den Agentendaten fehlt.
Die meisten Regelsätze im Modul Manual Checks werden Sie nie
benötigen und sind nur der Vollständigkeit halber vorhanden.
Die häufigsten Fälle für manuelle Checks sind:
Überwachung von Windows-Diensten (Regelsatz: Windows Services)
Überwachung von Prozessen (Regelsatz: State and count of processes)
7. Der Discovery Check
In der Einleitung haben wir versprochen, dass Checkmk die Liste der Services nicht nur automatisch ermitteln, sondern auch aktuell halten kann. Natürlich wäre dafür eine Möglichkeit, dass Sie ab und zu von Hand eine Bulkerkennung über alle Hosts durchführen.
7.1. Automatisches Prüfen auf nicht überwachte Services
Viel besser ist dafür aber ein regelmäßiger Discovery Check, welcher von Checkmk bei neuen Instanzen automatisch eingerichtet wird. Dieser Service existiert für jeden Host und meldet sich mit einer Warnung, wenn er nicht überwachte Dinge findet:
Die Einzelheiten zu den nicht überwachten oder verschwundenen Services finden Sie im Long output of check plugin in den Details des Services:
Zu der Serviceliste der Hosts in WATO gelangen Sie bequem über das 
Kontextmenü
des Discovery Checks über den Eintrag Edit services.
Wenn Ihre Instanz von einer älteren Version geupdated wurde, müssen Sie diesen Check von Hand einrichten. Das Einrichten und auch das Parametrieren des Discovery Checks geht sehr einfach über den Regelsatz Periodic service discovery. Im Parameterbereich der Regeln haben Sie folgende Einstellmöglichkeiten:
Neben dem Intervall, in dem der Check laufen soll, und dem Monitoringstatus, für die Fälle von nicht überwachten bzw. verschwundenen Services, können Sie dabei auch noch auswählen, ob bei SNMP-Geräten ein SNMP-Scan stattfinden soll.
7.2. Services automatisch hinzufügen
Sie können den Discovery Check fehlende Services automatisch hinzufügen lassen. Dazu aktivieren Sie die Option Automatically update service configuration. Nun werden weitere Optionen sichtbar.
Neben dem Hinzufügen können Sie bei Mode auch auswählen, überflüssige Services zu entfernen oder sogar alle bestehenden Services zu entfernen und komplett neu zu erkennen (Refresh). Beide Optionen sind mit Vorsicht zu genießen! Ein verschwundener Service kann auf ein Problem hindeuten! Der Discovery Check wird so einen Service dann einfach entfernen und Sie im Glauben wiegen, dass alles in Ordnung ist. Der Refresh ist besonders gefährlich. So übernimmt z.B. der Check für Switchports nur solche Ports in das Monitoring, die up sind. Ports mit Status down gelten dann als verschwunden und würden vom Discovery Check ohne Rückfrage weggeräumt!
Ein weiteres Problem gilt es noch zu bedenken: Das Hinzufügen von Services oder gar das automatische Activate Changes kann Sie als Admin bei Ihrer Arbeit am System stören, wenn Sie gerade beim Konfigurieren sind. Es kann theoretisch passieren, dass Sie gerade dabei sind, an Regeln und Einstellungen zu arbeiten und just in dem Augenblick ein Discovery Check Ihre Änderungen aktiviert. Denn WATO kann immer nur alle Änderungen auf einmal aktivieren! Um dies zu verhindern, können Sie die Uhrzeiten, in denen so etwas geschieht, z.B. in die Nacht legen. Die obige Abbildung zeigt dafür ein Beispiel.
Die Einstellung Group discovery and activation for up to sorgt dafür, dass nicht jeder einzelne Service, der neu gefunden wird, sofort ein Activate Changes auslöst, sondern eine bestimmte Zeit gewartet wird, um gleich mehrere Änderungen in einem Rutsch zu aktivieren. Denn selbst wenn der Discovery Check auf ein Intervall von zwei Stunden oder mehr eingestellt ist, gilt das nur für jeden Host separat. Die Checks laufen nicht für alle Hosts gleichzeitig — und das ist auch gut so, denn der Discovery Check braucht erheblich mehr Ressourcen als ein normaler Check.
8. Passive Services
Passive Services sind solche, die nicht von Checkmk aktiv angestoßen werden, sondern bei denen regelmäßig von außen neue Checkergebnisse eingeschleust werden. Dies geschieht in der Regel über die Kommandopipe des Cores. Hier ist ein Schritt-für-Schritt-Vorgehen für das Einrichten eines passiven Services:
Zunächst müssen Sie den Service dem Kern bekannt machen. Dies geschieht mit dem gleichen Regelsatz wie bei den eigenen aktiven Checks, nur dass Sie die Command line weglassen:
Die Abbildung zeigt auch, wie Sie prüfen lassen können, ob regelmäßig Checkergebnisse eingehen. Wenn dies für länger als 10 Minuten ausbleibt, so wird der Service hier automatisch auf UNKNOWN gesetzt.
Nach einem Activate Changes beginnt der neue Service sein Leben im Zustand PEND:
Das Senden der Checkergebnisse geschieht nun auf der Kommandozeile durch
ein echo des Befehls PROCESS_SERVICE_CHECK_RESULT in die
Kommandopipe ~/tmp/run/nagios.cmd.
Die Syntax entspricht den bei Nagios üblichen Konventionen — inklusive eines
aktuellen Zeitstempels in eckigen Klammern. Als Argumente nach dem Befehl
brauchen Sie den Hostnamen (z.B. myhost) und den gewählten
Servicenamen (im Beispiel BAR). Die beiden weiteren Argumente sind
wieder der Status (0 … 3) und die Pluginausgabe. Den
Zeitstempel erzeugen Sie mit $(date +%s):
OMD[mysite]:~$ echo "[$(date +%s)] PROCESS_SERVICE_CHECK_RESULT;myhost;BAR;2;Something bad happened" > ~/tmp/run/nagios.cmdNun zeigt der Service ohne Verzögerung den neuen Status:
Wenn Sie von Nagios noch das Werkzeug NSCA kennen, können Sie das auch mit Checkmk weiterverwenden. Dazu müssen Sie zuerst das eine Abhängigkeit auflösen und das Paket libmcrypt installieren:
Debian/Ubuntu
root@linux$ apt-get install libmcrypt4Red Hat / CentOS
root@linux$ yum install libmcryptSLES
root@linux$ zypper install libmcryptSchalten Sie anschließend den NSCA-Empfänger mittels omd config ein und
bearbeiten Sie nach Bedarf die Konfiguration für NSCA, welche unter
etc/nsca/nsca.cfg liegt:
OMD[mysite]:~$ omd stop
OMD[mysite]:~$ omd config set NSCA on
OMD[mysite]:~$ omd config set NSCA_TCP_PORT 5667
OMD[mysite]:~$ vim etc/nsca/nsca.cfg
OMD[mysite]:~$ omd startDas System ist dann zum Empfang von passiven Checkergebnissen via NSCA bereit.
9. Serviceerkennung auf der Kommandozeile
So schön eine GUI ist, so praktisch ist doch manchmal noch die gute alte Kommandozeile — sei es zum Automatisieren oder einfach zum schnellen Arbeiten für den geübten Benutzer.
Die Serviceerkennung können Sie auf der Kommandozeile mit dem Befehl cmk -I auslösen.
Dabei gibt es ein paar verschiedene Spielarten. Bei allen empfehlen wir die Option -v,
damit Sie sehen, was genau passiert. Ohne -v verhält sich Checkmk nach guter alter
Unix-Tradition: Solange alles gut geht, schweigt es.
Mit einem einfachen -I suchen Sie auf allen Hosts nach neuen Services:
OMD[mysite]:~$ cmk -vI
switch-cisco-c4000:
nothing new
switch-cisco-c4500:
nothing new
switch-cisco-c4500-2:
nothing new
switch-cisco-c4500-3:
nothing newSie können nach dem -I auch einen oder mehrere Hostnamen angeben, um nur diese zu discovern.
Das hat gleich noch einen zweiten Effekt. Während ein -I auf allen Hosts
grundsätzlich nur mit gecachten Daten arbeitet, holt Checkmk bei der
expliziten Angabe von einem Host immer frische Daten!
OMD[mysite]:~$ cmk -vI myhost123Alternativ können Sie über Tags filtern:
OMD[mysite]:~$ cmk -vI @mytagDamit würde das Discovery für alle Hosts mit dem Hostmerkmal mytag durchgeführt.
Filtern mit Tags steht für alle cmk-Optionen zur Verfügung, die mehrere Hosts akzeptieren.
Mit den Optionen --cache bzw. --no-cache können Sie die Verwendung
von Cache auch explizit bestimmen.
Zusätzliche Ausgaben bekommen Sie mit einem zweiten -v. Bei SNMP-basierten Geräten
können Sie dann sogar jede einzelne OID sehen, die vom Gerät geholt wird:
OMD[mysite]:~$ cmk -vvI myswitch123
Discovering services on myswitch123:
myswitch123:
SNMP scan:
Getting OID .1.3.6.1.2.1.1.1.0: Executing SNMP GET of .1.3.6.1.2.1.1.1.0 on switch
=> ['24G Managed Switch'] OCTETSTR
24G Managed Switch
Getting OID .1.3.6.1.2.1.1.2.0: Executing SNMP GET of .1.3.6.1.2.1.1.2.0 on switch
=> ['.1.3.6.1.4.1.11863.1.1.3'] OBJECTID
.1.3.6.1.4.1.11863.1.1.3
Getting OID .1.3.6.1.4.1.231.2.10.2.1.1.0: Executing SNMP GET of .1.3.6.1.4.1.231.2.10.2.1.1.0 on switch
=> [None] NOSUCHOBJECT
failed.
Getting OID .1.3.6.1.4.1.232.2.2.4.2.0: Executing SNMP GET of .1.3.6.1.4.1.232.2.2.4.2.0 on switch
=> [None] NOSUCHOBJECT
failed.Ein komplettes Erneuern der Services (Tabula Rasa) machen Sie mit einem Doppel- -II:
OMD[mysite]:~$ cmk -vII myhost123
Discovering services on myhost123:
myhost123:
1 cpu.loads
1 cpu.threads
6 cups_queues
3 df
1 diskstat
3 kernel
1 kernel.util
3 livestatus_status
1 lnx_if
1 lnx_thermalSie können das Ganze auch auf ein einzelnes Check-Plugin einschränken. Die Option dazu
lautet --checks= und muss vor dem Hostnamen stehen:
OMD[mysite]:~$ cmk -vII --checks=df myhost123
Discovering services on myhost123:
myhost123:
3 dfWenn Sie fertig sind, können Sie mit cmk -O (bei Nagios als Kern cmk -R)
die Änderungen aktivieren:
OMD[mysite]:~$ cmk -O
Generating configuration for core (type cmc)...OK
Packing config...OK
Reloading monitoring core...OKUnd wenn Sie mal bei einer Discovery auf einen Fehler stoßen …
OMD[mysite]:~$ cmk -vII --checks=df myhost123
WARNING: Exception in discovery function of check type 'df': global name 'bar' is not defined
nothing … dann können Sie mit einem zusätzlichen --debug einen genauen Python-Stacktrace der
Fehlerstelle bekommen:
OMD[mysite]:~$ cmk --debug -vII --checks=df myhost123
Discovering services on heute:
heute:
Traceback (most recent call last):
File "/omd/sites/heute/share/check_mk/modules/check_mk.py", line 5252, in <module>
do_discovery(hostnames, check_types, seen_I == 1)
File "/omd/sites/heute/share/check_mk/modules/discovery.py", line 76, in do_discovery
do_discovery_for(hostname, check_types, only_new, use_caches, on_error)
File "/omd/sites/heute/share/check_mk/modules/discovery.py", line 96, in do_discovery_for
new_items = discover_services(hostname, check_types, use_caches, do_snmp_scan, on_error)
File "/omd/sites/heute/share/check_mk/modules/discovery.py", line 677, in discover_services
for item, paramstring in discover_check_type(hostname, ipaddress, check_type, use_caches, on_error):
File "/omd/sites/heute/share/check_mk/modules/discovery.py", line 833, in discover_check_type
discovered_items = discovery_function(info)
File "/omd/sites/heute/share/check_mk/checks/df", line 91, in inventory_df
foo = bar
NameError: global name 'bar' is not defined9.1. Optionen im Überblick
Hier noch mal alle Optionen auf einen Blick:
cmk -I | Neue Services erkennen. |
cmk -II | Alle Services verwerfen und neu erkennen (Tabula Rasa). |
-v | Verbose: Hosts und gefundene Services anzeigen. |
-vv | Very verbose: genaues Protokoll von allen Operationen anzeigen. |
--checks=foo | Erkennung (und auch Tabula Rasa) nur für das gewählte Check-Plugin durchführen. |
@foo | Erkennung (und auch Tabula Rasa) nur für Hosts mit dem gewählten Hostmerkmal durchführen. |
--cache | Verwendung von Cachedateien erzwingen (sonst nur bei fehlender Hostangabe). |
--no-cache | Frische Daten holen (sonst nur bei Angabe von Hostname). |
--debug | Im Fehlerfall abbrechen und den kompletten Aufrufstapel von Python anzeigen. |
cmk -O | Änderungen aktivieren (Enterprise Editions mit CMC als Kern.) |
cmk -R | Änderungen aktivieren (Raw Edition bzw. Nagios als Kern). |
9.2. Speicherung in Dateien
Das Ergebnis der Serviceerkennung — also die eingangs genannte Tabelle
von Hostname, Check-Plugin, Item und erkannten Parametern — finden Sie im
Verzeichnis var/check_mk/autochecks. Dort existiert für jeden Host
eine Datei, welche die automatisch erkannten Services speichert. Solange
Sie die Python-Syntax der Datei nicht verletzen, können Sie einzelne Zeilen
auch von Hand löschen oder ändern. Ein Löschen der Datei entfernt
alle Services und setzt diese quasi wieder auf „unmonitored“.
[
('cpu.loads', None, cpuload_default_levels),
('cpu.threads', None, threads_default_levels),
('diskstat', u'SUMMARY', diskstat_default_levels),
('kernel', u'Context Switches', kernel_default_levels),
('kernel', u'Major Page Faults', kernel_default_levels),
('kernel', u'Process Creations', kernel_default_levels),
('kernel.util', None, {}),
('livestatus_status', u'stable', {}),
('lnx_if', u'2', {'state': ['1'], 'speed': 0}),
('lnx_thermal', u'Zone 0', {}),
('mem.linux', None, {}),
('mknotifyd', u'heute', {}),
('mknotifyd', u'stable', {}),
('mounts', u'/', [u'data=ordered', u'errors=remount-ro', u'relatime', u'rw']),
('ntp.time', None, ntp_default_levels),
('omd_apache', u'stable', None),
('tcp_conn_stats', None, tcp_conn_stats_default_levels),
('uptime', None, {}),
]10. Servicegruppen
10.1. Wofür Servicegruppen?
Bis hierher haben Sie erfahren, wie Sie Services ins Monitoring aufnehmen. Nun macht es wenig Sinn, sich Listen mit Tausenden Services anzuschauen oder immer über Hostansichten zu gehen. Wenn Sie beispielsweise alle Dateisystem- oder Update-Services gemeinsam beobachten wollen, können Sie in ähnlicher Weise Gruppen bilden, wie das mit Hostgruppen möglich ist
Servicegruppen ermöglichen Ihnen auf einfach Art, über Ansichten und NagVis-Karten deutlich mehr Ordnung ins Monitoring zu bringen und gezielte Alarmierungen und Alert Handler zu schalten. Übrigens: Sie könnten entsprechende Ansichten fast immer auch rein über die Ansichten-Filter konstruieren — Servicegruppen sind aber einfacher und übersichtlicher zu handeln.
10.2. Servicegruppen anlegen
Sie finden Servicegruppen unter WATO > Host & Service Groups. Standardmäßig
erscheinen hier die Hostgruppen, klicken Sie also zunächst auf
. Dort finden Sie ein ähnliches Menü,
um die Service Gruppen zu definieren:
Das Anlegen einer Servicegruppe ist simpel: Legen Sie über
eine Gruppe an und vergeben Sie einen
später nicht mehr veränderbaren Namen sowie einen aussagekräftigen Alias:
10.3. Services in Servicegruppe aufnehmen
Für die Zuordnung von Services in Servicegruppen benötigen Sie den
Regelsatz Assignment of services to service groups,
zu finden unter WATO > Host & Service Parameters > Grouping. Erstellen Sie nun
über 
eine neue Regel im gewünschten
Ordner. Zunächst legen Sie fest, welcher Servicegruppe Services zugeordnet
werden sollen, hier beispielsweise myservicegroup beziehungsweise
dessen Alias My Service Group 1.
Der spannende Teil folgt nun im Bereich Conditions. Zum einen dürfen Sie hier über Ordner, Hostmerkmale und explizite Hostnamen Einschränkungen abseits der Services vornehmen. Zum anderen nennen Sie eben die Services, die Sie gerne gruppiert hätten, beispielsweise Filesystem und myservice, um eine Gruppe mit Dateisystemen zu erstellen. Die Angabe der Services erfolgt hier in Form Regulärer Ausdrücke. So können Sie Gruppen ganz exakt definieren.
10.4. Servicegruppen eines Services prüfen
Die Zuordnungen von Services können Sie auf der Detailseite eines jeweiligen Service prüfen. Hier finden Sie, standardmäßig weit unten, die Zeile Service groups the service is member of.
10.5. Servicegruppen einsetzen
Zum Einsatz kommen die Servicegruppen wie bereits erwähnt an mehreren Stellen: Ansichten, NagVis-Karten, Alarmierungen und Alert Handler. Bei neuen Ansichten ist hier wichtig, dass Sie als Datenquelle die Servicegroups setzen. Im Views-Widget finden Sie natürlich auch vordefinierte Ansichten für Servicegruppen, zum Beispiel eine übersichtliche Zusammenfassung:
Mit einem Klick auf die Servicegruppennamen gelangen Sie zur vollständigen Ansicht aller Services der jeweiligen Gruppe.
Wenn Sie Servicegruppen in NagVis-Karten einsetzen, bekommen Sie als Ergebnis beispielsweise Zusammenfassungen von Servicegruppen per Hover-Menü über ein einzelnes Icon:
Wenn Sie Servicegruppen in Alarmierungen und Alert Handlern nutzen, stehen sie als Bedingungen/Filter zur Verfügung, von denen Sie einen oder mehrere nutzen können:
11. Mehr über Check-Plugins
11.1. Kurze Beschreibung der Funktionsweise
Check-Plugins werden benötigt, um die Services in Checkmk zu erstellen. Jeder
Service greift auf ein Check-Plugin zurück, um seinen Status zu ermitteln,
Metriken zu erstellen/pflegen usw. Dabei kann ein solches Plugin einen oder
mehrere Services pro Host erstellen. Damit mehrere Services vom gleichen
Plugin unterschieden werden können, wird ein Item benötigt. So ist
z.B. beim Service Filesystem /var das Item der Text /var. Bei
Plugins, die pro Host maximal einen Service anlegen können (z.B. CPU
utilization), ist das Item leer und nicht sichtbar.
11.2. Verfügbare Check-Plugins
Eine Liste aller verfügbaren Check-Plugins finden Sie unter WATO > Check Plugins. Hier können Sie nach verschiedenen Kategorien gefiltert die einzelnen Plugins durchsuchen:
Zu jedem Plugin werden drei Spalten ausgegeben, die die Servicebeschreibung (Type of Check), den Namen des Check-Plugins (Plugin Name) und die kompatiblen Datenquellen (Agents) enthalten:
