Migration from Checkmk¶

Checkmk has very far-reaching automatic service discovery. In Vesana a device profile creates the usual checks, and you pick the rest deliberately. Other differences that matter when moving:

Docker Compose stack instead of OMD sites
Tenants built in
Push notifications to the phone via the installable web app
Optional AI assistant

Concept mapping¶

Checkmk	Vesana	Note
Host	Host	identical
Service	Profile check + check on the host	analogous to a Zabbix item
Rule (Setup/WATO)	Thresholds on the profile check or check, alert rule for notifications	thresholds apply per profile and can be overridden per device
Folder + folder inheritance	Folders + profiles	folders structure; settings are inherited via the profile, not via the folder
Host tag	Tag	several tags per host
Service discovery	Profile + device scan / SNMP sensor picker	more deliberate than in Checkmk
Cluster	Aggregate (K-of-N)	see FAQ
Periodic discovery	Run the device scan again	no automatism
Notification rule	Alert rule + notification channel	both together
Time period	Recurring downtime	no time window on the alert rule
Local check	Monitoring script	same concept
Special agent (vSphere, Proxmox)	Device profiles via the API	ESXi via the vSphere API, Proxmox VE and Proxmox Backup Server via their API; cloud providers (AWS & co.) not
HW/SW inventory	Deep analysis in the host detail (agent)	no standalone inventory tool
BI (Business Intelligence)	Aggregates + dashboards	no aggregation trees like 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 service group (e.g. "filesystem", "cpu_load", "mem_used"), one profile check in a Vesana profile.

The profiles from the Vesana library cover many device types (Linux, Windows, network devices, NAS, hypervisors, …) — what's missing, create as a profile of your own.

Phase 3 — Agent switch¶

Linux¶

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

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

Then install the Vesana agent with the install command from Vesana (host → set up agent).

Windows¶

Uninstall the Checkmk agent, then install the Vesana agent via the install command or the setup.exe from Vesana.

Both agents can run in parallel — the Vesana agent opens no port, it only connects outbound to the server.

Phase 4 — Service detection¶

Checkmk discovers services automatically. In Vesana:

Create the host and assign the matching profile
The profile checks are created automatically (CPU, RAM, disks, …)
For SNMP devices: device scan or SNMP sensor picker for the sensors that are present
Windows/Linux with agent: agent_disk monitors all partitions, agent_services_auto all automatically starting services

Phase 5 — Rules / notifications¶

Checkmk rules are very granular. In Vesana this splits into two parts:

Setup rule "Levels for filesystems" → thresholds on the profile check, overridable per device
"Notification rules" → alert rule (scope, statuses, delay, channels, escalation)
Folder-specific rule → a profile of its own for those devices, or a device selection in the alert rule (folders and tags are not a filter of an alert rule)

Phase 6 — Tags¶

Checkmk host tags can be taken over as Vesana tags — on the host ("Manage host") or via the API.

Phase 7 — Dashboards¶

Checkmk dashboards → your own dashboards (or the customised built-in overview). Widget mapping:

Checkmk	Vesana
Sidebar snapin	your own version of the overview
Service list	Table or Open problems
Graph	Graph
Performance graph	Heatmap
Notification history	Delivery journal under Alerting, or the diagnostic log

FAQ¶

What about cluster services?¶

An aggregate combines several hosts or checks and judges them as K-of-N ("at least 2 of 3 nodes must be running"). As long as enough members are still running, the aggregate is WARNING instead of CRITICAL. Via dependencies it suppresses follow-up alerts behind it.

Special agents (e.g. vSphere)?¶

ESXi is queried via the vSphere API with a read-only account, Proxmox VE and Proxmox Backup Server via their API — each as a device profile from the Vesana library. For other systems with an API: check type "Script (API)" with a script of your own.

Inventory (HW/SW)?¶

With an agent, the host detail shows hardware, inventory, network and security in the deep analysis. Vesana is not a standalone inventory tool (export, history) — use e.g. GLPI or OCS Inventory for that.

BI (Business Intelligence)?¶

Aggregates (K-of-N) and dashboards. Multi-level aggregation trees as in Checkmk BI do not exist.

Can we take over Checkmk plugin contents?¶

Local checks (/usr/lib/check_mk_agent/local/) use their own format, not the Nagios format. Take the content over as a monitoring script and switch the output to the Nagios format (exit code + message + perfdata) or JSON, then create it as an agent_script check.