Checkmk
to checkmk.com

1. Einleitung

Checkmk ist sehr modular aufgebaut und kann an vielen Stellen mit Python-Programmierkenntnissen erweitert werden. Unter anderem ist es möglich, Checkmk um folgende Elemente ausbauen:

  • Eigene Checks und Agentenplugins inklusive Eingabemasken für die Konfigurationsumgebung

  • Eigene Plugins für die Checkmk HW/SW-Inventur

  • Erweiterungen für die GUI (Ansichten, Dashboards, Spalten, Icons, etc.)

  • Definitionen von Graphen oder Perf-O-Metern

  • Benachrichtigungs- und Alert Handler-Skripte (auch in Shell oder anderen Skriptsprachen)

All diese Erweiterungen werden durch Ablage von zusätzlichen Dateien unterhalb des Verzeichnisses ~/local innerhalb der Checkmk-Instanz realisiert. Um diese Erweiterungen sinnvoll zu verwalten, innerhalb von verteilten Umgebungen auszurollen und auch mit anderen Anwendern auszutauschen, stellt Checkmk ein eigenes Paketformat bereit: das Checkmk Erweiterungspaket — kurz MKP.

Ein MKP sammelt eine beliebige Menge von Erweiterungen — z.B. einen Satz Check-Plugins inklusive zugehöriger Handbuchseiten, der Konfigurationsumgebung für Schwellwerte und zugehörigen Metrikdefinitionen. Es kann darüber hinaus Einstellungen für die Verteilung via Agentenbäckerei enthalten. Das MKP hat einen Namen, eine Versionsnummer und kann mit einer einfachen Aktion installiert oder auch wieder entfernt werden.

Hinweis: Das in diesem Artikel geschilderte Verhalten mit zweistufiger Installation/Deinstallation entspricht Checkmk 2.1.0p21. Frühere Versionen verwenden eine einstufige Installation/Deinstallation. Dieses Verhalten wurde nachgerüstet, um eine Aktualisierung von 2.0.0 nach 2.1.0 (und später von 2.1.0 nach 2.2.0) zu erleichtern.

1.1. Die Checkmk Exchange

Auf der Checkmk Exchange können Plugin-Programmierer Pakete für andere Checkmk-Benutzer bereitstellen und untereinander austauschen. Von dort können Sie kostenlos Erweiterungen herunterladen und verwenden. Beachten Sie bei Paketen von der Exchange, dass diese durch andere Benutzern freiwillig und ohne jede Garantie bereitgestellt werden.

Unsauber programmierte Plugins können zu erhöhter Last und erhöhtem Arbeitsspeicherbedarf führen. Zudem ist es möglich, dass MKPs für ältere Versionen von CMK entwickelt wurden und so keine vollständige Kompatibilität vorhanden ist (von Version 1.6.0 auf 2.0.0 wechselte Checkmk von Python 2 auf Python 3). In Extremfällen droht Datenverlust. Wir empfehlen daher vor dem produktiven Einsatz fremder MKPs die Installation in einer Testinstanz.

1.2. Werkzeuge für MKPs

Zur Verwaltung von MKPs gibt es zwei Werkzeuge:

  • Den Kommandozeilenbefehl mkp

  • Den Setup-Menüeintrag Extension Packages (nur CEE Checkmk Enterprise Editions)

Beide Verwaltungswerkzeuge stellen wir Ihnen nun näher vor. Sie sind miteinander kompatibel, so dass Sie mal den Kommandozeilenbefehl und mal Extension Packages verwenden können, ohne dass dabei etwas „durcheinander gerät“.

2. Erweiterungspakete über das Setup-Menü verwalten

CEE Die Möglichkeit MKPs über die GUI zu verwalten gibt es ausschließlich in den Enterprise Editions von Checkmk. Im Setup-Menü steigen Sie in die Verwaltung der MKPs über Setup > Maintenance > Extension packages ein. Hier können Sie MKPs hinzufügen, ändern oder neu erstellen:

mkp manager sidebar

2.1. Hinzufügen eines MKPs

Ein MKP, das Sie z.B. von der Exchange heruntergeladen haben, können Sie mit dem Knopf Upload package in Checkmk hochladen und so verfügbar machen. Dafür muss die Datei auf dem Rechner vorhanden sein, auf dem auch Ihr Webbrowser läuft. Die Dateiendung des Pakets muss .mkp sein.

mkp manager upload

Nach der Installation ist das Erweiterungspaket zunächst verfügbar. Es befindet sich unter All packages (enabled or disabled):

mkp manager present not active

2.2. Aktivierung eines MKPs

Erst mit dem Klick auf das Steckersymbol icon install wird ein verfügbares Paket auch aktiviert. Bei der Aktivierung werden die Dateien in einer Ordnerhierarchie unterhalb von ~/local/ installiert. Außerdem wird die Paketbeschreibungsdatei in ~/var/check_mk/packages/ abgelegt. Nach dem Aktivierung erscheint das Paket dann auch in der Liste der freigeschalteten und aktiven MKPs – Enabled (active on this site):

mkp manager list active

Nun führen Sie noch eine Aktivierung der Änderungen durch und alle Funktionen aus dem Paket sind im System verankert und stehen Ihnen bereit.

2.3. Pakete deaktivieren und entfernen

Auch die vollständige Löschung eines Paketes erfolgt zweistufig. Mit dem icon disabled deaktivieren Sie in der Liste der aktiven Pakete ein Paket zunächst. In diesem Schritt werden die installierten Dateien entfernt, aber das MKP wird weiter vorgehalten – dieser Schritt macht lediglich die Aktivierung rückgängig.

Über das Symbol icon delete in der Liste aller Pakete, können Sie installierte und nicht verwendete Pakete wieder löschen. Beim Löschen wird das Paket gelöscht und somit die Erweiterung komplett entfernt – also das Gegenteil des Hinzufügens eines Paketes.

2.4. MKPs in verteilten Umgebungen

Bei einem verteilten Setup reicht es, wenn Sie die Pakete auf der Zentralinstanz verfügbar machen. Für jede der Zentralinstanz zugeordneten Remote-Instanz können Sie dann separat bestimmen, ob die Anpassungen an diese Instanz übertragen werden sollen. Sie müssen dazu lediglich die Option Replicate extensions aktivieren. Danach werden bei der Synchronisation auch die MKPs und alle anderen Änderungen unterhalb des Verzeichnisses ~/local übertragen.

mkp distr wato

Ist die Übertragung nicht gewünscht, schalten Sie die Option für diese oder alle Instanzen einfach ab.

Wichtig: Die Anpassungen für das verteilte Setup werden nur übertragen, wenn die Option Enable replication auf Push configuration to this site eingestellt ist.

2.5. Sonderfall: Freigeschaltete, aber inaktive Pakete

Ein Sonderfall stellt der Aktivierungsversuch eines Paketes dar, das nicht zur verwendeten Checkmk-Version passt. Ein solches Paket, das zwar freigeschaltet ist, aber dessen Aktivierung wegen einer inkompatiblen Checkmk-Version fehlschlägt, landet in der Liste Enabled (inactive on this site).

mkp manager all states

Warum aber sollte man Pakete installieren, die nicht zur verwendeten Checkmk-Version passen? Dafür gibt es zwei gute Gründe:

  1. Das Update der Checkmk-Version: Sie haben die Möglichkeit, Pakete sowohl für die alte als auch für die neue Version vorzuhalten – beim Update wird dann automatisch das neuere aktiviert.

  2. Verteiltes Monitoring: Um Updates zu erleichtern, darf die Checkmk-Major-Version von Remote-Instanzen eine höher als die der Zentralinstanz sein. Dies erschwerte jedoch bislang die Verteilung von MKPs, denn diese mussten zu beiden Major-Versionen kompatibel sein. Mit der Möglichkeit, auch unpassende Pakete freizuschalten, können Sie in der Zentralinstanz jeweils Pakete vorhalten, die zur Ausgangs- und Zielversion passen. Beim Update wird dann automatisch das neuere aktiviert.

Aus den Versionsnummern im obigen Screenshot können Sie entnehmen, dass es sich um eine Checkmk 2.1.0 Zentralinstanz handelt, die Pakete für Remote-Instanzen bereithält, welche bereits auf 2.2.0 aktualisiert wurden.

3. MKPs für Entwickler

Wenn Sie selbst Plugins für Checkmk programmieren oder modifizieren, beachten Sie die Artikel zu den vorhandenen Programmierschnittstellen und der Dateisystemstruktur, der Integration in die Agentenbäckerei sowie die Richtlinien für Check-Plugins.

3.1. Pakete auflösen

Das icon release mkp Auflösen eines Paketes entlässt die paketierten Dateien unter ~/local/ sozusagen "in die Freiheit" und entfernt nur die Paketbeschreibung. Als Ergebnis sind die Dateien dann unpaketiert und die Erweiterungen weiterhin aktiv. Dies ist das Gegenteil des Erzeugens eines Pakets aus bisher unpaketierten Dateien.

In der Praxis werden Sie das Auflösen von Paketen am ehesten benötigen, wenn Sie eine Erweiterung anpassen und später mit Änderungen neu paketieren wollen. Zum Beispiel können Sie mit unserem Hello world! Beispiel, welches nichts sinnvolles tut, aber als Vorlage für das erste eigene Paket dienen kann, loslegen.

3.2. Pakete erstellen

Das Erstellen eines eigenen MKPs ist sehr einfach, wenn die Programmierarbeit abgeschlossen ist. Ausgangspunkt ist, dass Sie unter ~/local/ in den entsprechenden Verzeichnissen eigene Dateien angelegt haben. Für eigene agentenbasierte Check-Plugins ist das richtige Verzeichnis z.B. ~/local/lib/check_mk/base/plugins/agent_based. Diese Dateien gehören zunächst zu keinem Paket und werden daher unter Unpackaged files aufgelistet:

mkps unpackaged
Liste der Unpackaged files und der Knopf Create package

Über den Knopf icon new mkp Create package gelangen Sie zum Dialog zum Erstellen eines neuen Pakets:

mkps create

Neben den offensichtlichen Angaben ist es wichtig, dass Sie mindestens eine Datei auswählen, die eingepackt werden soll. Durch das Erstellen wird eine Paketbeschreibung unter ~/var/check_mk/packages/ angelegt, welche neben den allgemeinen Angaben auch die Liste der enthaltenen Dateien beinhaltet. Die maximal unterstützte Checkmk-Version ist natürlich ohne Glaskugel schwer vorherzusagen. Als Faustregel kann angenommen werden: Was für 2.0.0 ohne Verwendung alter APIs programmiert wurde, läuft auch mit 2.1.0 und 2.2.0. Daher dient die maximale Checkmk-Version vor allem bei der Verteilung über die Exchange dazu, ältere Pakete zu identifizieren, die intensivere Tests und möglicherweise Anpassungen benötigen.

Dieses Paket können Sie nun — z.B. um es auf ein anderes System zu übertragen oder auf die Exchange hochzuladen — in der Paketliste mit dem Symbol icon download als MKP-Datei herunterladen.

Bei Änderungen an paketierten Dateien muss das Paket nicht neu erstellt werden. Klicken Sie auf icon edit, um die Versionsnummer zu ändern, speichern Sie das geänderte Paket und laden Sie es gegebenenfalls neu herunter.

4. MKP auf der Kommandozeile

Alle oben genannten Aktionen können Sie auch auf der Kommandozeile ausführen. Dazu dient der Befehl mkp (der eigentlich eine Abkürzung für cmk -P ist):

OMD[mysite]:~$ mkp
Usage: check_mk [-v] -P|--package COMMAND [ARGS]

Available commands are:
   create NAME             ...  Collect unpackaged files into new package NAME
   pack NAME               ...  Create package file from installed package
   release NAME            ...  Drop installed package NAME, release packaged files
   find                    ...  Find and display unpackaged files
   list                    ...  Show a table of all known packages
   list NAME               ...  List files of installed package
   list PACK.mkp           ...  List files of uninstalled package file
   show NAME               ...  Show information about installed package
   show PACK.mkp           ...  Show information about uninstalled package file
   install PACK.mkp        ...  Install or update package from file PACK.mkp
   remove NAME VERSION     ...  Uninstall and delete package NAME
   disable NAME [VERSION]  ...  Disable package NAME
   enable NAME VERSION     ...  Enable previously disabled package NAME
   disable-outdated        ...  Disable outdated packages

   -v  enables verbose output

Package files are located in /omd/sites/mysite/var/check_mk/packages.

4.1. Installation eines MKPs

Das Hinzufügen eines Pakets geschieht mit mkp install. Dazu müssen Sie die MKP-Datei natürlich zunächst auf den Checkmk-Server bringen (z.B. mit scp). Anschließend führen Sie den folgenden Befehl aus:

OMD[mysite]:~$ mkp install /tmp/hello_world-0.2.1.mkp

Die Liste der vorhandenen Pakete rufen Sie mit mkp list ab:

OMD[mysite]:~$ mkp list
Name        Version Title        Req. Version Until Version Files State
----------- ------- ------------ ------------ ------------- ----- -----------------------------
hello_world 0.2.1   Hello world! 2.1.0        2.1.999       6     Enabled (active on this site)

4.2. Pakete deaktivieren und entfernen

Die Deinstallation eines Pakets geschieht in zwei Stufen. Zunächst wird das Paket mit mkp disable deaktiviert. Dies löscht installierte Dateien, hält das Paket aber – beispielsweise für eine spätere erneute Aktivierung – weiterhin vor. Die Angabe der Versionsnummer ist nur in dem Fall erforderlich, dass der Name alleine nicht eindeutig ist:

OMD[mysite]:~$ mkp disable hello_world 0.2.1

In der Paketliste sehen Sie nun den Zustand Disabled, wenn Sie ein weiteres mal mkp list aufrufen:

OMD[mysite]:~$ mkp list
Name        Version Title        Req. Version Until Version Files State
----------- ------- ------------ ------------ ------------- ----- --------
hello_world 0.2.1   Hello world! 2.1.0        2.1.999       6     Disabled

Erst mkp remove löscht das Paket unwiderruflich:

OMD[mysite]:~$ mkp remove hello_world 0.2.1

4.3. Sonderfall: Freigeschaltete, aber inaktive Pakete

Ein Sonderfall stellt die Installation eines Paketes dar, das nicht zur verwendeten Checkmk-Version passt:

OMD[mysite]:~$ mkp install /tmp/hello_world-0.2.2.mkp
The package requires Check_MK version 2.2.0, but you have 2.1.0p21 installed.

Ein solches Paket, das zwar freigeschaltet ist, aber dessen Aktivierung wegen einer inkompatiblen Checkmk-Version fehlschlägt, erhält den Zustand Enabled (inactive on this site).

OMD[mysite]:~$ mkp list
Name        Version Title        Req. Version Until Version Files State
----------- ------- ------------ ------------ ------------- ----- -------------------------------
hello_world 0.2.2   Hello world! 2.2.0        2.2.999       6     Enabled (inactive on this site)
hello_world 0.2.1   Hello world! 2.1.0        2.1.999       6     Enabled (active on this site)

Die Gründe für die Installation inkompatibler Pakete – Updates und verteilte Umgebungen – erklären wir weiter oben. Ebenso analog zum vorgehen im Setup verwenden Sie mkp enable paketname version, um ein Paket freizuschalten, respektive mkp disable paketname version, um eine vorhandene Freischaltung aufzuheben.

4.4. Pakete auflösen

Ein vorhandenes und aktives Paket (State: Enabled (active on this site)) können Sie mit mkp release auflösen. Dabei bleiben die Erweiterungsdateien erhalten und nur das Download-Paket und die Paketbeschreibung werden gelöscht:

OMD[mysite]:~$ mkp release mypackage

4.5. Pakete erstellen

Die Vorgehensweise zum Erstellen von MKPs auf der Kommandozeile ist analog zum Setup-Menü. Zunächst erstellen Sie Ihre Erweiterungen in den passenden Verzeichnissen unterhalb von ~/local/. Alle unpaketierten Dateien listen Sie dann mit mkp find auf:

OMD[mysite]:~$ mkp find
/omd/sites/mysite/local/lib/check_mk/base/plugins/agent_based/mycheck
/omd/sites/mysite/local/lib/check_mk/base/plugins/agent_based/mycheck_manpage

Jetzt erzeugen Sie mit dem Befehl mkp create eine Paketkonfiguration, welche (vorerst) all diese Dateien beinhaltet. Geben Sie dabei den gewünschten Namen des neuen Pakets an:

OMD[mysite]:~$ mkp create mypackage

Die Eigenschaften des Pakets editieren Sie nun mit einem Texteditor. Die Datei dazu liegt in ~/var/check_mk/packages/mypackage:

~/var/check_mk/packages/mypackage
{'author': 'myName',
 'description': u'This package contains a check plugin',
 'download_url': 'http://www.example.com',
 'files': {'agent_based': [],
           'agents': [],
           'checkman': ['mycheck'],
           'checks': ['mycheck'],
           'doc': [],
           'inventory': [],
           'lib': [],
           'notifications': [],
           'pnp-templates': [],
           'web': []},
 'name': 'myPackage',
 'num_ files': 2,
 'title': 'My own check plugin',
 'version': '1.0',
 'version.min_required': '2.0.0',
 'version.packaged': '2.0.0p23'
 'version.usable_until': '2.1.999'}

Bearbeiten Sie diese Datei nach Ihren Wünschen. Achten Sie auf korrekte Python-Syntax. Unicode-Zeichenketten (Texte, die nicht-ASCII-Zeichen wie Umlaute enthalten) müssen mit einem kleinen vorangestellten u gekennzeichnet werden.

Unter dem Eintrag files können Sie Dateien entfernen, welche nicht paketiert werden sollen. Tragen Sie unter version.min_required die Mindestversion von Checkmk ein, die erforderlich ist, um das Paket zu verwenden.

Anschließend können Sie mit mkp pack eine MKP-Datei erzeugen:

OMD[mysite]:~$ mkp pack mypackage
OMD[mysite]:~$ ll *.mkp
-rw-rw-r-- 1 mysite mysite 495 Dez 22 13:36 mypackage-1.0.mkp
Auf dieser Seite