Linux überwachen

Checkmk bietet Ihnen für die Installation des Linux-Agenten verschiedene Wege — von der manuellen Installation der Einzelteile bis hin zum vollautomatischen Deployment. Manche davon stehen nur in den Enterprise Editions zur Verfügung:

Sie finden die Agentendateien im WATO-Modul Monitoring agents. Bei den Enterprise Editions landen Sie zunächst in der Agentenbäckerei. Von dort aus kommen Sie mit dem Knopf Agent files zur Liste der Agentendateien:

Alles was Sie brauchen, ist gleich im ersten Kasten mit dem Namen Packaged Agents. Dort finden Sie fertige RPM- und DEB-Pakete für die Installation eines Linux-Agenten mit Standardeinstellungen (auch das Paket für Windows mit der Endung .msi ist hier):

Ob Sie RPM oder DEB benötigen, hängt von der Linux-Distribution ab, auf der Sie das Paket installieren möchten:

Achtung: Im Kasten Linux/Unix-Agents finden Sie die reinen Agentenskripten für die manuelle Installation nach /usr/bin/. Verwenden Sie diese nur, wenn die paketierten Agenten bei Ihnen nicht funktionieren oder falls Sie andere Unix-Derivate als Linux überwachen möchten.

Die Checkmk Enterprise Editions verfügen mit der Agent-Bakery über ein WATO-Modul zum automatischen Paketieren von individuell angepassten Agenten. Diese wird im allgemeinen Kapitel über die Agenten beschrieben. Die Installation der gebackenen Pakete geschieht genau wie oben beschrieben.

Wenn Sie die Agentenbäckerei verwenden, können Sie automatische Updates des Agenten einrichten. Diese werden in einem eigenen Artikel beschrieben.

Die Manuelle Installation des Agenten ist zwar selten nötig, aber auch nicht sehr schwierig. Sie benötigen aus der Seite der Agentendateien dazu den Kasten Linux/Unix agents. Dort finden Sie die Datei {CMK} Agent for Linux:

Laden Sie diese Datei auf das Zielsystem und kopieren Sie sie in ein Verzeichnis, dass für root ausführbar ist. Sehr gut eignet sich /usr/local/bin/, da es sich im Suchpfad befindet und für eigene Erweiterungen gedacht ist. Auch hier können Sie wieder direkt mit wget arbeiten:

Vergessen Sie bitte nicht die letzten beiden Befehle: Damit entfernen Sie die Endung .linux und machen die Datei ausführbar. Wenn Sie alles richtig gemacht haben, muss der Agent jetzt einfach als Befehl ausführbar sein und seine typische Ausgabe erzeugen. Das geht auch, wenn Sie nicht in /usr/local/bin stehen. Das | head schneidet hier alles ab der 11. Zeile weg:

Falls Sie eine sehr alte Distribution haben, welche den Befehl timeout nicht kennt, dann laden Sie noch das kleine Programm waitmax von der Agentenseite und installieren Sie es ebenfalls nach /usr/local/bin. timeout und waitmax machen das gleiche: Sie erzwingen einen Timeout bei der Ausführung eines Programms:

Waitmax wurde als Teil von Checkmk zu einer Zeit entwickelt, als timeout noch nicht verbreitet war. Es hat fast die gleiche Aufrufsyntax:

Falls Sie den Agenten konfigurieren oder erweitern möchten, müssen Sie die dafür notwendigen Verzeichnisse selbst anlegen. Der Ort für die drei notwendigen Verzeichnisse ist im Agenten hart kodiert in Variablen, die mit MK_ beginnen und über das Environment auch den Plugins bereitgestellt werden:

Diese drei Verzeichnisse sollten Sie anlegen (mit den Standardrechten 755):

Falls Sie die Pfade ändern möchten, so editieren Sie einfach /usr/local/bin/check_mk_agent.

Falls Sie den Agenten grundsätzlich über SSH abrufen möchten, brauchen Sie keine Konfiguration für den xinetd und benötigen nur noch die SSH-Konfiguration. Wie das geht, beschreiben wir weiter unten.

Die Konfiguration per xinetd ermöglicht einen Zugriff auf die Agentendaten via TCP Port 6556 und ist der Standardweg im lokalen Netzwerk. Installieren Sie dazu das Paket xinetd und legen Sie folgende Datei an:

Tragen Sie hier unter only_from die IP-Adressen Ihrer Checkmk-Server ein, die auf den Agenten zugreifen dürfen. Danach braucht es nur noch ein Aktivieren und der Agent ist bereit:

Wenn Sie systemd verwenden, führen Sie stattdessen dieses Kommando aus:

Sobald Sie den Agent installiert haben, stellen Sie sich sicher die Frage, wie Sie ausprobieren können, ob Sie alles richtig gemacht haben. Alle Möglichkeiten, die es vom Checkmk-Server aus gibt, sind im allgemeinen Kapitel über die Agenten beschrieben. Aber natürlich gibt es noch weitere Diagnosemöglichkeiten, wenn man direkt auf dem Zielsystem selbst eingeloggt ist.

Da der „Agent“ im Grunde nichts als ein einfaches Programm ist, das Daten über Ihr System beschafft und diese als lose formatierten Text ausgibt, können Sie ihn auch als Programm aufrufen, und zwar ganz einfach so:

Da die Ausgabe etwas länger sein kann, ist less auch hier sehr praktisch (Sie können es mit der Taste Q verlassen):

Diese Ausgabe beweist natürlich nicht, dass der Agent auch über das Netzwerk erreichbar ist. Aber Sie können so testen, ob in der Ausgabe alle gewünschten Daten enthalten sind.

Sie müssen übrigens nicht unbedingt root sein, um den Agenten aufzurufen. Allerdings werden dann in der Ausgabe eventuell einige Informationen fehlen, zu deren Beschaffung root-Rechte erforderlich sind (z.B. Multipath-Informationen und die Ausgaben von ethtool).

Damit eventuelle Fehlerausgaben von nicht funktionierenden Plugins oder Befehlen nicht die eigentlichen Daten „verunreinigen“, unterdrückt der Agent generell den Standardfehlerkanal. Sind Sie auf der Suche nach einem bestimmten Problem, können Sie diesen wieder aktivieren, indem Sie den Agenten in einem speziellen Debugmodus aufrufen. Das machen Sie mit der Option -d. Dabei werden auch sämtliche Shellbefehle ausgegeben, die der Agent ausführt.

Damit Sie hier mit less arbeiten können, müssen Sie Standardausgabe und Fehlerkanal mit 2>&1 zusammenfassen:

Wenn Sie Ihr Monitoring von einer Nagios-basierten Lösung auf Checkmk migriert haben, ist es nicht ganz ausgeschlossen, dass Sie Check-Plugins klassischer Machart haben, zu denen es (noch) kein Pendant in Checkmk gibt. In den meisten Fällen sind das selbstgeschriebene Plugins in Perl oder Shell.

Der Checkmk-Agent bietet einen einfachen Mechanismus, solche Plugins weiter zu verwenden: MK’s Remote Plugin Executor oder kurz MRPE. Der Name ist bewusst eine Analogie zum NRPE von Nagios, der dort die gleiche Aufgabe übernimmt.

Der MRPE ist im Agenten fest eingebaut und wird mit einer einfachen Textdatei konfiguriert, welche Sie unter /etc/check_mk/mrpe.cfg selbst anlegen. Dort geben Sie pro Zeile einen Pluginaufruf an — zusammen mit dem Namen, den Checkmk für den Service verwenden soll, den es dafür automatisch erzeugt. Hier ist ein Beispiel:

Wenn Sie jetzt den Agenten lokal laufen lassen, finden Sie pro Plugin eine neue Sektion mit dem Titel <[mrpe]>, welche Name, Exitcode und Ausgabe des Plugins enthält. Das können Sie mit folgendem praktischen grep-Befehl überprüfen:

Die 0 bzw. 2 in der Ausgabe stehen für die Exitcodes der Plugins und folgen nach dem klassischen Schema: 0 = OK, 1 = WARN, 2 = CRIT und 3 = UNKNOWN.

Den Rest macht jetzt Checkmk automatisch. Sobald Sie die Serviceerkennung für den Host aufrufen, werden die beiden neuen Services als verfügbar angezeigt. Das sieht dann so aus:

Übrigens: Aufgrund der Syntax der Datei darf der Name keine Leerzeichen enthalten. Sie können aber mithilfe der gleichen Syntax wie in URLs ein Space durch %20 ersetzen (ASCII-Code 32 für Space ist Hexadezimal 20):

Bitte beachten Sie, dass alle Plugins, die Sie in mrpe.cfg aufführen, der Reihe nach synchron ausgeführt werden. Die Plugins sollten daher keine allzu große Ausführungszeit haben. Wenn ein Plugin hängt, verzögert sich die Ausführung aller weiteren. Das kann dazu führen, dass das komplette Abfragen des Agenten durch Checkmk in einen Timeout laufen und der Host nicht mehr zuverlässig überwacht werden kann.

Wenn Sie wirklich länger laufende Plugins benötigen, sollten Sie diese auf asynchrone Ausführung umstellen und das Problem damit vermeiden. Dabei legen Sie eine Zeit in Sekunden fest, die ein berechnetes Ergebnis Gültigkeit haben soll, z.B. 300 für fünf Minuten. Setzen Sie dazu in mrpe.cfg nach dem Servicenamen den Ausdruck (interval=300):

Das hat mehrere Auswirkungen:

Damit können Sie also Tests, die sehr viel Rechenzeit brauchen, auch in größeren Intervallen ausführen, ohne dass Sie dazu am Checkmk-Server etwas konfigurieren müssen.

Stolze Besitzer der Enterprise Editions können MRPE auch mit der Agentenbäckerei konfigurieren. Zuständig dafür ist der Regelsatz Monitoring Agents ⇒ Rules ⇒ Generic Options ⇒ Execute MRPE Checks. Dort können Sie die gleichen Dinge wie oben beschrieben konfigurieren. Die Datei mrpe.cfg wird dann von der Bäckerei automatisch generiert.

Der Standardagent /usr/bin/check_mk_agent enthält eine ganze Reihe von Sektionen, welche Überwachungsdaten für diverse Checks liefern und dann von der Serviceerkennung automatisch gefunden werden. Dazu gehören alle wichtigen Überwachungen des Betriebssystems.

Darüber hinaus gibt es die Möglichkeit, den Agenten um Agentenplugins zu erweitern. Das sind kleine Skripten oder Programme, die vom Agenten aufgerufen werden und diesen um weitere Sektionen mit zusätzlichen Monitoring-Daten erweitern. Das Checkmk-Projekt liefert eine ganze Reihe solcher Plugins mit aus, welche — wenn sie korrekt installiert und konfiguriert sind — in der Serviceerkennung automatisch neue Checks liefern.

Warum sind diese Plugins nicht einfach in den Standardagenten fest integriert? Für jedes der Plugins gibt es einen der folgenden Gründe:

Die vom Projekt mitgelieferten Plugins für Linux und UNIX finden Sie alle auf dem Checkmk-Server unter share/check_mk/agents/plugins. Auch über die Downloadseite der Agenten im WATO (wie am Anfang des Artikels beschrieben) sind diese im Kasten Linux/Unix Agents - Plugins verfügbar:

Zu allen von uns mitgelieferten Agentenplugins gibt es auch die passenden Checksplugins, welche deren Daten auswerten und Services erzeugen können. Diese sind bereits dafür bereit und müssen nicht extra installiert werden.

Bevor Sie ein Plugin im Agenten installieren werfen Sie bitte einen Blick in die entsprechende Datei. Oft finden Sie dort wichtige Hinweise zur korrekten Verwendung des Plugins.

Die eigentliche Installation ist dann einfach: Kopieren Sie die Datei nach /usr/lib/check_mk_agent/plugins. Achten Sie dabei darauf, dass diese ausführbar ist. Falls nicht, verwenden Sie ein chmod 755. Der Agent wird das Plugin sonst nicht ausführen. Insbesondere wenn Sie die Dateien nicht per scp übertragen sondern per HTTP von der Downloadseite holen, geht die Ausführungsberechtigung verloren!

Sobald das Plugin ausführbar und im richtigen Verzeichnis ist, wird es vom Agenten aufgerufen und es entsteht eine neue Sektion in der Agentenausgabe. Diese trägt üblicherweise den gleichen Namen wie das Plugin. Komplexe Plugins (z.B. mk_oracle) erzeugen sogar eine ganze Reihe von Sektionen.

In älteren Versionen des Checkmk-Agenten kann sich das Pluginverzeichnis auch an einem anderen Ort befinden. Falls Sie sich unsicher sind, ob Sie davon betroffen sind, können Sie das Verzeichnis folgendermaßen identifizieren:

Manche Plugins brauchen eine Konfigurationsdatei in /etc/check_mk/, damit sie funktionieren können. Bei anderen ist eine Konfiguration optional und ermöglicht besondere Features oder Anpassungen. Wieder andere funktionieren einfach so. Sie haben verschiedene Quellen, um an Informationen zu kommen:

Ebenso wie bei MRPE können Sie auch Plugins asynchron ausführen lassen. Das ist sehr nützlich, wenn die Plugins eine lange Laufzeit haben und die gewonnenen Statusdaten ohnehin nicht jede Minute neu zu erzeugt werden brauchen.

Die asynchrone Ausführung wird nicht über eine Datei konfiguriert. Stattdessen erzeugen Sie unter plugins ein Unterverzeichnis, dessen Name eine Zahl ist: eine Anzahl von Sekunden. Plugins in diesem Verzeichnis werden nicht nur asynchron ausgeführt, sondern gleichzeitig geben Sie mit der Sekundenzahl eine Mindestwartezeit vor, bevor das Plugin erneut ausgeführt werden soll. Wird der Agent vor Ablauf der Zeit erneut abgefragt, verwendet er gecachte Daten von der letzten Ausführung des Plugins. Damit können Sie quasi ein größeres Intervall für das Plugin konfigurieren, als die typische eine Minute.

Folgendes Beispiel zeigt, wie das Plugin my_foo_plugin von synchroner Ausführung auf eine asynchrone Ausführung mit einem Intervall von 5 Minuten umgestellt wird:

Bitte beachten Sie, dass einige Plugins bereits von sich aus eine asynchrone Ausführung intern umsetzen. Dazu gehört mk_oracle. Installieren Sie solche Plugins direkt nach /usr/lib/check_mk_agent/plugins!

Die von Checkmk mitgelieferten Plugins können über die Agent Bakery konfiguriert werden. Diese sorgt sowohl für die Installation des Plugins selbst als auch für die korrekte Erstellung der Konfigurationsdatei, falls eine notwendig sein sollte.

Jedes Plugin wird über eine Agentenregel konfiguriert. Sie finden die passenden Regelsätze in Monitoring Agents ⇒ Agent plugins:

Da Agentenplugins ausführbare Programme sind, können Sie diese zu Test- und Diagnosezwecken auch von Hand ausführen. Es gibt allerdings Plugins, welche bestimmte vom Agenten gesetzten Umgebungsvariablen brauchen, um z.B. ihre Konfigurationsdatei zu finden. Setzen Sie diese vor der Ausführung von Hand:

Einige Plugins kennen auch spezielle Aufrufoptionen zum Debuggen. Werfen Sie einfach einen Blick ins Plugin!

Heutzutage muss alles sicher sein. Und da darf Monitoring natürlich keine Ausnahme sein. Da der Monitoringagent auf jedem überwachten Server installiert wird, hätte hier ein Sicherheitsproblem besonders gravierende Auswirkungen.

Deswegen wurde schon beim Design von Checkmk auf Sicherheit Wert gelegt und es gilt seit den ersten Tagen von Checkmk ein eherner Grundsatz: Der Agent liest keine Daten vom Netzwerk. Punkt. Somit ist mit Sicherheit ausgeschlossen, dass ein Angreifer über den Überwachungsport 6556 irgendeine Art von Befehlen oder Skriptbestandteilen einschleusen könnte.

Das allein liefert bereits ein so hohes Sicherheitsniveau, dass die meisten Anwender im LAN auf weitere Maßnahmen verzichten. Kann das überwachte System nur über eine unsichere Internetverbindung erreicht werden, gelten natürlich ganz andere Maßstäbe und hier ist sicher eine Verschlüsselung mit SSH die erste Wahl.

Der Checkmk-Agent verfügt ferner über eine eingebaute Verschlüsselung, welche einen guten Kompromiss aus Sicherheit und Aufwand darstellt. Im Folgenden zeigen wir Ihnen alle Möglichkeiten zur Absicherung im Detail.

Auch wenn ein Angreifer keine Befehle ausführen kann: Die Monitoring-Daten des Agenten könnten für ihn auch schon nützlich sein, denn sie enthalten unter anderem eine Liste von allen auf dem System laufenden Prozessen. Am besten ist es daher, wenn die Daten nicht jeder einfach abrufen kann.

Die ultimative Sicherheit beim Aufruf des Checkmk-Agenten bietet der Aufruf desselben über Secure Shell — bei Linux in Form der Implementierung OpenSSH. Diese Methode ist angebracht bei:

Das Einrichten geschieht in folgenden Schritten:

Und das Ganze jetzt Schritt für Schritt mit allen notwendigen Details:

Der Checkmk-Agent kann seine Daten ohne Zusatzmittel selbst verschlüsseln. Dies ist streng genommen kein Ersatz für eine Zugangskontrolle. Da aber ein Angreifer ja keine Befehle senden und mit verschlüsselten Ausgabedaten nichts anfangen kann, kommt es einer solchen schon sehr nahe.

Der Aufwand für die Verwendung der Verschlüsselung und die nötige zusätzliche CPU-Last sind beide geringer, als bei der oben beschriebenen Methode mit SSH, welche wir aber nach wie vor bei der Übertragung über das Internet empfehlen.

Die Verschlüsselung braucht natürlich sowohl auf dem Agenten als auch auf dem Server eine passende Konfiguration. Diese kann entweder von Hand erstellt werden (Raw Edition) oder mit der Agentenbäckerei (Enterprise Editions).

Zu einer möglichst vollständigen Überwachung eines Linux-Servers gehört natürlich auch die Hardware. Dies geschieht teils direkt mit dem Checkmk-Agenten, teils auch über spezielle Plugins. Außerdem gibt es noch Fälle, in denen man per SNMP oder sogar über ein separates Managementboard eine Überwachung umsetzen kann.

Moderne Festplatten verfügen fast immer über S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology). Dieses System zeichnet kontinuierlich Daten zu dem Zustand der HDD oder SSD auf und Checkmk kann mit dem Plugin smart diese Werte abrufen und die wichtigsten davon auswerten. Damit das Plugin nach der Installation auch funktioniert, müssen folgende Voraussetzungen erfüllt sein:

Sind diese Voraussetzungen erfüllt und ist das Plugin installiert, werden die Daten automatisch ausgelesen und der Ausgabe des Agenten angehängt. In Checkmk können Sie die neuen Services dann auch direkt aktivieren:

IPMI (Intelligent Platform Management Interface) ist eine Schnittstelle zum Hardwaremanagement, welche unter anderem die Überwachung der Hardware ermöglicht. Checkmk nutzt dafür freeipmi, um direkt und ohne Netzwerk auf die Hardware zuzugreifen. Es wird dafür aus den Paketquellen installiert und ist danach sofort einsatzbereit, so dass die Daten schon bei dem nächsten Aufruf von Checkmk übermittelt werden.

Falls freeipmi nicht verfügbar ist, oder andere Gründe gegen eine Installation sprechen, kann auch ipmitool verwendet werden. Dieses ist oft bereits auf dem System vorhanden und muss lediglich mit einem IPMI Gerätetreiber versorgt werden, wie ihn z.B. das Paket openipmi zur Verfügung stellt. Auch hier müssen Sie danach nichts weiter tun. Die Daten werden von Checkmk automatisch erfasst.

Zur Fehlerdiagnose können Sie die Tools auch händisch in einer Shell des Hosts ausführen. Haben Sie das Paket freeipmi installiert, können Sie die Funktion hiermit kontrollieren:

Wenn ipmitool installiert wurde, können Sie die Ausgabe der Daten mit folgendem Befehl prüfen:

Viele große Server-Hersteller bieten auch eigene Tools an, um die Hardwareinformationen auszulesen und über SNMP bereitzustellen. Es gelten dabei die folgenden Voraussetzungen, um diese Daten abrufen und Checkmk bereitstellen zu können:

Die dadurch unterstützten neue Services für die Hardwareüberwachung werden dann automatisch erkannt. Es werden keine weiteren Plugins benötigt.

Man kann zu jedem Host ein Managementboard konfigurieren und zusätzliche Daten per SNMP holen. Die dadurch erkannten Services werden dann ebenfalls dem Host zugeordnet.

Die Einrichtung des Managementboard ist dabei sehr einfach. Geben Sie in den Eigenschaften des Hosts lediglich das Protocol, die IP-Adresse und die Zugangsdaten für SNMP an und speichern Sie die neuen Einstellungen ab:

In der Service Discovery werden die neu erkannten Services dann wie gewohnt aktiviert.