Skip to content

Migration from Nagios

Vesana does not accept results from Nagios (no passively submitted results, no import of configuration files). The path is parallel operation: Vesana checks the same devices itself, you compare, and then switch Nagios off group by group. Your own Nagios plugins keep running in Vesana as monitoring scripts — Vesana understands the plugin format (exit code + perfdata) directly.

Phase 1 — Create the devices in Vesana

The list of hosts with IPs is in your object files (hosts.cfg). In Vesana you create them with the host wizard, or find them via discovery and adopt them from there. The matching device profiles bring the usual checks along.

Phase 2 — Replace the checks

Active Nagios checks run from the Nagios server. In Vesana this is done by a collector in the same network, the active checker on the Vesana server, or the agent on the machine itself.

Mapping

Nagios plugin Vesana check type
check_ping ping
check_http http (status, content, response time) or http_json for APIs
check_http with certificate check ssl_certificate
check_tcp port
check_snmp snmp / snmp_oid / snmp_string
check_disk agent_disk (agent, all partitions automatically) or ssh_disk (without agent)
check_load agent_cpu (agent) or ssh_cpu
check_mem agent_memory (agent) or ssh_mem
check_procs agent_process (agent) or ssh_process
check_nrpe usually replace with the agent, or agent_custom with a local command
check_nt (NSClient++) agent
custom plugins monitoring script (agent_script or ssh_script), see phase 6

All types: check types reference.

Gradually

  1. Per host group (e.g. "web servers") check: what is monitored today?
  2. Pick a pilot host
  3. Install the agent or assign a collector → enable the matching profile checks
  4. Run both in parallel for a few days, compare values
  5. Switch off the Nagios checks for this host
  6. Expand to the next host group

Phase 3 — Recreate notifications

Nagios notifications (email, SMS, escalation) live in contacts.cfg and services.cfg. In Vesana:

Nagios concept Vesana equivalent
contact with email / pager notification channel (email, push to the phone, Telegram, Slack, Teams, webhook, …)
notification_period no time window on the alert rule; recurring downtimes suppress messages outside the desired times
escalation escalation steps in the alert rule
host_dependencies / service_dependencies dependencies with inhibition

Per notification set in Nagios: one alert rule in Vesana with the matching channels and escalation.

Phase 4 — Dashboards & maps

PNP4Nagios → dashboards with line chart widgets, or the check history on the host. NagVis → the maps (logical/physical) plus a dashboard with a status overview or heatmap.

Phase 5 — Hostgroups + servicegroups

Nagios hostgroups → folders, tags and profiles in Vesana.

Example: - Nagios hostgroup web-servers → folder or tag web on the hosts - Nagios servicegroup database → tag database on the hosts or a profile of its own

Phase 6 — Custom plugins

If Nagios used custom plugins (/usr/local/nagios/libexec/check_*):

  • Create the script content in Vesana as a monitoring script (Bash/Python/PowerShell)
  • Output format nagios — exit code, message and perfdata are evaluated as in Nagios
  • Create a check of type agent_script (runs on the agent) or ssh_script (runs via SSH) with that script
  • Standard plugins from monitoring-plugins on the Vesana server run as check type plugin_local via the Active Checker — only from its plugin directories (among them /usr/lib/nagios/plugins); for tenants this needs the approval "Own plugins on the server" under Admin → Agents & Collectors → Active checker
  • Declare values that differ per device (paths, names) as configurable values on the script instead of copying it — see Configurable values

The plugin content then lives centrally in Vesana instead of being spread across every machine.

FAQ

Do we need to reconfigure all checks?

Yes, in Vesana itself — there is no takeover of the Nagios configuration. The device profiles take most of the work off you: a profile creates the usual checks of a device type in one go.

What about notification_period?

There is no time window per alert rule. Suppress messages outside certain times with a recurring downtime.

Can we import data from Nagios?

No, neither configuration nor status history. Keep the old Nagios running read-only for a while until Vesana has enough history of its own.

What about notifications via script?

If Nagios calls a custom script via notification_command: create a webhook channel in Vesana that calls an endpoint of your script.

Next