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 Checkmk 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 Checkmk auf zu überwachende Systeme zugreift:

Methode | Beschreibung | Vorbereitung |
---|---|---|
Checkmk greift auf den im Zielgerät vorhandenen SNMP-Agenten zu. Mit aktiven Anfragen (GET) holt es Details über den Systemzustand ab. | SNMP-Agent freischalten | |
Checkmk-Agent | Für Server und Workstations hat Checkmk 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 Checkmk-Server werden sie aktiv und antworten mit den benötigten Daten. | Checkmk-Agent installieren |
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 Checkmk-Server laufen, fragt Checkmk diese Schnittstellen ab. | API-Konto für Checkmk anlegen | |
Netzwerkbasierte Dienste wie HTTP, SMTP oder IMAP können naturbedingt einfach über das Netzwerk abgefragt werden. Dazu verwendet Checkmk teils eigene, teils fertige Plugins, die ursprünglich für Nagios entwickelt wurden. Sehr beliebt ist z.B. | keine |
1.1. Überwachung per Events
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.
2. Der Checkmk-Agent
2.1. Download und Installation
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.
2.2. Installation über die Downloadseite
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.
3. Installation über die Agent Bakery
3.1. Einleitung
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:
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 Checkmk-Inventursystems (Plugin nötig)
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 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.
3.2. Konfiguration über Regeln
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:
VANILLA | Ein gedachter Host, dessen Agent nur mit der Defaultkonfiguration gebaut wurde, auf den also keine einzige der Agenten-Regeln Anwendung findet. |
GENERIC | Ein 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 gar nicht 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 Checkmk das Betriebssystem natürlich nicht erkennen! Sobald die automatischen Agenten-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 Konfigurationsdateien 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 Checkmk-Agenten auf allen Hosts ist immer ein größerer
Eingriff. Das automatische Update des Agenten der Checkmk Enterprise Editions
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 Checkmk eine generelle Regel: <b>Neuere Checkmk-Versionen können mit der Ausgabe von älteren Agenten grundsätzlich umgehen</b>.
Achtung: Umgekehrt gilt das nicht unbedingt. Wenn die Checkmk-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 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
:
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.6.0
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.6.0
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.6.0
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.6.0
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: 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.