Services

Letzte Aktualisierung: 05. Juli 2018


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 Check_MK seine vielleicht größte Stärke: Es verfügt über ein einzigartiges und sehr mächtiges System für eine auto­matische Erkennung und Konfiguration von Services. Sie müssen mit Check_MK nicht jeden einzelnen Service über Scha­blonen und Einzelzuweisungen definieren. Denn Check_MK 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 Check_MK basiert auf einem wichtigen Grundprinzip: der Trennung des Was vom Wie:

  • Was soll überwacht werden? → Das Dateisystem /var auf 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 Checkplugin (df: Dateisystemcheck unter Linux) und dem Item (/var) zusammens. Checkplugins, die auf einem Host maximal einen Service erzeugen können, benötigen kein Item (z. B. das Checkplugin für die CPU-Ausnutzung). Das Ergebnis der Erkennung ist eine Tabelle, die Sie sich so vorstellen können:

Host Checkplugin Item
lnxsrv015 df /
lnxsrv015 df/var
lnxsrv015cpu.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 Check_MK 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 Anpas­sungen 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 Available (missing) services:

Der übliche Weg ist nun einfach das Speichern mit . Danach ein Activate changes und schon ist der Host im Monitoring.

2.2. Fehlende Services hinzufügen

Bei einem Host, der bereits überwacht wird, sieht diese Liste anders aus. Anstelle von Missing (available) services sehen Sie Already configured services. Sollte Check_MK allerdings feststellen, dass es auf dem Host etwas gibt, das aktuell nicht überwacht wird, aber überwacht werden sollte, dann sieht das etwa so aus:

Obige Abbildung zeigt einen Windows-Host, auf dem ein Dateisystem D:\ gefunden wurde, welches aktuell nicht überwacht wird! Es könnte sein, dass ein Kollege hier eine neue LUN eingerichtet hat. Ein Klick auf fügt einfach 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 Check­boxen auswählen und mit speichern.

2.3. Verschwundene Services

Im Rechenzentrum können Dinge nicht nur neu auftauchen, sondern auch verschwinden. Eine Datenbank­instanz wird abgeschafft, eine LUN ausgehängt, ein Dateisystem entfernt u.s.w. Check_MK er­kennt 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 Check_MK 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 Check_MK 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

Entfernen Sie einfach bei den Services, die nicht überwacht werden sollen, die Häkchen in den Checkboxen und speichern Sie mit . 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 abge­wählten Services werden von Check_MK 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 Testsystemen möchte ich keine Dateisysteme überwachen, die mit /mnt/dsk be­ginnen“ formulieren. Das Symbol in der Serviceliste erleichtert das Neuanlegen von solchen Regeln, so dass Sie nicht den längeren Weg über das WATO-Modul Host & Service parameters gehen müssen:

Das bringt Sie direkt zum Anlegen einer neuen Regel, die für den aktuellen Ordner, Host und Service vorausgefüllt ist:

Sie können diese Regel sehr leicht auf alle Hosts verallgemeinern: Entfernen Sie einfach den Haken bei Specify explicit host names und – wichtig – setzen Sie den Folder auf Main directory. Natürlich können Sie wie immer bei den Regeln auch alle beliebigen anderen Bedingungen formulieren.

Wenn Sie die Regel speichern und erneut auf die Serviceliste des Hosts gehen, werden Sie den neuen Abschnitt Disabled services (configured away by admin) entdecken. Dieser dokumentiert alle so „still­gelegten“ Services:

2.5. Services auffrischen

Es gibt einige Checkplugins, 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 SNMP-Geräten erfolgt die Serviceerkennung intern ganz anders als bei Hosts, die mit dem Check_MK-Agenten überwacht werden. Check_MK kann bei diesen einfach in die Ausgabe des Agenten schauen und darin – mithilfe der einzelnen Checkplugins – die interessanten Items finden. Bei SNMP ist etwas mehr Arbeit notwendig. Zwar könnte Check_MK bei der Erkennung einen SNMP-Walk über das komplette Gerät machen und darin nach interessanten OIDs Ausschau halten. Aber es gibt Geräte, wo dann eine einzige Erkennung mehrere Stunden dauern würde!

Daher geht Check_MK intelligenter vor. Es ruft zunächst vom Gerät nur die allerersten beiden OIDs (sysDescr und sysObjectID) und je nach deren Wert etwa zehn weitere OIDs ab. Anhand der Ergebnisse entscheidet dann jedes der über 600 mitgelieferten SNMP-Checkplugins, ob das Gerät dieses Plugin überhaupt unterstützt. Diese Phase nennt Check_MK den SNMP-Scan und hat als Ergebnis eine Liste von Checkplugins.

In einem zweiten Schritt läuft dann die eigentliche Erkennung. Die gefundenen Plugins rufen per örtlich begrenzten SNMP-Walks gezielt genau die Daten ab, die sie benötigen und ermitteln daraus die zu überwachenden Services. Die abgerufenen Daten sind genau die Gleichen, die später auch regelmäßig für die Über­wachung geholt werden.

Bei Geräten im LAN dauert der ganze Vorgang in der Regel nicht sehr lange – mehrere Sekunden sind schon eher die Ausnahme. Wenn Sie aber Geräte über WAN-Strecken mit einer hohen Latenz überwachen, kann der komplette Scan einige Minuten dauern. Nun wäre es sehr unpraktisch, wenn Sie jedes Mal, wenn Sie die Seite der Services öffnen, so lange warten müssten.

Daher überspringt WATO den Scan im Normalfall und macht die Erkennung nur mit den Checkplugins, die bei dem Host aktuell schon zum Einsatz kommen. Die SNMP-Walks liegen dann bereits durch das normale Monitoring als Cachedateien vor und die Erkennung geht in Sekundenbruchteilen. Nur können Sie so zwar neue Items von bestehenden Plugins finden (z. B. neue Switchports, Festplatten, Sensoren, VPNs, usw.), aber keine ganz neuen Plugins.

Der Knopf erzwingt einen SNMP-Scan und anschließendes Holen von frischen Daten via SNMP. Dadurch werden dann auch Services von ganz neuen Plugins gefunden. Bei langsam antwortenden Geräten kann eine Wartezeit entstehen.

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 durch­geführt werden soll. Dazu haben Sie mehrere Möglichkeiten:

  1. In einem Ordner die Checkboxen bei einzelnen Hosts ankreuzen und drücken
  2. Mit der Hostsuche Hosts suchen und beim Suchergebnis drücken
  3. In 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 markiert. Diese Option erlaubt, die Erkennung nur genau für diese Hosts zu wiederholen.
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 Check_MK-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 – und den Vorgang gegebenenfalls auch abbrechen:

4. Checkparameter von Services

Viele der Checkplugins 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 aufge­baut sein, wie das Beispiel der Temperaturüberwachung mit Check_MK zeigt:

Die Checkparameter für einen Service werden in drei Schritten gebildet:

  1. Jedes Plugin hat Defaultwerte für die Parameter.
  2. Manche Plugins setzen Werte während der Erkennung (siehe oben).
  3. Parameter können über Regeln gesetzt werden.

Dabei haben Parameter aus Regeln Vorrang vor den bei der Erkennung gesetzten und diese wiederum Vor­rang 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 Tem­peratur 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 Checkplugins 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 Check_MK 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 Betriebs­systembenutzer, 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.

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äsize 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 tat­sächlich vorgefundenen Situation – allerdings kann das deutlich mehr Aufwand sein, da Sie unter Umstän­den viele Regeln brauchen, um genau abzubilden, auf welchem Host welche Dienste erwartet werden.

5.3. Überwachung von Switchports

Check_MK 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 Windows­diensten) die Erkennung auch erst mal ohne Regel funktioniert. Per Default überwacht Check_MK 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 Checkplugin 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 Checkplugin fest (z. B. chrony oder ntp.time). Bei Checkplugins, 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:

  1. Der Host ist korrekt aufgesetzt und der Service geht auf OK.
  2. 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.
  3. Der Agent stellt überhaupt keine Informationen bereit, z. B. weil NTP überhaupt nicht installiert ist. Dann bleibt der Service auf PEND und der Check_MK-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 Voll­stä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 Check_MK 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 ab Version 1.2.8 von Check_MK bei neuen Instanzen automatisch eingerichtet wird. Dieser Service existiert für jeden Host und meldet mit 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 Serveliste 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 Einstell­möglich­keiten:

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. Netzwerkchecks und andere aktive Checks

8.1. Netzwerkchecks

Wie im Artikel über die Monitoringagenten gezeigt, gibt es neben Abfragen über SNMP und über den Check_MK-Agenten noch den Fall, dass Sie Netzwerkdienste direkt überwachen möchten. Neben dem normalen PING, den Check_MK sowieso für die Überwachung der Hosts einrichtet, ist der häufigste Fall ein Check, der via HTTP eine Webseite abruft und so eine Anwendung überwacht.

Solche Services kann Check_MK nicht automatisch einrichten. Sie können sie aber recht komfortabel über Regeln anlegen, welche Sie unter Host & Service parameters ➳ Active checks finden.

Ähnlich wie bei den manuellen Checks sind dies Hostregeln, welche Services erzeugen. Und ebenso gilt hier das Prinzip, dass nicht nur die erste zutreffende Regel ausgewertet wird, sondern jede, die für den Host matcht. Denn nur so können Sie ja z. B. auf einem Host mehrere HTTP-Checks einrichten.

Während des Monitorings werden diese Checks durch den Aufruf von Nagios-kompatiblen Plugins verarbeitet. Check_MK liefert dazu alle Plugins aus dem Projekt Monitoring Plugins mit aus, zu denen auch das Plugin check_http gehört. Dazu kommen noch eine Anzahl an Plugins, die im Check_MK-Projekt entwickelt werden.

Check_MK unterstützt Sie beim Aufruf der Plugins mit einer komfortablen Eingabemaske, so dass Sie die zahlreichen Kommandozeilenoptionen der einzelnen Plugins nicht studieren müssen. Hier ist als Beispiel die Eingabemaske für die Überprüfung von DNS durch check_dns:

Aus den gewählten Optionen wird beim Activate Changes dann die passende Kommandozeile für das Plugin aufgebaut und ein passender Service angelegt.

8.2. Eigene Plugins verwenden

Sie können auch eigenen eigene Nagios-kompatible Plugins mit Check_MK verwenden, die Sie entweder selbst geschrieben oder irgendwo im Internet gefunden haben. Das Vorgehen ist wie folgt:

Schreiben Sie ein Skript, welches eine Zeile Text ausgibt und sich mit einem der vier Exitcodes 0 = OK, 1 = WARN, 2 = CRIT oder 3 = UNKNOWN beendet:

#!/bin/bash
echo "I am a self written check and I feel well."
exit 0

Kopieren Sie das Plugin in Ihre Intanz in das Verzeichnis ~/local/lib/nagios/plugins.

OMD[mysite]:~$ cp check_foo ~/local/lib/nagios/plugins

Machen Sie es ausführbar:

OMD[mysite]:~$ chmod 755 ~/local/lib/nagios/plugins/check_foo

Legen Sie nun im Regelsatz Active Checks ➳ Classical active and passive monitoring checks eine Regel an. Wählen Sie einen passenden Servicenamen. Bei der Kommandozeile müssen Sie keinen absoluten Pfad angeben, sondern nur die eigentliche Befehlszeile für Ihr Plugin. Dabei stehen ihnen die Makros $HOSTNAME$ und $HOSTADDRESS$ zur Verfügung. Eine komplette Übersicht über alle verfügbaren Makros finden Sie hier. Das check_foo von oben bräuchte natürlich keine Aufrufargumente …

Wenn Ihr Plugin Metriken ausgibt, die Sie verarbeiten möchten, aktivieren Sie noch die Checkbox Performance data. Mit dem Feld Internal command name können Sie optional bestimmen, wie die Kommandodefinition für den Core benannt werden soll. In der  Check_MK Raw Edition leitet das Graphingtool PNP4Nagios daraus ab, welche Schablone für den Graphen verwendet werden soll. Die Freshness gibt es nur für passive Services und macht hier keinen Sinn.

Nach einem Activate Changes taucht bei jedem Host, auf den die Regel greift, nur ein neuer Service auf. Dass dieser ein aktiver Service ist, erkennen Sie an dem grünen Pfeilsymbol im Kontextmenü, über welchen Sie eine sofortige Ausführung des Checks antriggern können. Das Erebnis:

9. Passive Services

Passive Services sind solche, die nicht von Check_MK aktiv angestoßen werden, sondern bei denen regel­mäß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. myhost123) 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;myhost123;BAR;2;Something bad happened" > ~/tmp/run/nagios.cmd

Nun zeigt der Service ohne Verzögerung den neuen Status:

Wenn Sie von Nagios noch das Werkzeug NSCA kennen, können Sie das auch mit Check_MK weiter­verwenden. Schalten Sie dazu 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 start

Das System ist dann zum Emfpang von passiven Checkergebnissen via NSCA bereit.

10. 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 Check_MK 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 new

Sie können nach dem -I auch einen oder mehrere Hostnames 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 Check_MK bei der expliziten Angabe von einem Host immer frische Daten!

OMD[mysite]:~$ cmk -vI myhost123

Mit den Optionen --cache bzw. --no-cache können Sie die Verwendung von Cache auch explizit be­stimmen.

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_thermal

Sie können das Ganze auch auf ein einzelnes Checkplugin 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 df

Wenn 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...OK

Und 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 defined

10.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 Checkplugin 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 ( Check_MK Enterprise Edition mit CMC als Kern.)
cmk -R Änderungen aktivieren ( Check_MK Raw Edition bzw. Nagios als Kern).

10.2. Speicherung in Dateien

Das Ergebnis der Serviceerkennung – also die eingangs genannte Tabelle von Hostname, Checkplugin, 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 Pythonsyntax 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“.

var/check_mk/autochecks/myhost123.mk
[
  ('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, {}),
]

11. Servicegruppen in wato _services

11.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 und 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 Alerthandler 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.

11.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:

11.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 Filesystems und CIFS mount, 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.

11.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.

11.5. Servicegruppen einsetzen

Zum Einsatz kommen die Servicegruppen wie bereits erwähnt an mehreren Stellen: Ansichten, NagVis-Karten, Alarmierungen und Alerthandler. 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 Alerthandlern nutzen, stehen sie als Bedingungen/Filter zur Verfügung, von denen Sie einen oderer mehrere nutzen können:

12. Mehr über Checkplugins

12.1. Kurze Beschreibung der Funktionsweise

Checkplugins werden benötigt, um die Services in Check_MK zu erstellen. Jeder Service greift auf ein Checkplugin 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.

12.2. Verfügbare Checkplugins

Eine Liste aller verfügbaren Checkplugins 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 Informationen über den Namen des Checkplugins, die kompatiblen Datenquellen und die Servicebeschreibung enthalten: