Zum Inhalt

Migration von Checkmk

Checkmk hat das wahrscheinlich ausgereifteste Auto-Discovery-Modell unter den großen Tools. Vesana ist dort einfacher, hat dafür einige Vorteile:

  • Single-Binary-Deployment (kein Apache-Site-Reseller-Setup)
  • Multi-Tenant nativ ohne Customer-Plugin
  • Mobile-Push out-of-the-box
  • AI-Analyse eingebaut

Konzept-Mapping

Checkmk Vesana Bemerkung
Host Host identisch
Service Profile-Check + Host-Service analog Zabbix-Item
Rule (in WATO) Alert-Rule etwas allgemeiner in Vesana
Folder + Folder-Vererbung Tag-Hierarchie + Profile Tag-Filter ersetzt Folder-Inheritance
Tag Tag identisch
Service-Discovery Profile-Apply + SNMP-Picker manueller in Vesana
Cluster aktuell kein direktes Pendant Workaround: Dependencies + Inhibition
Periodic discovery manueller Re-Walk via SNMP-Picker kann gescriptet werden
Notification Rule Alert-Rule + Notification-Channel beides kombiniert
Time period nicht direkt siehe Zabbix
Custom Check (local check) Monitoring-Script identisch im Konzept
Special Agent (vSphere, AWS) aktuell nicht für Spezialintegrationen Custom-Skripte
MK Inventory Plugin aktuell nicht Inventarisierung außerhalb Vesana
BI (Business Intelligence) Custom Dashboards nicht so mächtig 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-„Discovered service group" (z. B. „filesystem", „cpu_load", „mem_used") ein Profile-Check in einem Vesana-Profil.

Builtin-Profile decken die wichtigsten Fälle: Generic Linux, Generic Windows, SNMP-Geräte. Spezial-Profile für ESXi, NetApp, etc. teilweise vorhanden — sonst Custom anlegen.

Phase 3 — Agent-Wechsel

Linux

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

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

# Vesana-Agent installieren
wget -qO- https://vesana.example.com/agent/install.sh | bash -s -- TOKEN https://vesana.example.com

Windows

Checkmk-Agent als Service deinstallieren. Dann Vesana-Agent-Setup-Wizard.

Beide Agents parallel ist möglich (verschiedene Ports), aber meist nicht sinnvoll.

Phase 4 — Service-Discovery

Checkmk macht automatische Service-Discovery beim Agent-Start. Vesana macht manuelle Profile-Anwendung. Workflow:

  1. Host in Vesana anlegen mit dem passenden Profil
  2. Auto-Add-Profile-Checks erzeugen die Standard-Services (CPU, Memory, Disk, …)
  3. Bei SNMP-Geräten: SNMP-Sensor-Picker für vorhandene Sensoren
  4. Bei agent_services_auto (Windows) erkennt der Agent alle Auto-Start-Services und meldet sie als Sammel-Check

Was Checkmk automatisch erkennt (Filesystems, Interfaces): in Vesana aktuell manuell oder per SNMP-Picker.

Phase 5 — Rules / Notifications

Checkmk-Rules sind in WATO sehr granular. Vesana-Rules sind einfacher: Filter + Trigger + Channels + Eskalation.

Mapping:

  • WATO „Levels for filesystems" → threshold_warn / threshold_crit im Profile-Check
  • WATO „Notification rules" → Alert-Rule + Channel
  • WATO „Folder-spezifische Rule" → Tag-Filter in Alert-Rule

Pro WATO-Rule eine Alert-Rule in Vesana.

Phase 6 — Tags

Checkmk-Tags 1:1 als Vesana-Tags übernehmbar. Ein Bulk-Update-Script:

# scripts/checkmk_tags_import.py
for host in checkmk_hosts:
    vesana.update_host(host.id, tags=host.tags)

Phase 7 — Dashboards

Checkmk-Dashboards → Vesana-Custom-Dashboards. Widget-Mapping ähnlich Zabbix:

Checkmk Vesana
Sidebar-Snapin Custom Dashboard auf Default-Page
Service-Liste Service-Tabelle
Graph Line Chart
Performance Graph Heatmap
Notification History Audit-Log

Häufige Fragen

Was ist mit Cluster-Services?

Aktuell kein direktes Cluster-Konzept. Workaround:

  • Cluster-Hosts als normale Hosts anlegen mit Tag cluster-member
  • Dependency-Beziehung: Cluster-Service hängt drin in den Mitgliedern
  • Inhibition: wenn ein Mitglied CRIT, aber Cluster-Service OK → Mitglied-Alerts unterdrücken

Nicht so elegant wie Checkmk-Cluster, aber funktional ausreichend.

Special Agents (z. B. vSphere)?

Aktuell kein direktes Pendant. Workaround:

  • Custom-Skript, das vSphere-API aufruft (PowerCLI / vSphere-API), Werte ausliest, im Nagios-Format zurückgibt
  • Pro VM einen agent_script-Check

Nicht so komfortabel wie Checkmk Special Agents — wird kommen.

Inventur (HW/SW Inventarisierung)?

Aktuell nicht in Vesana eingebaut. Empfehlung: separates Inventarisierungs-Tool, z. B. GLPI / OCSInventory oder vendor-spezifische Lösungen.

BI (Business Intelligence)?

Custom Dashboards mit kombinierten Status-Aggregationen. Nicht so mächtig wie Checkmk-BI mit Aggregations-Bäumen — aber ausreichend für die meisten Use-Cases.

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

Lokale Checks (/usr/lib/check_mk_agent/local/) sind kompatibel zum Nagios-Format. Diese Skripte können als Monitoring-Script in Vesana eingespielt werden, dann via agent_script aufgerufen.

Anschluss