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
mkpDen Setup-Menüeintrag Extension Packages (nur
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
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:
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.
Nach der Installation ist das Erweiterungspaket zunächst verfügbar. Es befindet sich unter All packages (enabled or disabled):
2.2. Aktivierung eines MKPs
Erst mit dem Klick auf das Steckersymbol 
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):
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 
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 
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.
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
 |
Verlust von Einstellungen droht! Beim Update der Major-Version löscht Checkmk Regeln, die nicht mehr benötigt werden. Falls Sie Pakete vor dem Update deinstallieren, um nach dem Update eine neue Version zu installieren, gehen möglicherweise noch benötigte Einstellungen verloren. Installieren Sie stattdessen immer neue und alte Pakete wie in diesem Abschnitt beschrieben parallel und entfernen Sie alte erst nach dem Update. |
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).
Warum aber sollte man Pakete installieren, die nicht zur verwendeten Checkmk-Version passen? Dafür gibt es zwei gute Gründe:
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.
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 
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:
Über den Knopf 
Create package gelangen Sie zum Dialog zum Erstellen eines neuen Pakets:
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 
als MKP-Datei herunterladen.
Bei Änderungen an paketierten Dateien muss das Paket nicht neu erstellt werden.
Klicken Sie auf 
, 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.mkpDie 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.1In 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 DisabledErst mkp remove löscht das Paket unwiderruflich:
OMD[mysite]:~$ mkp remove hello_world 0.2.14.3. Sonderfall: Freigeschaltete, aber inaktive Pakete
|
Verlust von Einstellungen droht! Beim Update der Major-Version löscht Checkmk Regeln, die nicht mehr benötigt werden. Falls Sie Pakete vor dem Update deinstallieren, um nach dem Update eine neue Version zu installieren, gehen möglicherweise noch benötigte Einstellungen verloren. Installieren Sie stattdessen immer neue und alte Pakete wie in diesem Abschnitt beschrieben parallel und entfernen Sie alte erst nach dem Update. |
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 mypackage4.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_manpageJetzt 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 mypackageDie Eigenschaften des Pakets editieren Sie nun mit einem Texteditor.
Die Datei dazu liegt in ~/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