Checkmk
to checkmk.com

1. Einleitung

Die Services sind das eigentliche Fleisch im Monitoringsystem. Jeder Einzelne von ihnen repräsentiert ein wichtiges Rädchen in Ihrer komplexen IT-Landschaft. Der 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 Benachrichtigungen unbedingt vermeiden.

wato services services illu

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 /var auf dem Host `myserver01`

  • 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 (myserver01), 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:

HostCheck-PluginItem

myserver01

df

/

myserver01

df

/var

myserver01

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 im Setup

2.1. Host neu aufnehmen

Nachdem Sie einen neuen Host im Setup 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 den Knopf icon save to services Save & go to service configuration in den Properties of host im Setup

  • in der der Menüleiste der Properties of host über Hosts > Service configuration

  • über das Symbol icon services in der Liste der Hosts in einem Ordner im Setup

  • über den Eintrag icon services 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):

Ansicht der Services of host nach der ersten Serviceerkennung

Der übliche Weg ist nun einfach das Hinzufügen der Services über den Knopf Fix all. Auf diese Weise werden zeitgleich auch alle neuen Host-Labels mit aufgenommen. 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:

Liste von erkannten, nicht aufgenommen Services.

Ein Klick auf icon service to old Monitor undecided services oder auf Fix all 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 in den jeweiligen Zeilen auf den Knopf icon service to old für Move to monitored services klicken.

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:

Listeneintrag eines verschwundenen Services.

Der einfachste Weg um diese Services loszuwerden ist erneut ein Klick auf Fix all. Alternativ können Sie die verschwundenen Services auch über den Knopf icon service to removed Remove vanished services entfernen. 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

Um bestimmte Services vorübergehendes aus der Überwachung zu entfernen, klicken Sie entweder auf das Symbol icon service to undecided. Hiermit wird der Service wieder in die Liste der Undecided services verschoben. Oder Sie deaktivieren den Service gänzlich, indem Sie am Anfang der Zeile auf icon move to disabled klicken. 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 myserver01 sollen keine Services überwacht werden, die mit myservice beginnen.“ formulieren.

Sie erreichen die Regel über Setup > Services > Discovery rules > Discovery and Checkmk settings > Disabled Services.

Eingabemaske für Discovery-Bedinungen.

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.

Liste mit Services mit unterschiedlichen Status.

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 über das Symbol icon service to undecided für Move to undecided services und fügen Sie Ihn anschließend wieder hinzu. Dazu müssen Sie nach dem Entfernen einmal speichern. Oder Sie frischen alle Services des Host auf, indem Sie in der Menüleiste auf Actions > Remove all and find new klicken. Das ist natürlich viel bequemer — geht aber nur, wenn Sie nicht einzelne Services im Fehlerzustand behalten wollen.

2.6. Host-Labels aktualisieren

Über die Menüleiste haben Sie über Actions > Host labels > Update host labels auch die Möglichkeit nur die Liste der zugehörigen Host-Labels zu aktualisieren.

2.7. 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 Bulkoperationen von Checkmk erleichtern. Wählen Sie zunächst aus, auf welchen Hosts die Erkennung durchgeführt werden soll. Dazu haben Sie mehrere Möglichkeiten:

  1. In einem Ordner die Checkboxen bei einzelnen Hosts ankreuzen und dann in der Menüleiste auf Hosts > On selected hosts > Discover services drücken.

  2. Mit der Hostsuche Hosts suchen, alle gefunden mit einem Klick auf das Kreuz button select all auswählen und wieder in der Menüleiste über Hosts > On selected hosts > Discover services gehen.

  3. In einem Ordner in der Menüleiste auf Hosts > In this folder > Discover services 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:

Eingabemaske für Optionen der Serviceerkennung.

Im Mode finden Sie genau die verschiedenen Möglichkeiten, die Sie auch in der Serviceliste im Setup haben und die wir schon weiter oben erläutert haben.

Liste mit Optionen für die Servicerkennung.

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:

Include all subfolders

Wenn Sie die Serviceerkennung für einen Order gestartet haben, dann ist diese Option überhaupt nur verfügbar und standardmäßig aktiv. Die Serviceerkennung wird dann auch bei allen Hosts in den Unterordnern des aktuell geöffneten Ordners durchgeführt.

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 Checkmk mit dem Symbol icon inventory failed 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 immer ein vollständiger Service-Scan durchgeführt wird. Wenn Sie nicht auf neue Plugins aus sind, können Sie die Erkennung durch Wegnahme der Option beschleunigen.

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:

Status der laufenden Serviceerkennung.

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:

wato services example check parameters temperature levels

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

  1. Jedes Plugin hat Standardwerte 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 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 für die Check-Parameter icon check parameters. Wenn Sie die Parameter von allen Services direkt in der Servicetabelle sehen möchten, können Sie diese mit über die Menüleiste Display > Details > Show check parameters einblenden. Das sieht dann etwa so aus:

wato services check parameters

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 icon main setup dark Setup > Services > Discovery rules. 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 erzwungenen Services 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:

wato services process discovery

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:

wato services process discovery windows

Weitere Details zur Prozesserkennung finden Sie über in der Inline-Hilfe dieses Regelsatzes. Diese aktivieren Sie wie immer über Help > Show inline help in der Menüleiste.

5.2. Überwachung von Windows-Diensten

Das Erkennen 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:

wato services windows service discovery

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 erzwungenen 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 Windows-Diensten) 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:

wato services network interface switch port discovery

Am wichtigsten sind folgende Möglichkeiten:

  • Im Abschnitt Appearance of network interface können Sie bestimmen, wie das Interface im Servicenamen erscheinen soll. Sie haben hier die Wahl zwischen Use description, Use alias und Use index.

  • Match port types ermöglicht das Einschränken oder Ausweiten der überwachten Interfacetypen oder -namen.

6. Einrichtung von Services erzwingen

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 das Anlegen von Services erzwingen. Den Einstiegspunkt dafür finden Sie unter sind die Setup > Services > Enforced services. 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 Enforced services:

wato services example enforced services ntp

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:

wato services example enforced services oracle processes

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 Checkmk-Service geht auf WARN, mit dem Hinweis, dass die entsprechende Sektion in den Agentendaten fehlt.

Die meisten Regelsätze im Modul Enforced services werden Sie nie benötigen und sind nur der Vollständigkeit halber vorhanden. Die häufigsten Fälle für erzwungene Services 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 Bulk-Erkennung ü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:

wato services discovery check warn

Die Einzelheiten zu den nicht überwachten oder verschwundenen Services finden Sie im Long output of check plugin in den Details des Services:

wato services discovery check details

Zu der Serviceliste der Hosts im Setup gelangen Sie bequem über das icon menu Kontextmenü des Discovery Checks über den Eintrag icon services Edit services.

Das Parametrieren des Discovery Checks geht sehr einfach über den Regelsatz Periodic service discovery. In einer frischen Site werden Sie hier bereits eine global wirksame Regel mit den folgenden Einstellungen vorfinden:

wato services periodic service discovery

Neben dem Intervall, in dem der Check laufen soll, können Sie auch noch den Monitoringstatus, für die Fälle von nicht überwachten bzw. verschwundenen Services und Host-Labels, auswählen.

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.

wato services periodic service discovery update configuration

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 in Checkmk können immer nur alle Änderungen auf einmal aktiviert werden! 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:

wato services passive checks integrate nagios plugins

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:

wato services passive checks pending

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

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

wato services passive checks crit

Wenn Sie von Nagios noch das Werkzeug NSCA kennen, können Sie das auch mit Checkmk weiterverwenden. Dazu müssen Sie zuerst eine Abhängigkeit auflösen und das Paket libmcrypt installieren:

Debian/Ubuntu

root@linux# apt-get install libmcrypt4

Red Hat/CentOS

root@linux# yum install libmcrypt

SLES

root@linux# zypper install libmcrypt

Schalten 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 start

Das 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
Discovering services and host labels on all hosts
myserver01:
+ FETCHING DATA
Using data from cache file /omd/sites/mysite/tmp/check_mk/cache/myserver01
[TCPFetcher] Use cached data
No piggyback files for 'myserver01'. Skip processing.
[PiggybackFetcher] Execute data source
+ PARSE FETCHER RESULTS
Received no piggyback data
+ EXECUTING HOST LABEL DISCOVERY
+ PERFORM HOST LABEL DISCOVERY
+ EXECUTING DISCOVERY PLUGINS (42)
SUCCESS - Found no new services, 2 host labels
myserver02:
+ FETCHING DATA
Using data from cache file /omd/sites/mysite/tmp/check_mk/cache/myserver02
[TCPFetcher] Use cached data
No piggyback files for 'myserver02'. Skip processing.
[PiggybackFetcher] Execute data source
+ PARSE FETCHER RESULTS
Received no piggyback data
+ EXECUTING HOST LABEL DISCOVERY
+ PERFORM HOST LABEL DISCOVERY
+ EXECUTING DISCOVERY PLUGINS (1900)
SUCCESS - Found no new services, 2 host labels

Sie können nach dem -I auch einen oder mehrere Hostnamen angeben, um nur diese zu untersuchen. 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 myserver01

Alternativ können Sie über Tags filtern:

OMD[mysite]:~$ cmk -vI @mytag

Damit 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 myswitch01
Discovering services on myswitch01:
myswitch01:
  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 myserver01
Discovering services and host labels on: myserver01
myserver01:
+ FETCHING DATA
Using data from cache file /omd/sites/mysite/tmp/check_mk/cache/myserver01
[TCPFetcher] Use cached data
No piggyback files for 'myserver01'. Skip processing.
No piggyback files for '127.0.0.1'. Skip processing.
[PiggybackFetcher] Execute data source
+ PARSE FETCHER RESULTS
Received no piggyback data
+ EXECUTING HOST LABEL DISCOVERY
+ PERFORM HOST LABEL DISCOVERY
+ EXECUTING DISCOVERY PLUGINS (10)
    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
SUCCESS - Found 21 services, 2 host labels

Sie können das Ganze auch auf ein einzelnes Check-Plugin einschränken. Die Option dazu lautet --detect-plugins= und muss vor dem Hostnamen stehen:

cmk -vII --detect-plugins=df myserver01
Discovering services and host labels on: myserver01
myserver01:
+ FETCHING DATA
[TCPFetcher] Execute data source
No piggyback files for 'myserver01'. Skip processing.
No piggyback files for '127.0.0.1'. Skip processing.
[PiggybackFetcher] Execute data source
+ PARSE FETCHER RESULTS
Received no piggyback data
+ EXECUTING HOST LABEL DISCOVERY
+ PERFORM HOST LABEL DISCOVERY
+ EXECUTING DISCOVERY PLUGINS (1)
  3 df
SUCCESS - Found 3 services, no host labels

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
Creating helper config...OK
Reloading monitoring core...OK

Und wenn Sie mal bei einer Discovery auf einen Fehler stoßen …​

OMD[mysite]:~$ cmk -vII --detect-plugins=df myserver01
  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 --detect-plugins=df myserver01
Discovering services and host labels on myserver01:
myserver01:
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

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

--detect-plugins=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“.

var/check_mk/autochecks/myserver01.mk
[
  {'check_plugin_name': 'cpu_loads', 'item': None, 'parameters': (5.0, 10.0), 'service_labels': {}},
  {'check_plugin_name': 'cpu_threads', 'item': None, 'parameters': {}, 'service_labels': {}},
  {'check_plugin_name': 'diskstat', 'item': 'SUMMARY', 'parameters': {}, 'service_labels': {}},
  {'check_plugin_name': 'kernel_performance', 'item': None, 'parameters': {}, 'service_labels': {}},
  {'check_plugin_name': 'kernel_util', 'item': None, 'parameters': {}, 'service_labels': {}},
  {'check_plugin_name': 'livestatus_status', 'item': 'myremotesite', 'parameters': {}, 'service_labels': {}},
  {'check_plugin_name': 'lnx_thermal', 'item': 'Zone 0', 'parameters': {}, 'service_labels': {}},
  {'check_plugin_name': 'mem_linux', 'item': None, 'parameters': {}, 'service_labels': {}},
  {'check_plugin_name': 'mknotifyd', 'item': 'mysite', 'parameters': {}, 'service_labels': {}},
  {'check_plugin_name': 'mknotifyd', 'item': 'myremotesite', 'parameters': {}, 'service_labels': {}},
  {'check_plugin_name': 'mounts', 'item': '/', 'parameters': ['errors=remount-ro', 'relatime', 'rw'], 'service_labels': {}},
  {'check_plugin_name': 'omd_apache', 'item': 'mysite', 'parameters': {}, 'service_labels': {}},
  {'check_plugin_name': 'omd_apache', 'item': 'myremotesite', 'parameters': {}, 'service_labels': {}},
  {'check_plugin_name': 'tcp_conn_stats', 'item': None, 'parameters': {}, 'service_labels': {}},
  {'check_plugin_name': 'timesyncd', 'item': None, 'parameters': {}, 'service_labels': {}},
  {'check_plugin_name': 'uptime', 'item': None, 'parameters': {}, 'service_labels': {}},
]

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 Benachrichtigungen 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 Setup > Services > Service groups.

wato services service groups add group

Das Anlegen einer Servicegruppe ist simpel: Legen Sie über icon new Add group eine neue Gruppe an und vergeben Sie einen später nicht mehr veränderbaren Namen sowie einen aussagekräftigen Alias.

wato services add service group

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. In der Übersicht Ihrer Servicegruppen (Setup > Services > Service Groups), finden Sie diese Regel am schnellsten und zwar über die Menüleiste und dort die Punkte Service Groups > Assign to group > Rules. Alternativ können Sie die Regel natürlich auch über die Regelsuche im Setup-Menü finden, oder sich über Setup > Services > Service monitoring rules > Various > Assignment of services to service groups durchklicken. Erstellen Sie nun über Create rule in folder 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.

wato services servicegroups rule assignment

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.

wato services servicegroups rule conditions

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.

wato services servicegroups service detail

10.5. Servicegruppen einsetzen

Zum Einsatz kommen die Servicegruppen wie bereits erwähnt an mehreren Stellen: Ansichten, NagVis-Karten, Benachrichtigungen 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:

wato services servicegroups view summary

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:

wato services servicegroups nagvis example

Wenn Sie Servicegruppen in Benachrichtigungen und Alert Handlern nutzen, stehen sie als Bedingungen/Filter zur Verfügung, von denen Sie einen oder mehrere nutzen können:

wato services servicegroups notification rule

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 Setup > Services > Catalog of check plugins. Hier können Sie nach verschiedenen Kategorien gefiltert die einzelnen Plugins durchsuchen:

wato services catalog of check plugins

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:

wato services catalog of check plugins telephony
Auf dieser Seite