Zum Inhalt

NSCA — Nagios-Migration

NSCA (Nagios Service Check Acceptor) ist das alte Protokoll, mit dem send_nsca-Clients passive Check-Results an einen zentralen Server schicken. Vesana kann diese Pakete annehmen — damit existierende Nagios-Installationen ohne Komplett-Neuaufbau zu Vesana wandern.

Konzept

flowchart LR
    NC1[send_nsca] -->|Port 5667| NR[Vesana NSCA-Receiver]
    NC2[send_nsca] -->|Port 5667| NR
    NR --> P[Pipeline: Receiver → Redis → Worker → DB]
    P --> UI[Frontend zeigt Status]

Bestehende Clients zeigen einfach auf den Vesana-Server statt auf den alten Nagios. Keine Code-Änderungen am Client.

Aktivieren

In .env:

NSCA_RECEIVER_ENABLED=true
NSCA_PORT=5667
NSCA_PASSWORD=<shared secret aus alter nsca.cfg>
NSCA_DECRYPTION_METHOD=2     # 0 = none, 1 = XOR, 2 = DES, 14 = AES-128, ...

NSCA_DECRYPTION_METHOD und NSCA_PASSWORD müssen identisch zu den Werten in der alten nsca.cfg sein, sonst werden die eingehenden Pakete als korrupt verworfen.

Stack neu starten:

docker compose -f /opt/vesana/docker-compose.prod.yml up -d

NSCA-Receiver läuft als eigener Service (Go-Daemon) und nimmt UDP/TCP-Pakete auf 5667 an.

Migrationspfad

Vorbereitung

# Auf dem alten Nagios-Server:
grep decryption_method /etc/nsca.cfg
grep ^password        /etc/nsca.cfg
grep server_port      /etc/nsca.cfg
grep host_name        /etc/nagios/objects/hosts.cfg | sort -u

Diese Werte brauchst du für die Vesana-Konfiguration und den Host-Import.

Hosts importieren

In Vesana pro Nagios-Host einen Host anlegen mit:

  • name exakt wie in Nagios host_name (NSCA-Pakete enthalten den host_name als Identifier — wenn der Name nicht matcht, kommt der Status nirgends an)
  • monitoring_mode = nsca
  • Profil: spezifisch oder generisches „NSCA Host"

Importer-Script in scripts/nsca_import_nagios.py parst objects/hosts.cfg und legt entsprechend Hosts an.

Services importieren

Pro Nagios-Service einen Host-Service mit:

  • display_name = service_description aus Nagios
  • check_mode = passive_nsca
  • check_type = nsca_passive

Sobald der erste send_nsca-Aufruf eingeht, sollte Vesana den Host + Service per (host_name, service_description) finden und das Resultat anhängen.

Wenn ein NSCA-Paket eintrifft und der Host/Service nicht gefunden wird: Eintrag im Audit-Log mit unmatched_nsca. Sichtbar in der Discovery-UI als „NSCA-Pakete für unbekannte Hosts/Services" → manuell anlegen oder Auto-Create-Regel.

Auto-Create-Regel

/admin/nsca/auto-create:

  • Auto-Create-Hosts für unbekannte host_name aktivieren (Default: nein, sicherer)
  • Auto-Create-Services analog
  • Default-Profil für Auto-Created Hosts wählen

Sinnvoll wenn die Nagios-Installation laufend wächst und du nicht jede Konfiguration manuell rüber portieren willst.

Parallelbetrieb

Während der Migration kannst du send_nsca so konfigurieren, dass es an mehrere Ziele schickt (Wrapper-Script):

#!/bin/bash
# /usr/local/bin/send_nsca_dual
INPUT=$(cat)
echo "$INPUT" | send_nsca -H old-nagios.example.com -c /etc/send_nsca.cfg
echo "$INPUT" | send_nsca -H vesana.example.com  -c /etc/send_nsca-vesana.cfg

Damit laufen beide Systeme parallel, der Vergleich der Status zeigt eventuelle Mismatches.

Cut-Over

Wenn Vesana alle Pakete sieht und zeigt:

  1. DNS / IP umstellen → send_nsca-Clients schicken nur noch zu Vesana
  2. Alten Nagios-Server für eine Woche im Lese-Modus weiterlaufen lassen (Backup)
  3. Bei Vertrauen: Nagios abschalten

Was an Features mitkommt

Funktioniert sofort

  • Status-Anzeige (OK/WARN/CRIT/UNKNOWN — gleiches Modell wie Nagios)
  • Fehlerübersicht / Problem-Dashboard
  • Alert-Rules + Channels
  • Downtimes, ACK, Audit-Log
  • Multi-Tenant

Funktioniert mit Perfdata-Parsing

Nagios-Plugins liefern perfdata nach |. Vesana parst das automatisch in check_results.perfdata (JSONB) — damit funktionieren Charts und Heatmaps für gauge-Metriken.

Format: label=value[UOM];warn;crit;min;max.

Funktioniert nicht aus NSCA allein

Diese Features brauchen Agent oder Collector:

Feature Grund
Agent Heartbeat / Auto-Update NSCA-Clients sind „dumm" — kein Pull
Service Discovery Agent erkennt Services automatisch
Log Collection Agent sammelt Logs
Aktive SNMP/Ping/SSH/HTTP-Checks Collector
Retry-Intervall (schnellere Fehlererkennung) Server steuert nicht das Polling
Soft/Hard-State-Logik mit Retry Server steuert nicht das Polling

Der schrittweise Upgrade-Pfad: NSCA → Agent (CPU/Memory/Disk lokal) → Collector (SNMP/Ping/HTTP) — Service für Service.

Was du dem Nagios-Admin sagst

„Schreib einfach vesana.example.com als server in deine send_nsca.cfg. Der Rest bleibt gleich."

Der Rest ist auf Vesana-Seite — Hosts und Services anlegen, Migrations-Plan dokumentieren.

Limitierungen

  • Nagios-Plugins selbst migrieren nicht — die laufen weiter auf den Maschinen, nur das Sender-Ziel ändert sich
  • Aktive Nagios-Checks (active_checks_enabled = 1) müssen separat migriert werden (Agent oder Collector)
  • Nagios-Notification-Setup (E-Mail-Templates, Eskalationen) wird nicht automatisch migriert — entsprechende Alert-Rules in Vesana manuell anlegen
  • PNP4Nagios / NagVis haben keine direkte Entsprechung — Custom Dashboards sind die Alternative

Anschluss