1. Willkommen bei Checkmk für Azure
Egal, ob Sie bereits langjähriger Nutzer von Checkmk sind, oder erst mit der Verfügbarkeit fertiger Images im Marketplace von Microsoft Azure zu uns gefunden haben, Sie finden in diesem Handbuchartikel alle Ressourcen, um das vorbereitete VM Image zum für Ihre Bedürfnisse passenden Monitoring zu vervollständigen.
Wenn Sie neu bei Checkmk sind, empfehlen wir die vorbereitende Lektüre unseres Leitfadens für Einsteiger. Vorkonfigurierte VM Images kürzen zwar viele Punkte bei der Installation ab, doch Kenntnis fundamentaler Konzepte, wie das der Instanzen, hilft bei der Einrichtung.
1.1. Grundsätzliches
Falls Sie Azure-Nutzer sind, hatten Sie schon immer die Möglichkeit, ein im Marketplace vorhandenes Ubuntu-Image mit Checkmk zu versehen und so "Monitoring in der Cloud" einzurichten. Checkmk 2.2.0 geht den nächsten Schritt und bietet ein vorinstalliertes Image auf Basis von Ubuntu 22.04 (Jammy Jellyfish), bei denen alle Abhängigkeiten bereits erfüllt sind. Hierbei kommt ausschließlich die Checkmk Cloud zum Einsatz. Diese befindet sich mit dem Einrichten der ersten Instanz im 30 Tage währenden Lizenzstatus "Trial", in dem keine Einschränkungen gelten. Nach Ablauf des Testzeitraums kann Checkmk mit bis zu 750 überwachten Services auf einer einzigen Instanz ohne Subskription weiter genutzt werden. Sollen mehr Services überwacht werden, benötigen Sie einen Lizenzschlüssel.
Generell ist die Einrichtung ein wenig aufwendiger als beispielsweise beim Docker-Image, schließlich muss das bereitgestellte Image verschiedene Einsatzszenarien abdecken:
Setup mit einer einzigen Instanz (single site setup) auf einem Server in verschiedenster Skalierung
Zentralinstanz im verteilten Monitoring
Remote-Instanz im verteilten Monitoring
Mischbetrieb von produktiver Instanz und Instanz(en) zum Testen auf einem Host
Aus diesem Grund enthält das Azure-Image weder eine vorbereitete Instanz, noch E-Mail- oder Firewall-Konfiguration.
In diesem Artikel führen wir Sie durch das komplette Setup. Wo Hintergrundinformationen sinnvoll sind, verlinken wir in detaillierte Artikel des Handbuchs.
2. Vorbereitung
Neben der Dimensionierung von RAM, Prozessor und virtueller Festplatte sollten Sie sich Gedanken um den Speicherort von Backups machen.
Checkmk unterstützt von Haus aus die Objektspeicher von Azure, daneben können Backups in Dateisystempfaden abgelegt werden, was Sicherungen auf SMB- oder WebDAV-Mounts ermöglicht oder den regelmäßigen Transfer per rsync erlaubt.
2.1. SSH-Schlüssel erstellen
Da Azure derzeit keine ED25519 oder ECDSA Schlüssel unterstützt, werden Sie für das erste Login auf der virtuellen Maschine ein RSA-Schlüsselpärchen erstellen, dessen öffentlichen Schlüssel (public key) Sie beim Anlegen der VM hochladen. Alternativ können Sie Azure das Schlüsselpaar erstellen lassen. Vergessen Sie in diesem Fall nicht, den privaten Schlüssel im Laufe des Bestellverfahrens herunterzuladen.
2.2. Benötigte Ports ermitteln
In einer Checkmk-Konfiguration mit einer einzigen Instanz (single site setup), in der Hosts auch im Push-Modus Daten zur Checkmk-Instanz schicken, müssen die folgenden Ports des Checkmk-Servers erreichbar sein:
Von den Hosts im Monitoring aus: Port 80/443 (HTTP/HTTPS, während der Agentenregistrierung) und Port 8000 (Agent Receiver, dauerhaft)
Für die Verwaltung per Browser und REST-API: Port 80/443 (HTTP/HTTPS)
Die Freigaben dieser Ports sind in unseren Inbound port rules bereits vorbereitet. Für bestmögliche Sicherheit sollten Sie den Zugriff im Reiter Networking weiter einschränken.
Konsultieren Sie unsere Übersicht aller verwendeten Ports, falls Sie ein verteiltes Monitoring aufsetzen oder beispielsweise Statusabfragen über die Livestatus-Schnittstelle vornehmen wollen.
2.3. Image im Marketplace buchen
Die folgenden VM-Instanzen stellen eine Empfehlung zur Dimensionierung dar für die Zahl der zu überwachenden Services. Beachten Sie beim Ordern der Instanz, die Option burstable zu deaktivieren.
| Typ | CPU Cores | RAM (GB) | SSD (GB) | Checkmk-Services |
|---|---|---|---|---|
|
4 |
16 |
32 |
12 000 |
|
8 |
32 |
64 |
30 000 |
|
12 |
48 |
96 |
60 000 |
Kalkulationsgrundlage für die Dimensionierung sind ca. 15 % der Services durch Spezialagenten und aktive Checks, sowie 25 oder mehr Services pro regulärem Host, der Daten per Agent im Push-Modus liefert. Unter Umständen sind deutlich mehr Services in einem rein synthetischen Monitoring (primär Spezialagenten liefern Daten) möglich. Bei Verwendung von Agenten im Pull-Modus ist die angegebene Zahl an Services möglicherweise nur durch konsequente Optimierung zu erreichen.
Die Dimensionierung des Festplattenplatzes basiert auf Erfahrungen typischer Windows- und Linux-Serverumgebungen. Bringen viele Dienste eine große Zahl an Metriken mit, kann ein größerer Speicherplatzbedarf entstehen.
2.4. Backup-Speicher buchen
Wegen der günstigen Traffic-Kosten raten wir zur Nutzung des Azure Blob Storage. Für die Kalkulation des benötigten Speicherplatzes lesen Sie die Hinweise zum RRD Datenformat. Als Faustregel für die Kalkulation eines vollständigen Backups gilt, dass die Round Robin Databases nach 10 Tagen etwas mehr als ein Drittel ihrer maximalen Größe erreicht haben. Das bedeutet, nach dieser Zeit ist es sinnvoll, die Größe des gebuchten Backup-Speichers noch einmal zu überprüfen.
3. Einrichtung
3.1. Login auf der virtuellen Maschine
Das Root-Login ist auf den AWS-/Azure-Images deaktiviert.
Stattdessen kommt der Nutzer ubuntu zum Einsatz, der über die Berechtigung verfügt, sudo mit beliebigen Kommandos ohne Passwortabfrage auszuführen.
Wenn Sie ein separates Schlüsselpaar für das Login auf der virtuellen Maschine erstellt haben, müssen Sie mit dem Parameter -i den Pfad zu dessen privaten Teil angeben.
Die IP-Adresse ist natürlich auf die anzupassen, unter der die VM von außen erreichbar ist:
user@host:~$ ssh -i /path/to/id_file.priv ubuntu@192.0.2.123Sie finden sich nun am Prompt des Nutzers ubuntu wieder.
Der exakte Prompt kann als Host-Name den beim Anlegen der VM angegebenen Host-Namen oder eine IP-Adresse enthalten.
Wir verwenden im Laufe des weiteren Artikels den Host-Namen cloud:
ubuntu@cloud:~$3.2. Instanz aufsetzen
Eine Checkmk-Instanz muss eindeutig benannt sein und sollte darüber hinaus eine leichte Identifikation ermöglichen.
Hier, wie in den meisten anderen Stellen dieses Handbuches, verwenden wir als Instanznamen mysite.
Das Erstellen einer Instanz geschieht mit dem Verwaltungswerkzeug von Checkmk, omd.
Vorinstalliert ist immer die neueste Version von Checkmk:
ubuntu@cloud:~$ sudo omd create mysite
Adding /opt/omd/sites/mysite/tmp to /etc/fstab.
Creating temporary filesystem /omd/sites/mysite/tmp...OK
Updating core configuration...
Generating configuration for core (type cmc)...
Starting full compilation for all hosts Creating global helper config...OK
Creating cmc protobuf configuration...OK
Executing post-create script "01_create-sample-config.py"...OK
Restarting Apache...OK
Created new site mysite with version 2.2.0p1.cce.
The site can be started with omd start mysite.
The default web UI is available at http://cloud/mysite/
The admin user for the web applications is cmkadmin with password: UbWeec9QuazIf
For command line administration of the site, log in with 'omd su mysite'.
After logging in, you can change the password for cmkadmin with 'cmk-passwd cmkadmin'.Starten Sie jetzt die neu angelegte Instanz mit
ubuntu@cloud:~$ sudo omd start mysiteDie in der obigen Kommandoausgabe gezeigte URL (http://cloud/mysite) verwendet den intern genutzten Host-Namen Ihrer AWS- oder Azure-VM.
Da dieser in der Regel nicht extern aufgelöst wird, ist die URL von eingeschränktem Nutzen.
In der Regel werden Sie zunächst über die IP-Adresse oder einen im eigenen DNS-Server hinterlegten Host-Namen zugreifen.
3.3. Zertifikate hinterlegen
Damit der System-Apache überhaupt am HTTPS-Port 443 lauschen kann, benötigt er gültige Zertifikate. Beim ersten Start der virtuellen Maschine werden hierfür die selbst signierten Snakeoil Inc. Zertifikate generiert. Wir raten dringend zum baldigen Austausch gegen eigene Zertifikate, bei denen die komplette Zertifikatskette leicht verifiziert werden kann.
Die Apache-Konfiguration hält sich dabei eng an die Ubuntu-Standards, geänderte Zertifikatspfade müssen in der Datei /etc/apache2/sites-enabled/000-default.conf eingetragen werden.
3.4. E-Mail-System einrichten
Da die Wege der Benachrichtigungen in Checkmk vielfältig sind und variieren können, ist kein E-Mail-System vorbereitet.
Checkmk ohne E-Mail-System
Auch der vollständige Verzicht auf ein lokales E-Mail-System ist möglich, falls Sie ausschließlich die nachvollziehbare Zustellung von HTML-E-Mails per SMTP aktivieren wollen oder auf Benachrichtigungs-Plugins für Plattformen wie Microsoft Teams oder Slack setzen.
Beachten Sie aber, dass in dieser Konfiguration keine Sammelbenachrichtigungen möglich ist.
Relay-only oder vollwertiger Mail Transport Agent (MTA)
Im Regelfall werden Sie wegen der höheren Flexibilität ein E-Mail-System einrichten wollen. Für kleinere Umgebungen hat sich der relay-only MTA Nullmailer bewährt.
Für größere Installationen, bei denen unvorhergesehene Ereignisse auch einige Hundert E-Mails zur Folge haben können, empfehlen wir die Installation eines vollwertigen MTAs wie Postfix.
3.5. Hosts ins Monitoring aufnehmen
Localhost im Pull-Modus
In den allermeisten Fällen dürfte der Checkmk-Server selbst der erste Host sein, den Sie ins Monitoring aufnehmen.
Dazu müssen Sie den Linux-Agenten auf dem Checkmk-Server installieren.
Der Agent kommuniziert mit dem Server im Pull-Modus.
Wenn Ihnen der Download des Agentenpaketes über die Weboberfläche mit anschließendem Transfer per scp zu umständlich erscheint, können Sie den Agenten in seiner Standardkonfiguration ("Vanilla") direkt aus dem Dateisystem installieren:
ubuntu@cloud:~$ sudo apt install $(sudo find /opt/omd/versions/ -name 'check-mk-agent_*.deb' | tail -n1)Unmittelbar nach der Installation lauscht der Checkmk-Agent im unverschlüsselten Legacy-Pull-Modus auf Port 6556. Führen Sie daher zeitnah die Registrierung durch, damit keine unbefugten Dritten auf die Agentenausgabe zugreifen können:
ubuntu@cloud:~$ sudo cmk-agent-ctl register --hostname localhost --server localhost --site mysite --user cmkadminHosts im Push-Modus
Sollen Hosts überwacht werden, die hinter einer Firewall nicht direkt vom Checkmk-Server erreicht werden können, ist oft der Push-Modus der bevorzugte Kommunikationsweg. Sie können den Push-Modus in den Eigenschaften des Hosts im Abschnitt Monitoring agents mit der Option Checkmk agent connection mode auswählen. Alternativ können Sie den Push-Modus auch mit vorkonfigurierten Agentenpaketen für die Autoregistrierung kombinieren und so den Komfort weiter erhöhen.
3.6. Checkmk aktualisieren
Prüfen Sie die Download-Seite regelmäßig auf Updates und laden sie das aktualisierte Paket mit dem dort angezeigten wget Kommando herunter.
Die Installation eines Updates erfolgt in zwei Schritten, was darin begründet liegt, dass mit omd verschiedene Instanzen mit verschiedenen Versionen von Checkmk auf einem Server laufen können.
Neue Checkmk-Version installieren und Instanz aktualisieren
Der erste Schritt ist die Installation des Paketes, im folgenden Beispiel die Version 2.2.0p2:
ubuntu@cloud:~$ sudo apt install ./check-mk-cloud-2.2.0p2_0.jammy_amd64.debDer nächste Schritt ist das Update Ihrer Instanz(en):
ubuntu@cloud:~$ sudo omd stop mysite
ubuntu@cloud:~$ sudo omd update mysite
ubuntu@cloud:~$ sudo omd start mysiteNicht mehr benötigte Pakete entfernen
Falls Sie mehrere Instanzen auf dem Server nutzen (beispielsweise eine produktiv genutzte und eine für den Test von Erweiterungen), stellen Sie sicher, dass alle aktualisiert sind:
ubuntu@cloud:~$ omd sites
SITE VERSION COMMENTS
mysite 2.2.0p2.cce default version
mytestsite 2.2.0p2.cce default versionNicht mehr genutzte Checkmk-Versionen können Sie dann über das Ubuntu-Paketmanagement deinstallieren:
ubuntu@cloud:~$ sudo apt purge check-mk-cloud-2.2.0p14. Nachbereitung
4.1. Backup einrichten
Checkmk bietet eine komfortable Backup-Funktion, die Sie unter Setup > Maintenance > Backups > Backup targets konfigurieren. Mit Add backup target fügen Sie einen Speicherort hinzu. Hier bietet es sich an, wegen des schnellen und günstigen Transfers als Destination den Azure Blob Storage zu wählen.
Neben den müssen Sie einen Ordnerpfad angeben, in dem die Zwischenspeicherung des Archivs vorgenommen wird, bevor dieses in den Objektspeicher kopiert wird.
Dies kann unter /tmp sein.
Falls Ihre Azure VM unter /mnt ein flüchtiges (ephemeral) Laufwerk bereitstellt, können Sie auch hier ein Verzeichnis als Zwischenspeicher erstellen:
ubuntu@cloud:~$ sudo mkdir -p /mnt/backup/mysiteDamit der Instanzbenutzer in dieses Verzeichnis schreiben kann, müssen sie es ihm übereignen:
ubuntu@cloud:~$ sudo chown mysite:mysite /mnt/backup/mysiteVorgehen beim Restore
Das Restore eines Backups muss immer auf exakt derselben Version von Checkmk erfolgen wie dessen Erstellung. Soll ein Backup dazu dienen, auf einen anderen Typ der virtuellen Maschine, zu einem anderen Cloud-Anbieter oder von einer On Premise Installation in die Cloud (oder andersherum) umzuziehen, aktualisieren Sie vor dem finalen Backup und dem Umzug auf das höchste verfügbare Patchlevel von Checkmk.
Für das Restore eines Backups gilt damit:
Installieren Sie auf dem Zielsystem exakt die Version von Checkmk, mit der das Backup erstellt wurde.
Erstellen Sie mit
omd createeine Monitoring-Instanz, die denselben Instanznamen wie das Ursprungssystem nutzt.Geben Sie das Backup-Ziel an und laden Sie den Backup-Schlüssel hoch.
Führen Sie das eigentliche Restore durch.
5. Azure überwachen
Checkmk bietet nicht nur die Verfügbarkeit als Azure-Image, sondern auch umfangreiche Möglichkeiten der Überwachung Ihrer Azure-Infrastruktur. Selbst wenn Checkmk Ihr erstes oder einziges Azure-Projekt sein sollte, lohnt bereits die Überwachung der Leistung der virtuellen Maschine, des Zustand der Backup-Vaults und der Höhe der anfallenden Kosten.