Nagios Production Monitoring: Setup, Konfiguration und Best Practices

Linux, DevOps und KI: Warum Grundlagen im Jahr 2026 wichtiger sind als je zuvor

Im Eifer, KI und cloud-native Tools zu adoptieren, werden oft die Grundlagen vernachlässigt. Dieser Artikel erklärt, warum die Beherrschung der Linux-Kommandozeile, Container-Grundlagen und Basiswissen über Infrastruktur das Fundament für jeden modernen DevOps- und KI-Workload bilden. KI generiert Code – sie ersetzt nicht das Verständnis.

Warum Nagios

Nagios Core bleibt eines der am weitesten verbreiteten Monitoring-Frameworks in Produktionsumgebungen. Seine Plugin-Architektur, die Unterstützung für passive Checks und die Möglichkeiten für verteiltes Monitoring machen es zu einer soliden Wahl für Organisationen, die die volle Kontrolle über ihren Monitoring-Stack benötigen, ohne sich an einen bestimmten Anbieter zu binden (Vendor Lock-in).

Kernkomponenten

Ein typisches Nagios-Deployment besteht aus:

• Nagios Core — die Monitoring-Engine, die Checks plant, Ergebnisse verarbeitet und Alarme auslöst
• NRPE (Nagios Remote Plugin Executor) — führt Checks auf Remote-Hosts aus und gibt die Ergebnisse zurück
• NSCA (Nagios Service Check Acceptor) — empfängt Ergebnisse von passiven Checks von Remote-Systemen
• Check-Plugins — die eigentlichen Skripte, die die Prüfungen durchführen (Disk, CPU, Load, Prozesse, benutzerdefiniert)

Basis-Server-Setup

Installieren Sie Nagios Core und die Standard-Plugins:

apt install nagios4 nagios-plugins-contrib nagios-nrpe-plugin

Die Hauptkonfiguration befindet sich in /etc/nagios4/:

Hinzufügen von Hosts und Services

Definieren Sie jeden zu überwachenden Server in conf.d/hosts.cfg:

define host {
    use             linux-server
    host_name       web-01
    alias           Production Web Server
    address         10.0.1.10
    check_command   check-host-alive
    max_check_attempts 3
    notification_interval 120
}

Definieren Sie in conf.d/services.cfg, welche Services auf diesem Host geprüft werden sollen:

define service {
    use                 generic-service
    host_name           web-01
    service_description HTTP Response
    check_command       check_http!-H 10.0.1.10 -u /health -w 3 -c 5
    check_interval      5
    retry_interval      1
}

Alarm-Konfiguration

Nagios versendet Benachrichtigungen über die Befehle notify-host-by-email und notify-service-by-email. Konfigurieren Sie die Empfänger in contacts.cfg:

define contact {
    contact_name            ops-team
    alias                   Operations Team
    email                   ops@example.com
    service_notification_commands notify-service-by-email
    host_notification_commands    notify-host-by-email
}

Für die Slack-Integration ersetzen Sie den Benachrichtigungsbefehl durch einen Webhook-POST:

#!/bin/bash
WEBHOOK_URL="https://hooks.slack.com/services/YOUR/WEBHOOK"
MESSAGE="Nagios: $NOTIFICATIONTYPE - $HOSTALIAS/$SERVICEDESC is $SERVICESTATE"
curl -s -X POST -H 'Content-type: application/json' \
  --data "{\"text\":\"$MESSAGE\"}" "$WEBHOOK_URL"

Verteiltes Monitoring mit NSCA

Verwenden Sie für große Umgebungen ein verteiltes Setup: Satelliten-Nagios-Instanzen führen lokale Checks durch und leiten die Ergebnisse via NSCA an einen zentralen Server weiter.

Auf dem zentralen Server (Receiver):

apt install nsca
# configure /etc/nsca.cfg with server_address and password

Auf jedem Remote-Satelliten:

# After local check completes, send result to central
/usr/bin/send_nsca -H central.example.com -c /etc/send_nsca.cfg <<EOF
web-01\tHTTP Response\t0\tHTTP OK - 0.142s response
EOF

Best Practices

• Check-Intervalle: Verwenden Sie 5-Minuten-Intervalle für Standard-Checks und 1-Minute für kritische Services. Vermeiden Sie Intervalle unter einer Minute, sofern dies nicht absolut notwendig ist.
• Max Check Attempts: Setzen Sie diesen Wert auf mindestens 3, um zu verhindern, dass "Flapping" (ständiges Wechseln des Status) Alarme auslöst.
• Abhängigkeiten: Definieren Sie Service-Abhängigkeiten, damit nachgelagerte Ausfälle nicht kaskadieren (z. B. wenn eine Datenbank down ist, soll kein Alarm für die darauf angewiesene App ausgelöst werden).
• Passive Checks: Bevorzugen Sie passive Checks für Services, deren Abfrage ressourcenintensiv ist (Log-Analyse, komplexer Application Health Check).
• Konfigurationsmanagement: Speichern Sie Nagios-Konfigurationen in Git und deployen Sie diese mit Ansible oder einem ähnlichen Tool.
• Log-Rotation: Überwachen Sie die Größe der Nagios-Logs; Spool-Dateien können in großen Deployments schnell anwachsen.