Monitoringagenten

Bisher haben wir nur von aktiver Überwachung gesprochen — der Paradedisziplin von Checkmk. Es gibt auch den umkehrten Weg, nämlich dass die Zielsysteme von sich aus Nachrichten an das Monitoring senden, z.B. per Syslog oder SNMP Traps. Für dieses ganze Thema hat Checkmk die Event Console, welche in einem eigenen Artikel beschrieben ist.

Wie beschrieben, benötigen Sie für die Überwachung von Servern und Workstations einen Checkmk-Agenten. Im Checkmk-Projekt werden aktuell Agenten für elf verschiedene Betriebssystemfamilien gepflegt. Alle diese Agenten sind Bestandteil von Checkmk und stehen über die Web-GUI des Checkmk-Servers zum Download bereit. In den Enterprise Editions gibt es außerdem die Agent Bakery. Diese erlaubt es Ihnen, eigene Agenten zu „backen“, welche eine individuelle Konfiguration und Sammlung von Plugins enthalten. Das geht sogar individuell pro Host unterschiedlich.

Die Agenten erreichen Sie über das WATO-Modul Monitoring Agents. Bei den Enterprise Editions gelangen Sie so erstmal in die Agent Bakery. Der Knopf Agent files bringt Sie dann dorthin, wo Sie bei der Raw Edition direkt landen: der Download-Seite für die Agenten und deren Plugins:

Die paketierten Agenten für Windows (check_mk_agent.msi) und Linux (Dateien mit .deb oder .rpm) finden Sie gleich im ersten Abschnitt. Nach Installation dieser Pakete ist der Agent grundsätzlich lauffähig und Sie können mit dem Monitoring beginnen. Alle weitere Konfiguration geschieht über Konfigurationsdateien und die Installation von Plugins durch Download von der gleichen Seite sowie manuelles Kopieren in die entsprechenden Verzeichnisse.

Aufbau, Konfiguration und Möglichkeiten der Agenten unterscheiden sich je nach Betriebssystem. Details zu bestimmten Agenten finden Sie deswegen in eigenen Artikeln:

Zwar funktioniert der Checkmk-Agent auch erstmal „nackt“, also ohne Konfiguration und Plugins, aber in einigen Fällen muss der Agent eben doch angepasst werden. Beispiele:

Wenn Sie im Besitz einer der Enterprise Editions sind, dann können Sie mit der Agent Bakery Agenten individuell paketieren. So können Sie Agenten-Pakete erzeugen, die neben dem eigentlichen Agenten auch Konfiguration und zusätzliche Plugins enthalten. Diese Pakete können Sie mit einem einzigen Befehl installieren. Sie eignen sich daher ideal für eine automatische Verteilung und Installation. Und Sie können sogar für bestimmte Gruppen von Hosts individuelle Agenten erzeugen. Das schafft vor allem in Verbindung mit dem automatischen Agent Deployment große Flexibilität.

Sie erreichen die Bakery über WATO > Monitoring Agents:

Wenn Sie noch keine Einstellungen für bestimmte Hosts vorgenommen haben, gibt es nur eine einzige Standardagentenkonfiguration. Version 1.6.0 von Checkmk unterstützt mit der Bakery die Betriebssysteme Windows, Linux, Solaris und AIX. Bei Linux haben Sie dabei die Wahl zwischen den Paketformaten RPM (SUSE, RedHat, CentOS) und DEB (Debian, Ubuntu) sowie einem Tarball, der einfach als root unter / ausgepackt wird. Für AIX steht ebenfalls ein Tarball bereit. Dieser enthält allerdings keine automatische Integration in den inetd. Dies muss einmalig von Hand gemacht werden. Für Solaris gibt es wiederum den Tarball sowie ein PKG-Paket.

Jede Agentenkonfiguration hat eine eindeutige ID: den Hash. Die ersten 8 Zeichen des Hashs werden in der GUI angezeigt. Dieser Hash wird Teil der Paketversion und auch in den Namen der Paketdatei eingebaut. Wann immer Sie etwas an der Konfiguration eines Paketes ändern oder Checkmk aktualisieren, ändert sich auch der Hash des Pakets. Dadurch erkennt der Paketmanager des Betriebssystems, dass es sich um ein anderes Paket handelt und führt ein Update durch. Die Version von Checkmk wäre hier nicht ausreichend.

Die Konfiguration des Agenten ändern Sie wie so oft in Checkmk über Regeln. Diese bieten Ihnen die Möglichkeit, verschiedene Hosts mit unterschiedlichen Einstellungen oder Plugins auszustatten. Über den Knopf Rules gelangen Sie zu einer Seite, die Ihnen alle Regelsätze zeigt, die die Agenten beeinflussen:

Nehmen wir folgendes Beispiel: Sie möchten die Liste der IP-Adressen beschränken, welche auf den Agenten zugreifen dürfen. Dazu wählen Sie den Regelsatz Generic Options > Allowed agent access via IP address. Tragen Sie als Wert der Regel eine oder mehrere IP-Adressen ein:

Gehen Sie nach dem Speichern mit zurück zur Agent Bakery. Der Knopf sorgt für ein neues Backen der Agenten. Das Ergebnis: Sie haben nun zwei Konfigurationen:

In der Spalte Hosts finden Sie eine Liste von Hosts, welche der jeweiligen Konfiguration zugeordnet sind. Aus Platzgründen ist die Liste nicht vollständig. Eine Sonderrolle nehmen die beiden Namen VANILLA und GENERIC ein. Diese beiden Pseudo-Hosts sind immer vorhanden und haben folgende Funktion:

Je mehr Host-spezifische Regeln Sie aufstellen, desto mehr unterschiedliche Varianten von Agenten werden gebaut. Die Bakery achtet dabei darauf, dass nur solche Kombinationen von Konfigurationen gebaut werden, die auch von mindestens einem der vorhandenen Hosts verwendet werden.

Sie erreichen die Agentenpakete für einen Host übrigens auch bequem über die Details eines Hosts in WATO über den Knopf Monitoring Agent:

Warum werden für jeden Host die Pakete für alle Betriebssysteme angeboten? Die Antwort ist sehr einfach: Solange kein Agent auf einem System installiert ist, kann Checkmk das Betriebssystem natürlich nicht erkennen! Sobald die automatischen Agenten-Updates aktiviert sind, brauchen Sie sich darum ohnehin nicht mehr zu kümmern.

Sehr viele Regeln befassen sich mit der Installation verschiedener Plugins. Diese erweitern den Agenten um die Überwachung von ganz bestimmten Komponenten. Meist sind dies spezielle Anwendungen wie z.B. Datenbanken. Bei der Regel, welche das Plugin aktiviert, finden Sie auch gleich die Einstellungen für die Konfiguration des Plugins. Hier als Beispiel die Regel für die Überwachung von MySQL:

Bitte beachten Sie, dass Sie Konfigurationsdateien, die die Bakery erzeugt, auf dem Zielsystem nicht von Hand anpassen. Zwar wird das erstmal funktionieren, aber beim nächsten Update des Agenten sind die Änderungen wieder verloren. Das Installieren von zusätzlichen Plugins und Konfigurationsdateien ist dagegen problemlos möglich.

Die Agenten für die verschiedenen Betriebssysteme werden zwar unabhängig voneinander entwickelt, verhalten sich aber am Ende aus Sicht von Checkmk immer gleich: Sie öffnen den TCP-Port 6556 für Anfragen durch den Monitoringserver. Das Abfrageprotokoll ist absolut einfach: Der Server verbindet sich zu dem Port und schon strömen die Daten des Agenten herein — in lesbarer Textform. Sobald diese vollständig sind, schließt der Agent von sich aus den Port. Grundsätzlich liest der Agent keine Daten vom Netzwerk!

Sie können einen korrekt installierten Agenten sehr einfach von der Kommandozeile aus abfragen. Am besten machen Sie das direkt von der Checkmk-Instanz aus, welche den Agenten auch produktiv überwachen soll. So können Sie sicherstellen, dass die IP-Adresse des Servers vom Agenten akzeptiert wird. Als Befehl eignet sich z.B. telnet:

Mit nc oder netcat kommen die Daten „nackt“ daher. Das ist z.B. auch nützlich, wenn Sie diese per Skript weiterverarbeiten möchten:

Die Ausgabe beginnt immer mit der Zeile <[check_mk]>. Zeilen, die in <<< und >>> eingeschlossen sind, werden als Sektionsheader bezeichnet. Sie teilen die Agentenausgaben in Sektionen. Jede Sektion enthält zusammengehörige Informationen und ist meist einfach die die Ausgabe eines Diagnosebefehls. Die Sektion check_mk spielt eine Sonderrolle. Sie enthält allgemeine Informationen über den Agenten selbst, wie z.B. dessen Versionsnummer.

Wenn der Host bereits in das Monitoring aufgenommen ist, können Sie die Daten auch mit dem Befehl cmk -d abrufen. Dieser verwendet dann die per WATO konfigurierte IP-Adresse, berücksichtigt eine eventuell umkonfigurierte Portnummer und auch den Fall eines Spezialagenten:

Wenn das Monitoring für den besagten Host bereits regelmäßig läuft, finden Sie immer eine aktuelle Kopie der Ausgabe im Verzeichnis tmp/check_mk/cache:

Auch über die GUI können Sie eine Diagnose des Agenten durchführen. Diese berücksichtigt sämtliche Einstellungen, unterstützt auch SNMP-basierte Geräte und solche, die über einen Spezialagenten abgefragt werden. Das praktische: Checkmk probiert hier einfach immer gleichzeitig die Abfrage über TCP-Port 6556 und SNMP. Sie erreichen die Diagnose über die Details eines Hosts in WATO mit dem Knopf Diagnostic:

Etliche der Einstellungen (z.B. die SNMP-Comunity) können Sie auch hier sofort ausprobieren und bei Erfolg speichern.