Skip to content

Migration from Nagios

The simplest migration path — Vesana can receive NSCA packets directly, Nagios plugins return perfdata compatible with Vesana metrics.

Phase 1 — Parallel operation with NSCA

Detail: NSCA receiver.

Short version:

  1. Activate NSCA receiver in Vesana with same decryption-method + password as old nsca.cfg
  2. Create hosts and services in Vesana (importer script available)
  3. Use wrapper script to send send_nsca to both servers
  4. Compare values, debug mismatches
  5. Switch DNS/IP, run old Nagios as read-only
  6. Shut down Nagios

This migrates all passive checks.

Phase 2 — Replace active checks

Active Nagios checks (active_checks_enabled = 1) run from the Nagios server. Move them to collector or agent in Vesana.

Mapping

Nagios plugin Vesana equivalent
check_ping ping (collector)
check_http http (collector)
check_https with cert check ssl_certificate (collector)
check_tcp port (collector)
check_snmp snmp (collector)
check_disk agent_disk (agent) or ssh_disk (collector without agent)
check_load agent_cpu (agent) or ssh_cpu
check_mem agent_memory (agent) or ssh_mem
check_procs agent_process
check_nrpe replace with agent, or agent_custom with local command
check_nt (NSClient++) replace with agent
Custom plugins agent_custom or monitoring script

Gradually

  1. Per host group (e.g. „web servers") check: what's actively monitored?
  2. Pick a pilot host
  3. Install agent → enable matching profile-checks
  4. Disable Nagios active check for this host
  5. Watch status come into Vesana
  6. Expand to next 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 User with email / mobile push token
notification_period Currently no direct match — workaround: alert rule with time filter (on roadmap)
escalation Escalation stages in alert rule
host_dependencies / service_dependencies Dependencies tree with inhibition

Per Nagios notification set: an Vesana alert rule with matching channel + escalation.

Phase 4 — Dashboards & reports

PNP4Nagios → custom dashboards with line-chart widgets. NagVis → no direct equivalent currently — custom dashboard with heatmap + map widget.

Phase 5 — Hostgroups + servicegroups

Nagios hostgroups → Vesana tags + profiles.

Example: - Nagios hostgroup web-servers → tag web on hosts - Nagios servicegroup database → tag database on hosts or profile-check filter

Phase 6 — Custom scripts

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

  • Create the script content as a monitoring script in Vesana (Bash/Python)
  • Expected output nagios (plugin format is exactly compatible)
  • Assign service with check_type = agent_script and script_id

Old plugins now run as server-managed scripts, content centrally in Vesana instead of per machine.

FAQ

Do we need to reconfigure all 18 000 checks?

No. The NSCA strategy takes them 1:1. Only active checks and notifications follow in phases 2 and 3.

What about notification_period?

No direct time window per service yet. Workaround: alert rule with cron filter („only fires Mon–Fri 08–18"). On roadmap. Pragmatic until then.

Can we import data from Nagios?

Status history not directly. What's importable: objects/hosts.cfg (hosts with IPs), objects/services.cfg (service definitions), objects/hostgroups.cfg (tags). Importer script in scripts/nsca_import_nagios.py.

What about notifications via script?

When Nagios calls a custom notification_command script: create a webhook channel in Vesana that calls the script. Adjust payload format with custom template if needed.

Next