Zum Inhalt

Migration von Nagios

Der einfachste Migrationspfad — Vesana kann NSCA-Pakete direkt empfangen, Nagios-Plugins liefern Perfdata kompatibel zu Vesana-Metriken.

Phase 1 — Parallelbetrieb mit NSCA

Detail: NSCA-Empfänger.

Kurzfassung:

  1. NSCA-Empfänger in Vesana aktivieren mit gleichen Decryption-Method + Password wie altes nsca.cfg
  2. Hosts und Services in Vesana anlegen (Importer-Script verfügbar)
  3. send_nsca-Clients via Wrapper-Script auf beide Server schicken
  4. Werte vergleichen, Mismatches debuggen
  5. DNS/IP umstellen, alten Nagios als Read-Only weiterlaufen lassen
  6. Nagios abschalten

Damit hast du alle passiven Checks migriert.

Phase 2 — Aktive Checks ersetzen

Aktive Nagios-Checks (active_checks_enabled = 1) laufen direkt vom Nagios-Server aus. Die müssen in Vesana auf Collector oder Agent umgestellt werden.

Mapping

Nagios-Plugin Vesana-Äquivalent
check_ping ping (Collector)
check_http http (Collector)
check_https mit Cert-Check ssl_certificate (Collector)
check_tcp port (Collector)
check_snmp snmp (Collector)
check_disk agent_disk (Agent) oder ssh_disk (Collector ohne Agent)
check_load agent_cpu (Agent) oder ssh_cpu
check_mem agent_memory (Agent) oder ssh_mem
check_procs agent_process
check_nrpe meistens Agent ersetzen, oder agent_custom mit lokalem Befehl
check_nt (NSClient++) Agent ersetzen
Custom-Plugins agent_custom oder Monitoring-Script

Schrittweise

  1. Pro Host-Gruppe (z. B. „Web-Server") prüfen: was wird aktiv geprüft?
  2. Ein Pilot-Host auswählen
  3. Agent installieren → entsprechende Profile-Checks aktivieren
  4. Nagios-Aktiv-Check für diesen Host deaktivieren
  5. Beobachten, dass Status in Vesana kommt
  6. Auf nächste Host-Gruppe ausweiten

Phase 3 — Notifications nachbauen

Nagios-Notifications (E-Mail, SMS, Eskalation) sind in contacts.cfg und services.cfg konfiguriert. In Vesana:

Nagios-Konzept Vesana-Äquivalent
contact mit email / pager User mit E-Mail / Mobile-Push-Token
notification_period Aktuell nicht direkt umsetzbar — Workaround: Alert-Rule mit Time-Filter (kommt in Roadmap)
escalation Eskalations-Stufen in Alert-Rule
host_dependencies / service_dependencies Dependencies-Tree mit Inhibition

Pro Notification-Set in Nagios: eine Alert-Rule in Vesana mit passendem Channel + Eskalation.

Phase 4 — Dashboards & Reports

PNP4Nagios → Custom Dashboards mit Line-Chart-Widgets. NagVis → momentan keine direkte Entsprechung — Custom Dashboard mit Heatmap + Map-Widget.

Phase 5 — Hostgroups + Servicegroups

Nagios-Hostgroups → Vesana-Tags + Profile.

Beispiel: - Nagios-Hostgroup web-servers → Tag web auf Hosts - Nagios-Servicegroup database → Tag database auf Hosts oder Profile-Check-Filter

Phase 6 — Custom Scripts

Wenn Nagios eigene Plugins genutzt hat (/usr/local/nagios/libexec/check_*):

  • Skript-Inhalt in Vesana als Monitoring-Script anlegen (Bash/Python)
  • Expected-Output nagios (Plugin-Format ist genau kompatibel)
  • Service mit check_type = agent_script und script_id zuweisen

Damit laufen die alten Plugins als Server-managed Scripts weiter, der Inhalt liegt zentral in Vesana statt verteilt auf jeder Maschine.

Häufige Fragen

Müssen wir alle 18 000 Checks neu konfigurieren?

Nein. Die NSCA-Strategie übernimmt sie 1:1. Nur aktive Checks und Notifications werden in Phase 2 und 3 nachgezogen.

Was ist mit notification_period?

Aktuell kein direktes Time-Window pro Service. Workaround: Alert-Rule mit Cron-Filter („feuert nur Mo–Fr 08–18"). Kommt in Roadmap. Bis dahin pragmatisch lösen.

Können wir Daten aus Nagios importieren?

Status-Historie nicht direkt. Was importierbar ist: objects/hosts.cfg (Hosts mit IPs), objects/services.cfg (Service-Definitionen), objects/hostgroups.cfg (Tags). Importer-Script in scripts/nsca_import_nagios.py.

Was machen wir mit Notifications-via-Skript?

Wenn Nagios per notification_command ein eigenes Skript ruft: in Vesana einen Webhook-Channel anlegen, der das Skript aufruft. Payload-Format ggf. mit Custom-Template anpassen.

Anschluss