Zum Inhalt

Migration von Nagios

Vesana nimmt keine Ergebnisse von Nagios entgegen (keine passiv eingeschickten Ergebnisse, kein Import von Konfigurationsdateien). Der Weg ist ein Parallelbetrieb: Vesana prüft dieselben Geräte selbst, du vergleichst, und schaltest Nagios danach Gruppe für Gruppe ab. Eigene Nagios-Plugins laufen in Vesana als Monitoring-Script weiter — das Plugin-Format (Exit-Code + Perfdata) versteht Vesana direkt.

Phase 1 — Geräte in Vesana anlegen

Die Liste der Hosts mit IPs steht in deinen Objekt-Dateien (hosts.cfg). In Vesana legst du sie über den Host-Assistenten an oder findest sie per Discovery und übernimmst sie von dort. Die passenden Geräteprofile bringen die üblichen Checks gleich mit.

Phase 2 — Checks ersetzen

Aktive Nagios-Checks laufen vom Nagios-Server aus. In Vesana übernimmt das ein Collector im selben Netz, der Active-Checker auf dem Vesana-Server oder der Agent auf der Maschine selbst.

Mapping

Nagios-Plugin Vesana-Check-Typ
check_ping ping
check_http http (Status, Inhalt, Antwortzeit) bzw. http_json für APIs
check_http mit Zertifikatsprüfung ssl_certificate
check_tcp port
check_snmp snmp / snmp_oid / snmp_string
check_disk agent_disk (Agent, alle Partitionen automatisch) oder ssh_disk (ohne Agent)
check_load agent_cpu (Agent) oder ssh_cpu
check_mem agent_memory (Agent) oder ssh_mem
check_procs agent_process (Agent) oder ssh_process
check_nrpe meistens durch den Agent ersetzen, oder agent_custom mit lokalem Befehl
check_nt (NSClient++) Agent
eigene Plugins Monitoring-Script (agent_script bzw. ssh_script), siehe Phase 6

Alle Typen: Check-Typen-Referenz.

Schrittweise

  1. Pro Host-Gruppe (z. B. „Web-Server") prüfen: was wird heute geprüft?
  2. Einen Pilot-Host auswählen
  3. Agent installieren bzw. Collector zuweisen → passende Profil-Checks aktivieren
  4. Einige Tage parallel laufen lassen, Werte vergleichen
  5. Nagios-Checks für diesen Host abschalten
  6. Auf die 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 Benachrichtigungs-Kanal (E-Mail, Push aufs Handy, Telegram, Slack, Teams, Webhook, …)
notification_period kein Zeitfenster an der Alert-Regel; wiederkehrende Downtimes unterdrücken Meldungen außerhalb der gewünschten Zeiten
escalation Eskalations-Stufen in der Alert-Regel
host_dependencies / service_dependencies Abhängigkeiten mit Inhibition

Pro Notification-Set in Nagios: eine Alert-Regel in Vesana mit passenden Kanälen und Eskalation.

Phase 4 — Dashboards & Karten

PNP4Nagios → Dashboards mit Liniendiagramm-Widgets oder der Check-Verlauf am Host. NagVis → die Karten (logisch/physisch) plus ein Dashboard mit Status-Übersicht oder Heatmap.

Phase 5 — Hostgroups + Servicegroups

Nagios-Hostgroups → Ordner, Tags und Profile in Vesana.

Beispiel: - Nagios-Hostgroup web-servers → Ordner oder Tag web auf den Hosts - Nagios-Servicegroup database → Tag database auf den Hosts oder ein eigenes Profil

Phase 6 — Eigene Plugins

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

  • Script-Inhalt in Vesana als Monitoring-Script anlegen (Bash/Python/PowerShell)
  • Ausgabeformat nagios — Exit-Code, Meldung und Perfdata werden wie in Nagios ausgewertet
  • Check mit Typ agent_script (läuft auf dem Agent) oder ssh_script (läuft per SSH) und dem Script anlegen
  • Standard-Plugins aus monitoring-plugins auf dem Vesana-Server laufen als Check-Typ plugin_local über den Active-Checker — nur aus dessen Plugin-Verzeichnissen (u. a. /usr/lib/nagios/plugins); für Tenants braucht das die Freigabe „Eigene Plugins auf dem Server" unter Admin → Agents & Collectors → Active-Checker
  • Werte, die je Gerät anders sind (Pfade, Namen), als einstellbare Werte am Script deklarieren statt das Script zu kopieren — siehe Einstellbare Werte

Damit liegt der Plugin-Inhalt zentral in Vesana statt verteilt auf jeder Maschine.

Häufige Fragen

Müssen wir alle Checks neu konfigurieren?

Ja, in Vesana selbst — eine Übernahme der Nagios-Konfiguration gibt es nicht. Die Geräteprofile nehmen dabei den Großteil ab: ein Profil legt die üblichen Checks eines Gerätetyps auf einmal an.

Was ist mit notification_period?

Ein Zeitfenster pro Alert-Regel gibt es nicht. Meldungen außerhalb bestimmter Zeiten unterdrückst du mit einer wiederkehrenden Downtime.

Können wir Daten aus Nagios importieren?

Nein, weder Konfiguration noch Status-Historie. Den alten Nagios eine Weile lesend weiterlaufen lassen, bis Vesana genug eigenen Verlauf hat.

Was machen wir mit Notifications-via-Skript?

Wenn Nagios per notification_command ein eigenes Skript ruft: in Vesana einen Webhook-Kanal anlegen, der einen Endpunkt deines Skripts aufruft.

Anschluss