Überwachen von Linux

Letzte Aktualisierung: 06. Juli 2017


1. Einleitung

Linux-Systeme können Sie mit Check_MK besonders gut überwachen. Das liegt weniger daran, dass sich das Check_MK-Entwicklerteam auf Linux „zuhause“ fühlt, sondern vielmehr daran, dass Linux ein sehr offenes System ist und zahlreiche gut dokumentierte und einfach abzufragende Schnittstellen für eine detaillierte Über­wachung bereitstellt.

Natürlich ist die Installation eines Monitoringagenten unumgänglich, denn die meisten der Schnittstellen sind per se nicht über das Netzwerk erreichbar. Deswegen hat Check_MK einen eigenen Agenten für die Überwachung von Linux. Dieser ist einfach zu installieren und sparsam im Verbrauch von Ressourcen.

Der Check_MK-Agent für Linux ist

  • minimalistisch, denn er benötigt nur wenig CPU, RAM und Plattenplatz,
  • transparent, denn er ist ein Shellskript, in dem Sie können sehen können, welche Befehle er aufruft und
  • sicher, denn er erlaubt keinerlei Zugriffe aus dem Netzwerk.

Der Agent besteht aus einem simplen Shellskript, das nach /usr/bin/check_mk_agent installiert wird und der Reihe nach vorhandene Systembefehle aufruft, um Daten für das Monitoring zu ermitteln. Seine Ausgabe stellt er entweder per xinetd oder systemd an TCP-Port 6556 bereit oder er wird alternativ per SSH aufgerufen. Und wenn Ihnen beides nicht gefällt, können Sie auch eigene Methoden implementieren, wie Check_MK die Daten vom Agenten bekommen soll.

Monitoringinformationen, die der Agent nicht von Haus aus liefert, können Sie in Form von Agentenplugins hinzufügen. In der  Check_MK Enterprise Edition können Sie alle Einstellungen und Plugins zusammen mit dem Agenten in der Agentenbäckerei zu einem RPM oder DEB-Paket paketieren, das mit einem einzigen Befehl installiert und oder sogar vollautomatisch aktualisiert werden kann.

2. Installation

2.1. Verschiedene Möglichkeiten

Check_MK 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 der  Check_MK Enterprise Edition zur Vefügung:

Methode Beschreibung CRE CEE
Mitgeliefertes RPM/DEB-Paket Einfache Installation eines Standard-Agenten mit manueller Konfiguration über Konfigurationsdateien. X X
RPM/DEB-Paket aus der Agentenbäckerei Konfiguration über die GUI, individuelle Konfiguration pro Host möglich. X
Automatisches Updaten Das Paket aus der Agentenbäckerei wird erstmalig von Hand oder per Skript installiert und von da an automatisch aktualisiert. X
Manuelle Installation Sie kopieren die Einzeldateien ohne Paket auf das Zielsystem und setzen xinetd, systemd, SSH oder eine eigene Zugrifssmethode von Hand auf. X X

2.2. Installation per RPM/DEB-Paket

Sie finden die Agentendateien im WATO-Modul Monitoring agents. Bei der  Check_MK Enterprise Edition landen Sie zunächst in der Agentenbäckerei. Von dort aus kommen Sie mit dem Knopf Unpackaged agents bzw. Agent files (Version 1.4.0) 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:

Paket Endung Installation auf
RPM .rpm Red Hat Enterprise Linux, Fedora, CentOS, openSUSE, SLES, Derivate davon
DEB .deb Debian, Ubuntu, allere anderen DEB-basierten Distributionen

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.

Exotische Linux-Distributionen

Auch wenn der Check_MK-Server nur Enterprise-Linux-Distributionen unterstützt, die deren Hersteller noch supported, ist der Check_MK-Agent hier viel genügsamer. Er unterstützt jede Linux-Distribution – selbst uralte „Dinosaurier“, auf denen noch ein Kernel der Version 2.4 läuft! Es kann dann zwar sein, dass nicht alle Plugins im Agenten korrekt laufen, aber die grundsätzliche Überwachung wird funktionieren.

Installation mit RPM

Die Installation des Agenten mit dem RPM-Paket ist sehr einfach:

  1. Laden Sie das Agentenpaket mit der Endung *.rpm herunter.
  2. Kopieren Sie es mit scp, WinSCP oder anders auf das zu überwachende Zielsystem.
  3. Installieren Sie es dort als root mit dem Befehl rpm -U.
  4. Installieren Sie noch das Paket xinetd von Ihrer Distribution nach, falls es nicht schon installiert ist.

Hier ein Beispiel für die Installation des Pakets:

root@linux# rpm -U check-mk-agent-1.4.0p4-1.noarch.rpm

Das -U steht übrigens für „Update“, kann aber auch eine Erstinstallation korrekt durchführen. Das bedeutet, dass Sie den gleichen Befehl auch später für ein Update auf eine neue Version verwenden können.

Das Nachinstallieren von xinetd geht auf Red Hat / CentOS mit:

root@linux# yum install xinetd

Bei SUSE Linux verwenden Sie zypper:

root@linux# zypper install xinetd

Nach der Installation ist der Agent sofort aktiv und kann auf TCP Port 6556 abgefragt werden.

Installation mit DEB

Das Verfahren ist das gleiche wie bei RPM, nur die Befehle lauten anders. Installation und ein späteres Update des Agenten gehen gleichermaßen mit:

root@linux# dpkg -i check-mk-agent_1.4.0p4-1_all.deb

Das Nachinstallieren von xinetd:

root@linux# apt-get install xinetd

Paket per HTTP holen

Manchmal ist scp oder WinSCP sehr umständlich. Sie können das Paket vom Check_MK-Server auch direkt per HTTP auf das Zielsystem laden. Für diesen Zweck sind die Downloads der Agentendateien bewusst ohne Anmeldung möglich. Immerhin enthalten die Dateien keine Geheimnisse. Jeder kann sich Check_MK selbst herunterladen und installieren und so auf die Dateien zugreifen.

Am einfachsten geht das mit wget. Die URLs können Sie über den Browser ermitteln. Wenn Sie den Namen des Pakets bereits kennen, können Sie die URL einfach selbst zusammensetzen. Setzen Sie einfach /mysite/check_mk/agents/ vor den Dateinamen:

root@linux# wget http://mycmkserver/mysite/check_mk/agents/check-mk-agent-1.4.0p4-1.noarch.rpm

RPM hat sogar ein eingebautes wget. Hier können Sie Download und Installation in einem Schritt machen:

root@linux# rpm -U http://mycmkserver/mysite/check_mk/agents/check-mk-agent-1.4.0p4-1.noarch.rpm

2.3. Installation mit der Agent-Bakery

Die  Check_MK Enterprise Edition verfügt 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.

2.4. Automatisches Updaten

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

2.5. Manuelle Installation

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 Check_MK 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:

root@linux# cd /usr/local/bin
root@linux# wget http://mycmkserver/mysite/check_mk/agents/check_mk_agent.linux
root@linux# mv check_mk_agent.linux check_mk_agent
root@linux# chmod 755 check_mk_agent

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:

root@linux# check_mk_agent | head
<<<check_mk>>>
Version: 1.2.8p16
AgentOS: linux
Hostname: mycmkserver
AgentDirectory: /etc/check_mk
DataDirectory: /var/lib/check_mk_agent
SpoolDirectory: /var/lib/check_mk_agent/spool
PluginsDirectory: /usr/lib/check_mk_agent/plugins
LocalDirectory: /usr/lib/check_mk_agent/local
<<<df>>>

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:

root@linux# timeout --help
Usage: timeout [OPTION] DURATION COMMAND [ARG]...
  or:  timeout [OPTION]
  Start COMMAND, and kill it if still running after DURATION.

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

root@linux# waitmax --help
age: waitmax [-s SIGNUM] MAXTIME PROGRAM [ARGS...]

Execute PROGRAM as a subprocess. If PROGRAM does not exit before MAXTIME
seconds, it will be killed with SIGTERM or an alternative signal.

   -s, --signal SIGNUM   kill with SIGNUM on timeout
   -h, --help            this help
   -V, --version         show version an exit

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:

root@linux# grep 'export MK_' check_mk_agent
export MK_LIBDIR="/usr/lib/check_mk_agent"
export MK_CONFDIR="/etc/check_mk"
export MK_VARDIR="/var/lib/check_mk_agent"

Diese drei Verzeichnisse sollten Sie anlegen:

root@linux# mkdir /usr/lib/check_mk_agent /etc/check_mk /var/lib/check_mk_agent

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:

/etc/xinetd.d/check_mk_agent
service check_mk
{
        type           = UNLISTED
        port           = 6556
        socket_type    = stream
        protocol       = tcp
        wait           = no
        user           = root
        server         = /usr/local/bin/check_mk_agent
        only_from      = 10.118.14.5 10.118.14.37
        disable        = no
}

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

root@linux# /etc/init.d/xinetd restart

3. Test und Fehlerdiagnose

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 Check_MK-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:

root@linux# check_mk_agent
<<<check_mk>>>
Version: 1.2.8p16
AgentOS: linux
Hostname: myhost123
AgentDirectory: /etc/check_mk
DataDirectory: /var/lib/check_mk_agent
SpoolDirectory: /var/lib/check_mk_agent/spool
PluginsDirectory: /usr/lib/check_mk_agent/plugins
LocalDirectory: /usr/lib/check_mk_agent/local
<<<df>>>
udev              devtmpfs     8155492         4   8155488       1% /dev
tmpfs             tmpfs        1634036      1204   1632832       1% /run
/dev/sda5         ext4       226298268 176973752  37806104      83% /
none              tmpfs              4         0         4       0% /sys/fs/cgroup

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

root@linux# check_mk_agent | less

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

Debugmodus

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:

root@linux# check_mk_agent -d 2>&1 | less

4. Einbinden von klassischen Checkplugins

4.1. Plugins über MRPE ausführen

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

Der Check_MK-Agent bietet einen einfachen Mechnismus, 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 Check_MK für den Service verwenden soll, den es dafür automatisch erzeugt. Hier ist ein Beispiel:

/etc/check_mk/mrpe.cfg
Foo_Application /usr/local/bin/check_foo -w 60 -c 80
Bar_Extender /usr/local/bin/check_bar -s -X -w 4:5

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:

root@linux# check_mk_agent | grep -A1 '^...mrpe'
<<<mrpe>>>
(check_foo) Foo_Application 0 OK - Foo server up and running
<<<mrpe>>>
(check_bar) Bar_Extender 1 WARN - Bar extender overload 6.012|bar_load=6.012

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 Check_MK automatisch. Sobald Sie die Serviceerkennung für den Host aufrufen, werden die beiden neuen Services als verfügbar angezeigt. Das sieht dann so aus (hier in der neuen Darstellung von Version 1.4.0):

Ü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):

/etc/check_mk/mrpe.cfg
Foo%20Application /usr/local/bin/check_foo -w 60 -c 80
Bar%20Extender /usr/local/bin/check_bar -s -X -w 4:5

4.2. Asynchrone Ausführung

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 allzugroß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 Check_MK 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):

/etc/check_mk/mrpe.cfg
Foo_Application (interval=300) /usr/local/bin/check_foo -w 60 -c 80
Bar_Extender /usr/local/bin/check_bar -s -X -w 4:5

Das hat mehrere Auswirkungen:

  • Das Plugin wird in einem Hintergrundprozess ausgeführt und bremst nicht mehr die Ausführung des Agenten.
  • Weil der Agent die Ausführung nicht abwartet, wird das Ergebnis erst beim nächsten Aufruf des Agenten geliefert.
  • Frühestens nach 300 Sekunden wird das Plugin neu ausgeführt. Bis dahin wird das alte Ergebnis wiederverwendet.

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

4.3. MRPE mit der Agentbakery

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

Backen der Plugins

Auch die Checksplugins selbst können Sie mit dem Paket ausliefern lassen. Damit ist der Agent dann komplett und braucht keine manuelle Installation von weiteren Dateien. Das Ganze geht so:

  1. Erzeugen Sie auf dem Check_MK-Server das Verzeichnis local/share/check_mk/agents/custom.
  2. Erzeugen Sie dort ein Unterverzeichnis – z. B. my_mrpe_plugins.
  3. Erzeugen Sie wiederum darin das Unterverzeichnis bin.
  4. Kopieren Sie Ihre Plugins in den bin-Ordner.
  5. Legen Sie eine Regel in Monitoring Agents ➳ Generic Options ➳ Deploy custom files with agent an.
  6. Wählen Sie my_mrpe_plugins aus, speichern Sie und backen Sie!

Die Checkplugins werden jetzt in das Standard-bin-Verzeichnis Ihres Agenten installiert. Per Default ist das /usr/bin. Bei der Konfiguration der MRPE-Checks brauchen Sie dann also /usr/bin/check_foo anstelle von /usr/local/bin/check_foo.

5. Agent um Plugins erweitern

5.1. Was sind Plugins?

Der Standardagent /usr/bin/check_mk_agent enthält eine ganze Reihe von Sektionen, welche Über­wachungsdaten 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 Monitoringdaten erweitern. Das Check_MK-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:

  • Das Plugin ist in einer anderen Programmiersprache als Shell geschrieben und kann daher nicht inline realisiert werden (Beispiel: mk_logwatch).
  • Das Plugin braucht sowieso eine Konfiguration, ohne die es nicht funktionieren würde (Beispiel: mk_oracle).
  • Das Plugin ist so speziell, dass ihn die meisten Anwender nicht brauchen (Beispiel: plesk_domains).

5.2. Manuelle Installation von Plugins

Die vom Projekt mitgelieferten Plugins für Linux und UNIX finden Sie alle auf dem Check_MK-Server unter local/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.

5.3. Konfiguration der Plugins

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:

  • Die Dokumentation der zugehörgen Checkplugins im WATO-Modul Check plugins
  • Kommentare im Plugin selbst (oft sehr hilfreich!)
  • Einen passenden Artikel in diesem Handbuch (z. B. über das Überwachen von Oracle)

5.4. Asynchrone Ausführung

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:

root@linux# cd /usr/lib/check_mk_agent/plugins
root@linux# mkdir 300
root@linux# mv my_foo_plugin 300

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

5.5. Plugins über die Bakery installieren

Die von Check_MK 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 agentes ➳ Agent plugins:

5.6. Plugins von Hand ausführen

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:

root@linux# export MK_LIBDIR=/usr/lib/check_mk_agent
root@linux# export MK_CONFDIR=/etc/check_mk
root@linux# export MK_VARDIR=/var/lib/check_mk_agent
root@linux# /usr/lib/check_mk_agent/plugins/mk_foobar
<<<foobar>>>
FOO BAR BLA BLUBB 17 47 11

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

6. Absicherung

6.1. Vorüberlegung

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 Check_MK auf Sicherheit Wert gelegt und es gilt seit den ersten Tagen von Check_MK 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.

Ab Version 1.4.0 verfügt der Check_MK-Agent 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.

6.2. Beschränkung des Zugriffs über IP-Adressen

Auch wenn ein Angreifer keine Befehle ausführen kann: Die Monitoringdaten 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.

Xinetd

Wenn Sie den Check_MK-Agenten ganz normal über den xinetd freigeben, ist es sehr einfach und effektiv, den Zugriff auf bestimmte IP-Adressen zu beschränken – und zwar natürlich auf die des Monitoringservers. Das ist einfach gemacht und war schon im Beispiel weiter oben zu sehen:

/etc/xinetd.d/check_mk_agent
service check_mk
{
        type           = UNLISTED
        port           = 6556
        socket_type    = stream
        protocol       = tcp
        wait           = no
        user           = root
        server         = /usr/bin/check_mk_agent
        only_from      = 10.118.14.5 10.118.14.37
        disable        = no
}

Benutzer der Agentenbäckerei können die erlaubten IP-Adressen über den Regelsatz Monitoring agents ➳ Rules ➳ Generic options ➳ Restrict agent access via IP address per WATO konfigurieren.

Natürlich kann ein Angreifer sehr leicht seine IP-Adresse fälschen und so eine Verbindung zum Agenten bekommen. Aber dann ist es sehr wahrscheinlich, dass er die Antwort nicht bekommt – weil diese zum echten Monitoringserver geht. Oder er bekommt sie tatsächlich, aber der Check_MK-Server guckt dann in die Röhre und wird sehr bald einen Fehler melden.

Systemd

Weil Systemd jetzt das Neue Tolle ist, was alle machen, arbeiten Linux-Distributoren hart daran, den guten alten Xinetd abzuschaffen. Der vorpaketierte Linux-Agent (nicht der aus der Bakery!) installiert sich daher bereits mit Mitteln des Systemd, wenn das Zielsystem auf Systemd basiert und kein Xinetd verfügbar ist.

Nun kann aber Systemd leider so einfache Dinge wie only_from nicht (Pöttering!!). Man wird lapidar auf iptables verwiesen. Sollte Ihr Agent also ohne Xinetd rein mit Systemd aufgerufen werden, gibt es leider keine einfachere Möglichkeit der IP-Adressbeschränkung, als in die Konfiguration der Firewall einzusteigen.

Wenn Sie noch nicht zu den Systemd-Evangelisten gehören, gibt es aber einen einfachen Ausweg: Es ist selbst bei Systemd-basierten Systemen (noch) möglich, Xinetd zu verwenden. Dieser läuft dann als Dienst unter Systemd. Und dann geht auch wieder die oben beschriebene Methode mit only_from. Installieren Sie dazu das Paket xinetd und danach den Check_MK-Agenten erneut. Dieser sollte dann Xinetd finden und bevorzugt einrichten.

6.3. Aufruf über SSH

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

  • Überwachung von Linux-Servern, die nur über das Internet erreichbar sind
  • Überwachung von Rechnern in einer DMZ
  • In ähnlichen Situationen, in denen eine TCP-Verbindung vom Check_MK-Server auf den Agenten überhaupt möglich ist.

Das Einrichten geschieht in folgenden Schritten:

  1. Erstellen Sie ein SSH-Schlüsselpaar speziell für diesen Zweck.
  2. Erlauben Sie auf den Zielsystemen den Zugriff auf den Agenten mittels dieses Schlüssels.
  3. Klemmen Sie den Zugriffs über Xinetd ab.
  4. Konfigurieren Sie den Check_MK-Server so, dass er anstelle der TCP-Verbindung auf Port 6556 SSH verwende

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

SSH-Schlüsselpaar erstellen

SSH arbeitet mit einer „Public-Key-Authentifizierung“. Dazu erzeugt man zunächst ein Paar von aufeinander abgestimmten Schlüsseln, bei denen einer öffenltich (public) ist und einer geheim (private). Sie machen das als Instanzbenutzer mit ssh-keygen -t ed25519:

OMD[mysite]:~$ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/omd/sites/mysite/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /omd/sites/mysite/.ssh/id_ed25519.
Your public key has been saved in /omd/sites/mysite/.ssh/id_ed25519.pub.
The key fingerprint is:
cc:87:34:d2:ed:87:ed:f7:1b:ec:58:1f:7c:23:00:e2 mysite@mycmkserver
The key's randomart image is:
+--[ED25519  256--+
|                 |
|       . .       |
|      ..+..      |
|      .=.+.o     |
|       ES +.o    |
|         . o. o  |
|            ...B.|
|             .=.*|
|             . o+|
+-----------------+

Wichtig: Geben Sie hier keine Passphrase an! Es nützt Ihnen nichts, die Datei mit dem geheimen Schlüssel zu verschlüsseln. Denn Sie möchten ja sicher nicht jedesmal beim Start des Check_MK-Servers die Passphrase eingeben müssen …

Das Ergebnis sind zwei Dateien im Verzeichnis .ssh:

OMD[mysite]:~$ ll .ssh
total 8
-rw------- 1 mysite mysite 1679 Feb 16 14:18 id_ed25519
-rw-r--r-- 1 mysite mysite  398 Feb 16 14:18 id_ed25519.pub

Der private Schlüssel heißt id_ed25519, ist nur für den Instanzbenutzer lesbar (-rw-------) und das ist auch gut so! Der öffentliche Schlüssel id_ed25519.pub sieht etwa so aus:

OMD[mysite]:~$ cat .ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGb6AaqRPlbEmDnBkeIW3Q6Emb5lr2QEbWEQLmA5pb48 mysite@mycmkserver

Zugriff per SSH erlauben

Der nächste Schritt muss jetzt auf (je-)dem per SSH überwachten Linux-Server stattfinden. Loggen Sie sich dort als root ein und legen Sie in dessen Homeverzeichnis (/root) das Unterverzeichnis .ssh an, falls es das nicht bereits gibt:

root@linux# mkdir /root/.ssh

Die Berechtigungen des Verzeichnisses müssen 700 sein, damit SSH es anerkennt. Falls Sie das Verzeichnis selbst angelegt haben, brauchen Sie daher noch:

root@linux# chmod 700 /root/.ssh

Öffnen Sie jetzt die Datei authorized_keys mit einem (konsolenbasierten) Texteditor Ihrer Wahl. Falls die Datei nicht existiert, wird sie der Editor automatisch anlegen:

root@linux# vim /root/.ssh/authorized_keys

Kopieren Sie jetzt den Inhalt der Publickeys in diese Datei. Das geht z. B. mit der Maus und Copy & Paste. Seien Sie genau! Jedes Leerzeichen zählt. Achten Sie auch darauf, dass nirgendwo zwei Leerzeichen hintereinander sind. Und: Das ganze ist eine Zeile! Wenn die Datei schon existiert, dann hängen Sie einfach unten eine neue Zeile an.

Zugriff auf die Ausführung des Agenten beschränken

Was jetzt kommt, ist sehr wichtig! Der SSH-Schlüssel soll ausschließlich zur Ausführung des Agenten dienen. SSH bietet so etwas unter dem Namen Command restriction an. Dazu setzen Sie den Text command="/usr/bin/check_mk_agent" An den Anfang der Zeile, die Sie gerade erzeugt haben – mit einem Leerzeichen vom Rest getrennt. Das sieht dann etwa so aus:

/root/.ssh/authorized_keys
command="/usr/bin/check_mk_agent" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGb6AaqRPlbEmDnBkeIW3Q6Emb5lr2QEbWEQLmA5pb48 mysite@mycmkserver

Speichern Sie die Datei, kontrollieren Sie die Rechte. Die müssen auf 600 gesetzt sein:

root@linux# chmod 600 /root/.ssh/authorized_keys
root@linux# ll /root/.ssh/authorized_keys
-rw------- 1 root root 1304 Feb 16 14:36 authorized_keys

Jetzt sollte vom Monitoringserver aus ein Zugriff auf den Agenten per SSH möglich sein. Das können Sie so überprüfen:

OMD[mysite]:~$ ssh root@myhost123
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is 55:34:f9:dd:2b:db:a7:fc:5d:4c:9d:37:28:f7:69:62.
Are you sure you want to continue connecting (yes/no)? yes
<<<check_mk>>>
Version: 1.4.0p3
AgentOS: linux
Hostname: myhost123
AgentDirectory: /etc/check_mk
DataDirectory: /var/lib/check_mk_agent
SpoolDirectory: /var/lib/check_mk_agent/spool
PluginsDirectory: /usr/lib/check_mk_agent/plugins
LocalDirectory: /usr/lib/check_mk_agent/local
<<<df>>>

Die Abfrage nach dem key fingerprint kommt übrigens nur beim ersten Mal. Wenn es nicht klappt, überprüfen Sie bitte:

  • Ist der SSH-Server auf dem Zielsystem überhaupt installiert?
  • Haben die genannten Dateien und Verzeichnisse die richtigen Berechtigungen?
  • Haben Sie die Syntax von authorized_keys korrekt getippt?
  • Haben Sie dort den richtigen öffentlichen Schlüssel eingetragen?
  • Haben Sie sich als der richtige Benutzer eingeloggt (root@...)?
  • Haben Sie an das command="..." gedacht?

Zugriff über Xinetd abklemmen

Das ganze Einrichten von SSH nützt nichts, wenn der Zugriff über Port 6556 nach wie vor möglich ist. Um den zu schließen, setzen Sie den Xinetd-Dienst von Check_MK auf disabled. Löschen Sie nicht die ganze Konfigurationsdatei. Diese würde beim nächsten Agentenupdate sonst wieder auftauchen!

Das Deaktivieren geht in /etc/xinetd.d/check_mk_agent:

/etc/xinetd.d/check_mk_agent
service check_mk
{
        type           = UNLISTED
        port           = 6556
        socket_type    = stream
        protocol       = tcp
        wait           = no
        user           = root
        server         = /usr/bin/check_mk_agent
        disable        = yes
}

Danach den Neustart von Xinetd nicht vergessen:

root@linux# /etc/init.d/xinetd restart

Die Deinstallation von Xinetd ist natürlich auch möglich – aber dann wird sich der Check_MK-Agent beim nächsten Update unter Umständen wieder über Systemd aktivieren!

Vergessen Sie auf keinen Fall einen abschließenden Test. Eine Vebindung auf Port 6556 darf jetzt nicht mehr möglich sein:

OMD[mysite]:~$ telnet myhost123 6556
Trying 10.118.15.23...
telnet: Unable to connect to remote host: Connection refused

Zugriff von Check_MK auf SSH umstellen

Das Zielsystem ist vorbereitet. Jetzt fehlt nur noch die Konfiguration von Check_MK selbst. Das geschieht über den Regelsatz Datasource programs ➳ Individual program call instead of agent access. Erstellen Sie hier für die betroffenen Hosts eine Regel und tragen Sie als Befehl ssh -T -oStrictHostKeyChecking=no root@<IP> ein:

Nach einem Speichern und einem Activate changes sollte alles funktionieren! Als Diagnose bieten sich die Befehle cmk -D und cmk -d an, die im Artikel über die Kommandozeile erklärt werden.

Einzelheiten über die „Datasource programs“ erfahren Sie in einem eigenen Artikel.

Mehrere SSH-Schlüssel

Sie können auch mit mehr als einem SSH-Schlüssel arbeiten. Legen Sie die Schlüssel in einem beliebigen Verzeichnis ab. Beim „Datasource program“ müssen Sie den Pfad zum jeweiligen privaten Schlüssel dann mit der Option -i angeben. Verwenden Sie hier am besten $OMD_ROOT als Ersatz für den Pfad zum Instanzverzeichnis (/omd/sites/mysite). Dann ist die Konfiguration auch in einer Instanz mit einem anderen Namen lauffähig:

Sie können so für verschiedene Gruppen von Hosts verschiedene SSH-Schlüssel verwenden, indem Sie mehrere unterschiedliche Regeln in Datasource programs verwenden.

6.4. Eingebaute Verschlüsselung

Ab Version 1.4.0 von Check_MK kann der Linux-Agent (und auch das Windows-Pendant) 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 ( Check_MK Raw Edition) oder mit der Agentenbäckerei ( Check_MK Enterprise Edition).

Aufsetzen ohne Bakery

Auch ohne Agentbakery geht der erste Schritt über WATO: Anlegen einer Regel im Regelsatz Host & Service Parameters ➳ Access to agents ➳ Encryption. Die Regel soll auf alle Hosts greifen, für die Sie Verschlüsselung einsetzen möchten. SNMP-Hosts ignorieren diese Einstellung, daher müssen Sie sie nicht explizit ausschließen.

Wichtig ist die Einstellung für Encryption for agent. Solange Sie die Regel auf dem Default Disable lassen, bleibt natürlich alles beim Alten. Sie haben also die Wahl zwischen:

  • Enable: Verschlüsselung wird aktiviert, aber Daten von Agenten ohne Verschlüsselung werden weiter akzeptiert.
  • Enforce: Verschlüsselung wird aktiviert, nur noch verschlüsselte Daten werden akzeptiert.

Sinnvoll ist es, zunächst mit Enable zu beginnen. Sobald Sie meinen, dass alle Agenten auf Verschlüsselung umgestellt sind, stellen Sie auf Enforce, um dadurch Hosts zu finden, die noch Daten im Klartext senden.

Die Verschlüsselung funktioniert mit einem gemeinsamen Passwort, das Sie hier angeben und sowohl auf dem Check_MK-Server als auch auf dem Agenten im Klartext gespeichert werden muss („Shared secret“). Wählen Sie ein zufälliges Passwort aus und halten Sie es parat für den zweiten Schritt: die Konfiguration des Agenten.

Dort erzeugen Sie die Datei /etc/check_mk/encryption.cfg mit folgendem Inhalt:

/etc/check_mk/encryption.cfg
ENCRYPTED=yes
PASSPHRASE='XEwks9fm'

Natürlich setzen Sie hier bei PASSPHRASE Ihr eigenes Passwort ein. Und Sie sollten die Datei unbedingt vor Lesezugriffen anderer Benutzer schützen:

root@linux# chmod 600 /etc/check_mk/encryption.cfg

Jetzt können Sie folgende Tests machen (siehe dazu auch den Artikel über die Kommandozeile von Check_MK):

  • Ein Aufruf von check_mk_agent auf dem Zielsystem muss wirren Zeichensalat ausgeben.
  • Ein telnet myhost123 6556 vom Check_MK-Server muss den gleichen Zeichensalat ausgeben.
  • Ein cmk -d myshost123 auf dem Check_MK-Server muss die sauberen Klartextdaten anzeigen.

Aufsetzen mit der Bakery

Das Aufsetzen der Verschlüsselung mit der Agentbakery ist sehr einfach. Mit dem Erstellen der gerade beschriebenen Regel sind Sie im Grunde fertig. Sie brauchen nur noch neue Agenten zu backen und zu verteilen. Die Datei /etc/check_mk/encryption.cfg wird automatisch für Sie erzeugt und mit in die Agentenpakete eingebaut.

7. Überwachen von Linux per SNMP

Da es für Linux einen einfach aufzusetzenden SNMP-Agenten gibt, kommt gelegentlich die Frage auf, ob es nicht möglich oder sogar sinnvoll wäre, Linux per SNMP zu überwachen. Die Antwort ist sehr einfach: möglich ja, sinnvoll nein. Warum?

  • Die Monitoringdaten des SNMP-Agenten sind sehr begrenzt. Daher brauchen Sie den Check_MK-Agenten für eine habwegs sinnvolle Überwachung sowieso.
  • Der SNMP-Agent liefert keine sinnvollen Daten, die nicht auch der Check_MK-Agent liefern würde.
  • Der SNMP-Agent ist umständlicher aufzusetzen.
  • Nicht zuletzt braucht das Protokoll SNMP deutlich mehr CPU- und Netzwerkressourcen als die normale Überwachung mit Check_MK.

Es gibt allerdings ein paar wenige Situationen, in denen eine Überwachung per SNMP zusätzlich zum normalen Agenten sinnvoll sein kann. Und zwar ist das der Fall, wenn entweder eine eigene Anwendungs­software oder ein Hardwareüber­wachungstool des Serverherstellers Überwachungsdaten nur per SNMP liefern.

Setzen Sie in so einem Fall in den Eigenschaften des Hosts im WATO im Kasten Host tags die Einstellung Agent type auf Dual: Check_MK Agent + SNMP. Services, die sowohl per SNMP als auch per Check_MK-Agent verfügbar sind (z. B. CPU-Auslastung, Dateisysteme, Netzwerkkarten), werden dann automatisch vom Check_MK-Agenten geholt und nicht per SNMP. Damit wird eine Doppeltübertragung automatisch vermieden.

8. Hardwareüberwachung

8.1. Grundsätzliches

Zu einer möglichst vollständigen Überwachung eines Linux-Servers gehört natürlich auch die Hardware. Dies geschieht teils direkt mit dem Check_MK-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.

8.2. Überwachung der SMART-Werte

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 Check_MK 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:

  • Das Paket smartmontools muss installiert sein. Sie können es auf allen modernen Distributionen über den jeweiligen Paketmanager installieren.
  • Falls die Festplatten hinter einem RAID-Controller liegen und dieser Zugriff auf die SMART-Werte erlaubt, muss das jeweilige Tool dazu installiert sein. Unterstützt werden tw_cli (3ware) und megacli (LSI).

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

8.3. Überwachung mit Hilfe von IPMI

IPMI (Intelligent Platform Management Interface) ist eine Schnittstelle zum Hardwaremanagement, welche unter anderem die Überwachung der Hardware ermöglicht. Check_MK 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 Check_MK ü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 Check_MK 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:

root@linux# ipmi-sensors Temperature
32 Temperature_Ambient 20.00_C_(1.00/42.00) [OK]
96 Temperature_Systemboard 23.00_C_(1.00/65.00) [OK]
160 Temperature_CPU_1 31.00_C_(1.00/90.00) [OK]
224 Temperature_CPU_2 NA(1.00/78.00) [Unknown]
288 Temperature_DIMM-1A 54.00_C_(NA/115.00) [OK]
352 Temperature_DIMM-1B 56.00_C_(NA/115.00) [OK]
416 Temperature_DIMM-2A NA(NA/115.00) [Unknown]
480 Temperature_DIMM-2B NA(NA/115.00) [Unknown]

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

root@linux# ipmitool sensor list
UID_Light 0.000 unspecified ok na na 0.000 na na na
Int._Health_LED 0.000 unspecified ok na na 0.000 na na na
Ext._Health_LED 0.000 unspecified ok na na 0.000 na na na
Power_Supply_1 0.000 unspecified nc na na 0.000 na na na
Fan_Block_1 34.888 unspecified nc na na 75.264 na na na
Fan_Block_2 29.792 unspecified nc na na 75.264 na na na
Temp_1 39.000 degrees_C ok na na -64.000 na na na
Temp_2 16.000 degrees_C ok na na -64.000 na na na
Power_Meter 180.000 Watts cr na na 384.00

8.4. Herstellerspezifische Tools

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 Check_MK bereitstellen zu können:

  • Auf dem Linuxhost ist ein SNMP-Server eingerichtet.
  • Das Tool des Herstellers ist installiert (z. B. Dells OpenManage oder Supermicros SuperDoctor ).
  • Der Host ist in Check_MK für die zusätzliche Überwachung per SNMP konfiguriert ( Agent type auf Dual: Check_MK Agent + SNMP ).

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

8.5. Zusätzliche Überwachung über das Managementboard

Seit Version 1.4.0 kann man 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.

9. Dateien und Verzeichnisse

9.1. Pfade auf dem überwachten System

Pfad Bedeutung
/usr/bin/check_mk_agent Installationsort des Check_MK-Agenten auf dem Zielsystem.
/etc/check_mk Ablage von Konfigurationsdateien für den Agenten.
/etc/check_mk/mrpe.cfg Konfigurationsdatei für MRPE – für die Ausführung von klassischen Nagios-kompatiblen Checkplugins.
/etc/check_mk/encryption.cfg Konfiguration für die Verschlüsselung der Agentendaten.
/usr/lib/check_mk_agent Basisverzeichnis für Erweiterungen des Agenten.
/usr/lib/check_mk_agent/plugins Plugins, welche den Agenten um zusätzliche Überwachungsdaten erweitern. Plugins können in jeder verfügbaren Programmiersprache geschrieben werden.
/usr/lib/check_mk_agent/local Eigene „Localchecks“.
/etc/xinetd.d/check_mk_agent Konfiguration für den xinetd, welche die Ausgabe des Agenten an den TCP-Port 6556 bindet.

9.2. Pfade auf dem überwachten System

Pfad Bedeutung
local/share/check_mk/agents/custom Basisverzeichnis für eigene Dateien, die mit einem gebackenen Agenten mit ausgeliefert werden sollen.