Monitoringagenten


1. Einleitung

Damit ein Monitoringsystem von einem überwachten Zielsystem mehr Informationen bekommt als nur, ob dieses erreichbar ist, benötigt es dessen Mithilfe. Denn wie soll Check_MK z. B. wissen, wie voll ein Dateisystem auf einem Server ist, ohne dass dieser das irgendwie mitteilt? Die Komponente, die diese Auskunft gibt, ist immer ein aktives Stück Software – also ein Agent.

Natürlich gibt es Situationen, wo man für das Monitoring nicht extra einen Agenten installieren muss – weil nämlich schon einer vorhanden ist, der genutzt werden kann. Bestes Beispiel ist hier SNMP. Alle managebaren Netzwerkgeräte und Appliances haben einen SNMP-Agenten eingebaut.

Wie überall gibt es auch hier eine Ausnahme: die Überwachung von Netzwerkdiensten. So kann z. B. eine Webanwendung von ihrer Natur her von Remote aus per HTTP abgefragt und über diesen Weg auch gemonitort werden. Aber selbst in diesem Fall kommt meist zusätzlich ein Agent zum Einsatz, mit dem man die übrigen Daten des Servers auch in das Monitoring bekommt.

Folgendes Schema zeigt Ihnen die vier verschiedenen Wege, wie Check_MK auf zu überwachende Systeme zugreift:

Methode Beschreibung Vorbereitung
SNMP Check_MK greift auf den im Zielgerät vorhandenen SNMP-Agenten zu. Mit aktiven Anfragen (GET) holt es Details über den Systemzustand ab. SNMP-Agent freischalten
Check_MK-Agent Für Server und Workstations hat Check_MK eigene Agenten. Unterstützt werden elf verschiedene Betriebssysteme – von gängigen wie Windows und Linux, bis zu Exoten wie OpenVMS. Die Agenten verhalten sich passiv und horchen auf TCP Port 6556. Erst bei einer Abfrage durch den Check_MK-Server werden sie aktiv und antworten mit den benötigten Daten. Check_MK-Agent installieren
Spezial-Agent Einige Systeme erlauben weder die Installation eines Agenten noch unterstützen sie SNMP auf brauchbare Weise. Anstelle dessen bieten sie Management-APIs, die auf TELNET, SSH oder HTTP/XML basieren. Über spezielle Agenten, die auf dem Check_MK-Server laufen, fragt Check_MK diese Schnittstellen ab. API-Konto für Check_MK anlegen
Active Checks Netzwerkbasierte Dienste wie HTTP, SMTP oder IMAP können naturbedingt einfach über das Netzwerk abgefragt werden. Dazu verwendet Check_MK teils eigene, teils fertige Plugins, die ursprünglich für Nagios entwickelt wurden. Sehr beliebt ist z. B. check_http für das Abfragen von Webseiten. Diese werden auch als Aktive Checks bezeichnet. Näheres erfahren Sie in einem eigenen Artikel. keine

1.1. Überwachung per Events

Bisher haben wir nur von aktiver Überwachung gesprochen – der Paradedisziplin von Check_MK. 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 Check_MK die Event Console, welche in einem eigenen Artikel beschrieben ist.

2. Der Check_MK-Agent

2.1. Download und Installation

Wie beschrieben, benötigen Sie für die Überwachung von Servern und Workstations einen Check_MK-Agenten. Im Check_MK-Projekt werden aktuell Agenten für elf verschiedene Betriebssystemfamilien gepflegt. Alle diese Agenten sind Bestandteil von Check_MK und stehen über die Web-GUI des Check_MK-Servers zum Download bereit. In der  Check_MK Enterprise Edition 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.

2.2. Installation über die Downloadseite

Die Agenten erreichen Sie über das WATO-Modul Monitoring Agents. Bei der Enterprise Edition gelangen Sie so erstmal in die Agent Bakery. Der Knopf Agent files (bis zu Version 1.2.8: Unpackaged Agents) 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 Konfigurations­dateien und die Installation von Plugins durch Download von der gleichen Seite sowie manuelles Kopieren in die entsprechenden Verzeichnisse.

2.3. Details zu den Agenten bestimmter Betriebssysteme

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

3. Installation über die Agent Bakery

3.1. Einleitung

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

  • Beschränkung des Zugriffs auf bestimmte IP-Adressen
  • Überwachung von ORACLE-Datenbanken (Plugin und Konfiguration nötig)
  • Überwachung von Text-Logdateien (Plugin, Dateinamen und Textmuster nötig)
  • Verwendung des Check_MK-Inventursystems (Plugin nötig)

Wenn Sie im Besitz einer  Check_MK Enterprise Edition 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 Agentenkonfiguration. Diese heißt Default configuration. Version 1.2.8 von Check_MK unterstützt mit der Bakery die Betriebssysteme Windows, Linux 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.

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 Check_MK 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 Check_MK wäre hier nicht ausreichend.

3.2. Konfiguration über Regeln

Die Konfiguration des Agenten ändern Sie wie so oft in Check_MK ü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 ➳ Restrict agent access via IP address. Tragen Sie als Wert der Regel eine oder mehrere IP-Adressen ein:

Gehen Sie nach dem Speichern mit und 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:

VANILLAEin gedachter Host, dessen Agent nur mit der Defaultkonfiguration gebaut wurde, auf den also keine einzige der Agenten-Regeln Anwendung findet.
GENERICEin gedachter Host, auf dem genau alle Regeln greifen, in denen keine weiteren Bedingungen definiert sind. Der Eintrag GENERIC ist vor allem nützlich, um Agenten auf Hosts zu installieren, die noch garnicht in das Monitoring aufgenommen wurden.

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 Check_MK das Betriebssystem natürlich nicht erkennen! Sobald die Automatischen Agent-Updates aktiviert sind, brauchen Sie sich darum ohnehin nicht mehr zu kümmern.

3.3. Plugins

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:

3.4. Manuelle Anpassungen am Angenten

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 Konfigurations­dateien ist dagegen problemlos möglich.

4. Wann soll man den Agenten updaten?

Egal, ob Sie nur eine Handvoll oder gleich tausende Hosts überwachen: Eine Aktualisierung des Check_MK-Agenten auf allen Hosts ist immer ein größerer Eingriff. Das automatische Update des Agenten der  Check_MK Enterprise Edition ist zwar eine Erleichterung, doch trotzdem sollten Sie den Agenten immer nur dann aktualisieren, wenn das Update

  • einen Fehler behebt, von dem Sie betroffen sind, oder
  • neue, benötigte Funktionen enthält.

Damit dies auch so möglich ist, gilt in Check_MK eine generelle Regel: Neuere Check_MK-Versionen können mit der Ausgabe von älteren Agenten grundsätzlich umgehen.

Achtung: Umgekehrt gilt das nicht unbedingt. Wenn die Check_MK-Version eines Agenten neuer ist, als die des Monitoringservers, kann es sein, dass die dort vorhandenen Check-Plugins Ausgaben des Agenten nicht korrekt interpretieren können. In so einem Fall gehen die betroffenen Services auf UNKNOWN (bitte senden Sie in so einem Fall keinen Crash-Report):

5. Fehlerdiagnose

5.1. Agenten über die Kommandozeile testen

Die Agenten für die verschiedenen Betriebssysteme werden zwar unabhängig voneinander entwickelt, verhalten sich aber am Ende aus Sicht von Check_MK 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 Check_MK-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:

OMD[mysite]:~$ telnet 10.1.1.2 6556
Trying 10.1.1.2...
Connected to 10.1.1.2.
Escape character is '^]'.
<<<check_mk>>>
Version: 1.2.7i1
AgentOS: linux
AgentDirectory: /etc/check_mk
DataDirectory: /var/lib/check_mk_agent
SpoolDirectory: /var/lib/check_mk_agent/spool
PluginsDirectory: /usr/lib/check_mk_agent/plugins

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

OMD[mysite]:~$ nc 10.1.1.2 6556
<<<check_mk>>>
Version: 1.2.7i1
AgentOS: linux
AgentDirectory: /etc/check_mk
DataDirectory: /var/lib/check_mk_agent
SpoolDirectory: /var/lib/check_mk_agent/spool
PluginsDirectory: /usr/lib/check_mk_agent/plugins

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:

OMD[mysite]:~$ cmk -d myhost123
<<<check_mk>>>
Version: 1.2.7i1

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:

OMD[mysite]:~$ cat tmp/check_mk/cache/myhost123
<<<check_mk>>>
Version: 1.2.7i1

5.2. Diagnose über die GUI

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