Migration von Checkmk¶

Checkmk hat eine sehr weitgehende automatische Service-Erkennung. In Vesana legt ein Geräteprofil die üblichen Checks an, den Rest wählst du gezielt aus. Weitere Unterschiede, die beim Umzug eine Rolle spielen:

Docker-Compose-Stack statt OMD-Sites
Mandanten (Tenants) eingebaut
Push-Meldungen aufs Handy über die installierbare Web-App
optionaler KI-Assistent

Konzept-Mapping¶

Checkmk	Vesana	Bemerkung
Host	Host	identisch
Service	Profil-Check + Check am Host	analog Zabbix-Item
Rule (Setup/WATO)	Schwellwerte am Profil-Check bzw. Check, Alert-Regel für Meldungen	Schwellwerte gelten pro Profil und lassen sich je Gerät überschreiben
Folder + Folder-Vererbung	Ordner + Profile	Ordner strukturieren; Einstellungen erben über das Profil, nicht über den Ordner
Host-Tag	Tag	mehrere Tags pro Host
Service-Discovery	Profil + Geräte-Scan / SNMP-Sensor-Picker	gezielter als in Checkmk
Cluster	Aggregat (K-von-N)	siehe Häufige Fragen
Periodic discovery	Geräte-Scan erneut ausführen	kein Automatismus
Notification Rule	Alert-Regel + Benachrichtigungs-Kanal	beides zusammen
Time period	wiederkehrende Downtime	kein Zeitfenster an der Alert-Regel
Local check	Monitoring-Script	identisch im Konzept
Special Agent (vSphere, Proxmox)	Geräteprofile über die API	ESXi über die vSphere-API, Proxmox VE und Proxmox Backup Server über ihre API; Cloud-Anbieter (AWS & Co.) nicht
HW/SW-Inventory	Tiefenanalyse im Host-Detail (Agent)	kein eigenständiges Inventar-Werkzeug
BI (Business Intelligence)	Aggregate + Dashboards	keine Aggregations-Bäume wie Checkmk-BI
Site (verteilte Überwachung)	mehrere Collectors / mehrere Tenants	strukturell anders

Phase 1 — Site-Inventur¶

Auf dem Checkmk-Server:

# Alle Hosts:
omd su <site>
cmk -L

# Alle Services pro Host:
cmk -d <hostname>

# Discovery für einen Host:
cmk -II <hostname>

Phase 2 — Profile in Vesana anlegen¶

Pro Checkmk-Service-Gruppe (z. B. „filesystem", „cpu_load", „mem_used") ein Profil-Check in einem Vesana-Profil.

Die Profile aus der Vesana-Bibliothek decken viele Gerätetypen ab (Linux, Windows, Netzwerkgeräte, NAS, Hypervisoren, …) — was fehlt, als eigenes Profil anlegen.

Phase 3 — Agent-Wechsel¶

Linux¶

# Checkmk-Agent stoppen
sudo systemctl stop check-mk-agent

# Optional: deinstallieren
sudo dpkg -r check-mk-agent

Danach den Vesana-Agent mit dem Installationsbefehl aus Vesana installieren (Host → Agent einrichten).

Windows¶

Checkmk-Agent deinstallieren, dann den Vesana-Agent über den Installationsbefehl oder das setup.exe aus Vesana installieren.

Beide Agents können parallel laufen — der Vesana-Agent öffnet keinen Port, er verbindet sich nur ausgehend zum Server.

Phase 4 — Service-Erkennung¶

Checkmk erkennt Services automatisch. In Vesana:

Host anlegen und das passende Profil zuweisen
Die Profil-Checks entstehen automatisch (CPU, RAM, Platten, …)
Bei SNMP-Geräten: Geräte-Scan bzw. SNMP-Sensor-Picker für die vorhandenen Sensoren
Windows/Linux mit Agent: agent_disk überwacht alle Partitionen, agent_services_auto alle automatisch startenden Dienste

Phase 5 — Rules / Notifications¶

Checkmk-Rules sind sehr granular. In Vesana trennt sich das in zwei Teile:

Setup-Rule „Levels for filesystems" → Schwellwerte am Profil-Check, je Gerät überschreibbar
„Notification rules" → Alert-Regel (Geltungsbereich, Statusse, Wartezeit, Kanäle, Eskalation)
Ordner-spezifische Regel → eigenes Profil für diese Geräte bzw. Geräte-Auswahl in der Alert-Regel (Ordner und Tags sind kein Filter einer Alert-Regel)

Phase 6 — Tags¶

Checkmk-Host-Tags lassen sich als Vesana-Tags übernehmen — am Host („Host verwalten") oder über die API.

Phase 7 — Dashboards¶

Checkmk-Dashboards → eigene Dashboards (oder die angepasste eingebaute Übersicht). Widget-Mapping:

Checkmk	Vesana
Sidebar-Snapin	eigene Fassung der Übersicht
Service-Liste	Tabelle oder Offene Probleme
Graph	Graph
Performance Graph	Heatmap
Notification History	Zustell-Journal unter Alerting bzw. Diagnose-Log

Häufige Fragen¶

Was ist mit Cluster-Services?¶

Ein Aggregat fasst mehrere Hosts oder Checks zusammen und bewertet sie als K-von-N („mindestens 2 von 3 Knoten müssen laufen"). Solange noch genug Mitglieder laufen, steht das Aggregat auf WARNING statt CRITICAL. Über Abhängigkeiten unterdrückt es Folge-Alarme dahinter.

Special Agents (z. B. vSphere)?¶

ESXi wird über die vSphere-API mit einem Read-only-Konto abgefragt, Proxmox VE und Proxmox Backup Server über ihre API — jeweils als Geräteprofil aus der Vesana-Bibliothek. Für andere Systeme mit API: Check-Typ „Script (API)" mit einem eigenen Script.

Inventur (HW/SW-Inventarisierung)?¶

Mit Agent zeigt das Host-Detail Hardware, Inventar, Netzwerk und Sicherheit in der Tiefenanalyse. Ein eigenständiges Inventarisierungs-Werkzeug (Export, Historie) ist Vesana nicht — dafür z. B. GLPI oder OCS Inventory.

BI (Business Intelligence)?¶

Aggregate (K-von-N) und Dashboards. Mehrstufige Aggregations-Bäume wie in Checkmk-BI gibt es nicht.

Können wir Checkmk-Plugin-Inhalte übernehmen?¶

Lokale Checks (/usr/lib/check_mk_agent/local/) liefern ein eigenes Format, nicht das Nagios-Format. Den Inhalt als Monitoring-Script übernehmen und die Ausgabe auf das Nagios-Format (Exit-Code + Meldung + Perfdata) oder JSON umstellen, dann als agent_script-Check anlegen.