Skip to content

Migration from Checkmk

Checkmk has probably the most mature auto-discovery model among major tools. Vesana is simpler there, with some advantages:

  • Single-binary deployment (no Apache site reseller setup)
  • Multi-tenant native without customer plugin
  • Mobile push out of the box
  • Built-in AI analysis

Concept mapping

Checkmk Vesana Note
Host Host identical
Service Profile-check + host-service analog Zabbix item
Rule (in WATO) Alert rule more general in Vesana
Folder + folder inheritance Tag hierarchy + profiles tag filter replaces folder inheritance
Tag Tag identical
Service discovery Profile apply + SNMP picker manual in Vesana
Cluster currently no direct counterpart workaround: dependencies + inhibition
Periodic discovery manual re-walk via SNMP picker scriptable
Notification rule Alert rule + notification channel both combined
Time period not directly see Zabbix
Custom check (local check) Monitoring script identical concept
Special agent (vSphere, AWS) currently not for special integrations: custom scripts
MK Inventory plugin currently not inventory outside Vesana
BI (Business Intelligence) Custom dashboards not as powerful as Checkmk BI
Site (distributed monitoring) Multiple collectors / multiple tenants structurally different

Phase 1 — Site inventory

On the Checkmk server:

# All hosts:
omd su <site>
cmk -L

# All services per host:
cmk -d <hostname>

# Discovery for a host:
cmk -II <hostname>

Phase 2 — Create profiles in Vesana

Per Checkmk „discovered service group" (e.g. „filesystem", „cpu_load", „mem_used") a profile-check in an Vesana profile.

Built-in profiles cover the most important cases: Generic Linux, Generic Windows, SNMP devices. Special profiles for ESXi, NetApp, etc. partly available — otherwise custom.

Phase 3 — Agent swap

Linux

# Stop Checkmk agent
sudo systemctl stop check-mk-agent

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

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

Windows

Uninstall Checkmk agent service. Then run Vesana agent setup wizard.

Both agents in parallel works (different ports), but rarely useful.

Phase 4 — Service discovery

Checkmk does automatic service discovery on agent start. Vesana does manual profile application. Workflow:

  1. Create host in Vesana with matching profile
  2. Auto-add profile-checks create standard services (CPU, memory, disk, …)
  3. For SNMP devices: SNMP sensor picker for present sensors
  4. With agent_services_auto (Windows) the agent detects all auto-start services and reports them as a combined check

What Checkmk auto-detects (filesystems, interfaces): currently manual or via SNMP picker in Vesana.

Phase 5 — Rules / notifications

Checkmk rules in WATO are very granular. Vesana rules are simpler: filter + trigger + channels + escalation.

Mapping:

  • WATO „Levels for filesystems" → threshold_warn / threshold_crit in profile-check
  • WATO „Notification rules" → alert rule + channel
  • WATO „Folder-specific rule" → tag filter in alert rule

Per WATO rule: an alert rule in Vesana.

Phase 6 — Tags

Checkmk tags transferable 1:1 as Vesana tags. A 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 similar to Zabbix:

Checkmk Vesana
Sidebar snapin Custom dashboard on default page
Service list Service table
Graph Line chart
Performance graph Heatmap
Notification history Audit log

FAQ

What about cluster services?

No direct cluster concept yet. Workaround:

  • Create cluster hosts as normal hosts with tag cluster-member
  • Dependency relationship: cluster service hangs on the members
  • Inhibition: when a member is CRIT but cluster service is OK → suppress member alerts

Not as elegant as Checkmk cluster, but functionally enough.

Special agents (e.g. vSphere)?

No direct counterpart yet. Workaround:

  • Custom script calling vSphere API (PowerCLI / vSphere API), reading values, returning in Nagios format
  • Per VM an agent_script check

Not as comfortable as Checkmk special agents — coming later.

Inventory (HW/SW inventory)?

Not built into Vesana yet. Recommendation: separate inventory tool, e.g. GLPI / OCSInventory or vendor-specific solutions.

BI (Business Intelligence)?

Custom dashboards with combined status aggregations. Not as powerful as Checkmk BI with aggregation trees — but enough for most use cases.

Can we take Checkmk plugin content?

Local checks (/usr/lib/check_mk_agent/local/) are compatible with Nagios format. These scripts can be imported as monitoring scripts in Vesana, then called via agent_script.

Next