Nagios für unterschiedliche Betriebssysteme zu kompilieren scheint kein Problem mehr zu sein, solange keine string-Funktion fehlt...

Falls also ein Probleme mit der strncat(), strncpy(), oder snprintf()-Funktion auftaucht, ist höchstwahrscheinlich t die falsche glibc-Bibliothek auf Ihrem System installiert. Dies scheint meistens auf HP-UX und Solaris Maschinen zu passieren. Ich habe mit diesen Funktionen versucht potentielle Buffer-Overflows in Nagios und den CGIs zu verhindern, deshalb sind sie überall im Code verstreut. Falls Sie aus irgendeinem Grund nicht die glibc-Bibliothek installieren wollen, müssen Sie leider selbst einen Weg finden um alles zu kompilieren.

Falls Ihnen nur die snprintf()-Funktion fehlt, können Sie versuchen die snprintf.c Datei von http://www.ijs.si/software/snprintf/ herunterzuladen und in das Makefile hinzuzufügen, so dass es während dem Kompilieren hinzugefügt wird. Einige Leute haben erwähnt, dass diese Version von snprintf allerdings nicht das '%f' Formatierungs-Flag unterstützt, vielleicht haben Sie mehr Glück. Sorry...

Wenn Sie alle CGIs kompilieren, aber das Statuskarten-CGI, Trends-CGI oder Histogram-CGI nicht finden (oder diese nicht zum Laufen bekommen), haben Sie evtl. folgende Bibliotheken nicht richtig auf ihrem System installiert:

• Thomas Boutell's gd-Bibliothek (Version 1.6.3 oder neuer wird benötigt)
• Zlib (de)Kompressions-Bibliothek
• PNG Entwicklungs-Bibliothek

Die gd-Bibliothek basiert auf der zlib und png Bibliothek (und ein paar anderen), deswegen benötigen Sie diese beiden Bibliotheken auf Ihrem System, bevor Sie die gd-Bibliothek installieren. Neuere Versionen der gd-Bibliothek benötigt ausserdem die jpeg-Bibliothek auf Ihrem System.

Falls bei Ihnen die CGIs nicht kompiliert wurden oder nicht richtig arbeiten, vergewissern Sie sich, dass Sie die gd-, png-, zlib- und jede andere benötigte Bibliothek installiert haben. Anschliessend sollten Sie die alten Nagios-Kompilierungs-Konfiguration löschen und das "configure"-Skript erneut mit den folgenden zwei Befehlen (in dem Verzeichnis Ihres Nagios-Quelltextes) laufen lassen:

make devclean
./configure --with-gd-lib=LIBDIR --with-gd-inc=INCDIR [andere Optionen]

Ersetzen Sie LIBDIR mit dem Verzeichnis, in dem Sie die gd-Bibliothek installiert haben (normalerweise /usr/lib oder /usr/local/lib) und ersetzen Sie INCDIR mit dem Verzeichnis, in dem die Header-Dateien der gd-Bibliothek installiert wurden (normalerweise /usr/include oder /usr/local/include).

Nachdem Sie das "configure"-Skript neu gestartet haben, sollten Sie in der Lage sein die CGIs richtig zu kompilieren und an die richtige Stelle zu installieren.

Falls Sie RedHat Linux benutzen und Probleme haben, empfehle ich Ihnen die gd- und gd-devel-RPMs von www.rpmfind.net herunterzuladen und zu installieren. Beachten SIe auch, dass andere Applikationen (PHP, MRTG, etc.) auch auf der gd-Bibliothek basieren und bei einem update der gd-Bibliothek Probleme machen könnten und evtl. auch erneut kompiliert werden müssen.

Der häufigste Grund für dieses Problem ist, dass Sie keine 2-D oder 3-D Koordinaten für die Hosts angegeben haben. Obwohl das Statuskarten-CGI auch autmatisch ein Layout erzeugen kann, versucht es standardmässig die von Ihnen angegebenen Koordinaten zu verwenden. Das 3-D-Statuskarten-CGI (VRML) wird nicht funktionieren, wenn Sie keine 3-D Koordinaten angeben.

Wie können Sie diese Koordinaten für Hosts angeben?
Benutzen Sie die erweiterten Informationen.

Falls Sie die Installation-Dokumentation nicht richtig gelesen haben und den großen Hinweis auf der Download-Seite nicht gesehen haben, werden Sie sich wundern, wo all die Plugins sind. Schnelle und einfache Antwort - Sie sind getrennt von der Nagios-Kernapplikation erhältlich, so dass Sie diese von der Downloads-Seite oder direkt von der SourceForge Projektseite herunterladen und installieren müssen.

Einfache Antwort. Sie haben die notify_unreachable-Option in der Host-Definition(en) aktiviert. Falls Sie nicht benachrichtig werden wollen, wenn ein Host unerreichbar ist, müssen Sie diese Option in der Host-Definition nur deaktivieren.

Ich bekomme viele eMails, in denen gefragt wird, warum Nagios nicht intelligent genug ist um Benachrichtigungen für unerreichbare Hosts zu unterdrücken. Allerdings ist Nagios intelligent genug um zwischen einem Host mit DOWN und UNREACHABLE Status zu unterscheiden - Sie müssen nur Ihre Benachrichtigungs-Optionen richtig konfigurieren...

Dies scheint das größte Thema für neue Anwender zu sein. In 99.9% aller Fälle ist dieses Problem eine Folge von inkorrekten Befehls-Definitionen der Überprüfungs-Befehle, die für diese Hosts benutzt werden.

Ein Hauptgrund für dieses Problem, war die änderung in der Syntax der Kommandozeilen-Argumente des check_ping-Plugins. Gehen Sie sicher, dass der Befehl zur Host-Überprüfung die korrekte Syntax verwendet. Um zu testen, ob der Befehl richtig funktioniert, können Sie diesen Befehl auch per Hand in der Kommandozeile ausführen. Die neue Version des check_ping-Plugin benötigen das -p-Flag um die Anzahl der Packete anzugeben. Das Problem liegt darin, dass bisherige Versionen des Plugins dies nicht taten. Überprüfen Sie die Version des verwendeten Plugins um die richtige Syntax für den Host-Überprüfungs-Befehl herauszufinden.

Wichtig! Nur weil Sie einen Dienst definiert haben, der per Ping die Netzwerk-Erreichbarkeit für einen Host überprüft, heisst das nicht, dass der aktuelle Host-Status überprüft wird. Der Status eines Hosts wird nur überprüft, wenn das Ergebnis einer Dienst-Überprüfung mit einem nicht-OK-Status endet oder der Host vorher down und das Ergebnis der Dienst-Überprüfung ok war.

Einige Symtome für inkorrekte Überprüfungs-Befehle:

1. Hosts die inkorrekt als DOWN aufgelistet werden
2. Hosts die inkorrekt als UNREACHABLE aufgelistet werden
3. Abwechselnde Alarmierungen/Benachrichtigungen über Host-Probleme und -Erholungen

Einige Leute haben von Problemen berichtet, mit dem ich Stunden verbracht habe, um es zu lösen und letztendlich herauszufinden, dass es kein Fehler im Code von Nagios ist. Falls Sie Benachrichtigungen über Dienste erhalten, aber eigentlich Host-Benachrichtigungen erhalten sollten (und die Dienst-Benachrichtigungen die Sie erhalten falsche Daten enthalten), sollten Sie Ihre Kontakt-Definitionen in der Objekt-Konfigurationsdatei(en) überprüfen. Meistens sind diese falsch.

Gehen Sie sicher, das Sie nicht die selben Benachrichtigungs-Befehle für Dienst- und Host-Benachrichtigungen verwenden. Dienst- und Host-Benachrichtigungen sind sehr unterschiedlich und benutzen Macros welche nicht zwischen den beiden Typen getauscht werden können. Schauen Sie in die Beispiel-Host-Konfigurationdatei, die mit Nagios mitgeliefert wird, um zu sehen, wie Sie Kontakte richtig definieren und wie sich die Dienst- und Host- Benachrichtigungs-Befehle voneinander unterscheiden. Falls Sie sich wundern welche Macros für welchen Typ der Benachrichtigung benutzt werden können, schauen Sie einfach in diese Tabelle.

Nein, nicht wirklich. Obwohl Sie einen Host definieren können ohne ihm einen Dienst zuzuordnen, werden Sie keine Ergebnisse bekommen, wie Sie es erwarten. Sie müssen mindestens einen Dienst für jeden Host, den Sie überwachen wollen, definieren. Nagios ist primär auf die Überwachung von Diensten ausgerichtet. Hosts werden nur überprüft, wenn es Probleme mit oder Wiederherstellungen von Diensten (wie in der "Dienst-Überprüfungs-Plan"-Dokumentation beschrieben) gibt.

Nein. Sie müssen Nagios jedes Mal neu starten, wenn Sie einen Host oder Dienst (oder jede andere Art von Objekt-Definition in der Objekt-Konfigurationdatei) hinzufügen.

Wichtig: Wenn Sie Konfigurationsänderungen durchführen, ohne Nagios neu zu starten, werden Sie Unregelmässigkeiten inden CGIs bemerken. Einige Hosts können erscheinen, andere Dienste können verschwinden, usw. Dies heißt nicht, das Nagios mit der Überwachung der einstigen Dienste aufgehört, oder der neuen Hosts angefangen hat. Dies ist nur eine Nebenwirkung der Authorisierungs-Logik in den CGIs.

Erstens müssen Sie erkennen, wo Timeouts auftauchen. Die meisten Plugins haben einen Timeout von 10 Sekunden, um einen Dienst zu kontaktieren (FTP, HTTP, usw.). Wenn die Plugins nach einer kurzen Zeit timeouten, können Sie die Timeout-Werte für das Plugin erhöhen (indem Sie z.B. ein entsprechendes Kommandozeilen-Argument benutzen).

Außerdem übergibt Nagios seine eigenen Timeout-Werte für alle Dienst-Überprüfungen, die gerade laufen. Dieser Wert ist standardmässig auf 30 Sekunden gesetzt. Wenn das Plugin länger als 30 Sekunden läuft, wird Nagios es automatisch beenden und einen kritischen Fehler für diesen Dienst melden. Wenn Sie Einträge im Logfile sehen, die besagen, dass Dienst-Überprüfungen einen Timeout hatten, ist das vielleicht ein Problem in diesen Plugins. Sie können die Timeout-Werte für Dienst-Überprüfungen erhöhen. indem Sie die service_check_timeout-Direktive benutzen.

Als Nebenbemerkung, sollte ausserdem die Direktiven für das Setzen des Timeout-Wertes für Host-Überprüfungen, Benachrichtigungen, Event-Handler und des OCSP Kommandos erwähnt werden.

Wenn der Output eines Plugins für eine Host- oder Dienst-Überprüfung einen "(Return code of x is out of bounds)"-Fehler ausgibt, bedeutet dies normalerweise zwei Dinge:

1. Das Plugin, dass Sie für die Überprüfung des Diensts oder des Hosts benutzen, gibt keinen korrekten Rückgabewert zurück, wenn es sich beendet
   
   
2. Der Pfad zu dem Plugin ist ungültig (z.B. existiert das Programm oder Skript nicht). Dies ist meistens der Fall, wenn einen Fehler mit dem Rückgabewert 127 vorliegt. Falls Sie diesen Fehler bekommen, müssen Sie Ihre Befehls-Definition überprüfen und sicherstellen, dass der Pfad zu den Plugins korrekt ist (und das Sie wirklich auf Ihrem System an dieser Stelle installiert sind).

Wenn Sie eine Nachricht wie "mail: Null names are not allowed", "You must specify direct recipients with -s, -c, or -b.", oder etwas ähnliches bekommen, haben Sie vielleicht einen Fehler in der Definition des Benachrichtigungs-Befehls.

Stellen Sie sicher, dass die Syntax, die Sie benutzen um /bin/mail (oder wo/wie Ihr Mail-Programm seien sollte) aufzurufen, in der Definition des Benachrichtigungs-Befehl für Ihr System korrekt ist.

Wenn Nagios läuft oder Sie mit dem -v Argument Ihre Konfigurationsdatei überprüfen lassen, meldet Nagios unter Umständen eine Nachricht wie "Error in configuration file 'xxxxxxx.cfg' - Line 34 (Unknown variable)". Einige simple Überprüfungen sollten dieses Problem normalerweise beheben...

1. Stelln Sie sicher, dass Sie den Pfad zu Ihrer Haupt-Konfigurationsdatei in der Kommandozeile mit übergeben. Die richtige Syntax sollte ähnlich wie der folgende Befehl (evtl. natürlich etwas für Ihr System verändert):
   /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
   
   
2. Stellen Sie sicher, dass Sie keine ungültige Variable in Ihrer Konfigurationsdatei angegeben haben. Beachten Sie dass die Fehlermeldung eine Referenz zu dem Namen der Konfigurationsdatei und der Zeile in der der Fehler auftritt, enthält. Stellen Sie sicher, dass alle Kommentarzeilen in Ihren Konfigurationsdateien ein Doppelkreuz-Zeichen (#) an der ersten Stelle der Zeile enthalten. Wenn Sie sich nicht sicher sind, welche Variablen gültig und welche ungültig sind, schauen Sie einfach in die Dokumentation für die Haupt- und Objekt-Konfigurationdatei.
   
   
3. Stellen Sie sicher, dass alle Variablen in kleinen Buchstaben angegeben sind.
   Beispiel:
   "admin_email=someaddress@somedomain.com" anstelle von "ADMIN_EMAIL=somedomain@nowhere.com"

Sie können multiple Instanzen von Nagios auf der gleichen Maschine betreiben, wenn Sie sicherstellen, dass die folgenden Variablen für jede Instanz von Nagios dediziert angegeben sind...

• Haupt-Konfigurationsdatei
• temporäre Datei
• Status-Datei
• externe Kommandodatei
• Log-Datei
• Log-Archiv Pfad
• Lock-Datei

Wenn Sie das Web-Interface benuten, müssen Sie für jede Instanz von Nagios seperate CGI-Verzeichnisse und entsprechende Skript-Aliase in Ihrer Konfigurationsdatei Ihres Webservers. Dies ist nötig, da die CGI-Konfigurationsdatei für jedes CGI-Setup einzigartig sein muss, da es eine Referenz zu der Haupt-Konfigurationsdatei, die von den CGIs gelesen werden muss, enthält.

Als letztes sollten Sie Ihr Init-Skript (falls Sie eines benutzen) überprüfen. Das Init-Skript sollte alle Instanzen von Nagios starten, stopen, restarten, und reloaden natürlich nur falls Sie dieses so wollen).

Falls Sie glauben, dass Sie nicht alle Informationen in den CGIs sehen, die sie sehen sollten, oder wenn Sie Authorisierungs-Fehler bekommen, haben Sie evtl. den Webserver nicht richtig für die Authentifizierung konfiguriert. Lesen Sie die Dokumentation für die CGI-Authentifizierung und -Authentisierung hier.

Die traceroute- und daemonchk-CGIs sind nun in dem contrib/-Unterverzeichnis der Nagios-Distribution.

Lesen Sie die Dokumentation für die CGI-Authentifizierung und -Authentisierung hier.

Falls Sie für die Status-, Statuskarten-, Status-Welt-CGIs und dem CGI für erweiterte Informationen, einzelne Hosts mit Bildern verknüpfen wollen, müssen Sie erweiterte Host-Informationen definieren.

Falls Sie einen 'Could not open command file irgendeinedatei for update'-Fehler bekommen, wenn Sie Kommandos an Nagios über das Befehls-CGI übermitteln, ist es meistens ein Problem mit den Verzeichnis- und/oder Datei-Rechten. So können Sie es beheben...

1. Stellen Sie sicher, dass Sie ein Verzeichnis für die Befehlsdatei - wie hier beschrieben - angelegt haben.
   
   
2. Stellen Sie sicher, dass Sie Ihren Webserver neu gestartet haben, so dass es die neuen Gruppenrechte, die Sie vergeben, erkennt.

Wenn sich Nagios selbst beendet, nach dem es externe Befehle ausgeführt hat, und Sie Warnungen im Logfile über falsche Zugriffsrecht auf die Befehlsdatei lesen, müssen Sie diese Beschreibung befolgen.

Einige User haben danach gefragt, wie man diverse Plugins benutzt, um Informationen zu überprüfen, die auf entfernten Hosts liegen. Dies kann man auf unterschiedlichen Weisen tun:

Wenn Sie für jede Überprüfung auf dem entfernten Host ein Plugin ausführen müssen um ein Ergebnis zu bekommen, können Sie eines der folgenden Methoden nutzen:

• Benutzen Sie das check_by_ssh-"Plugin" um ein Plugin auf einem entfernten Hose auszuführen. Das check_by_ssh-Plugin ist eigentlich ein Wrapper um ein Plugin auf einem anderen Host mit dem SSH-Kommando auszuführen. Sie müssen SSH richtig installiert und konfiguriert haben, um dieses zu benutzen.
• Sie können auch das nrpe-Addon benutzen, um dies zu tun. Die Plugins und der nrpe-Daemon liegen auf dem entfernten Host. Das check_nrpe-Plugin (im nrpe-Packet enthalten) sendet eine Anfrage an den nrpe-Daemon um ein Plugin auf dem entfernten Host auszuführen und die Ergebnisse für Nagios zu sammeln.
• Nutzen sie das nrpep-Addon. Dieses Addon arbeitet in der gleichen Art wie das nrpe-Packet, allerdings verschlüsselt es die übermittelten Daten und läuft als Dienst unter einem Super- Daemon (z.B. tcpserver, xinetd oder inetd), um von dessen Zugriffsschutzmöglichkeiten gebrauch zu machen.
• Mann kann auch rsh benutzen, um ein entferntes Plugin auszuführen.
  Diese Möglichkeit ist aber aufgrund der schlechten Sicherheit nicht zu empfehlen...

Falls Sie nur den Festplatten-Platz auf einem entfernten Host überprüfen müssen, können Sie die folgenden Methoden benutzen:

• Nutzen Sie eines der Plugins, dass in dem nagios_statd-Addon für Nagios enthalten ist. Das Addon, geschrieben von Charlie Cook, enthält einen Perl-Daemon der auf dem entfernten Host läuft und vier Plugins, die auf dem entfernten Host die Informationen sammeln.
  Der Daemon kann auf Linux-, IRIX-, HP-UX-, SunOS- and OSF/1-Systemen laufen. Es sollte kein Problem sein den Code für andere Systeme zu weiter zu verändern.
  Weitere Informationen über das nagios_statd-Plugin finden Sie hier.
• Nutzen Sie das check_overcr-Plugin um Informationen von einen entfernten Host anzufragen. Auf dem entfernten Host muss Eric Molitor's Over-CR-Datensammler laufen, um diese Methode zu nutzen.
• Nutzen Sie das check_snmp-Plugin um die Werte von verschiedenen OIDs auf einem entfernten Host abzufragen. Sie müssen dafür einen SNMP-Dienst auf dem entfernten Host installiert und am Laufen haben, um dies zu tun.

Ja, obwohl Nagios selbst nicht auf einem NT-Server läuft, können Sie durchaus NT-Server von Nagios aus überwachen. Sie können dies auf zwei verschiedenen Wegen tun:

• Sie benutzen SNMP
• Sie benutzen das NSSERVICER-Addon (Dienst und Plugins)

SNMP

Die gute Nachricht ist, dass NT sehr viele Performance-Daten zur Überwachung zur Verfügung stellt. Die schlechte Nachricht ist, dass dies recht schwer einzurichten ist. Das Beste wird aber trotzdem sein, wenn man den SNMP-Dienst auf allen seinen NT-Servern installiert.

Um Windows NT/2000 dazu zu bewegen Performance-Daten zur Überwachung zur Verfügung zu stellen, müssen Sie den SNMP-Dienst auf allen Servern, die Sie überwachen müssen laufen lassen. Sie müssen evtl. auch alle nötigen Performance-MIBs für den Dienst installieren, den Sie überwachen wollen. Ich glaube, dass Sie diese im "NT Ressource Kit" finden, dass in vielen "Server Administrations"-Packeten enthalten ist.
Falls Sie aber richtig gut drauf sind, können Sie auch auf Microsofts Webseite nach den Begriffen SNMP und MIB durchsuchen und evtl. etwas brauchbares finden...

Sie können das MRTG Mailinglisten-Archiv durchsuchen, um mehr Informationen zu erhalten, wie man NT-Server konfiguriert um Performance-Daten via SNMP preiszugeben. Ich weiß, dass es bereits in der Vergangenheit diskutiert wurde, wie viele Leute MRTG nutzen, um NT-Performance-Daten grafisch für Statistiken aufzubereiten.
Sogar bei Microsoft tut das derzeit jemand, sie können die Webseite unter http://snmpboy.rte.microsoft.com/ erreichen.

Wenn Sie einmal den ganzen SNMP-Kram am laufen haben, können Sie das check_snmp-Plugin benutzen, um die Daten und generelle Warnungen von den NT-Servern abzufragen.

NSSERVICER Addon

Jan Christian Kaldestad und Hallstein Lohne haben das nsservicer-Addon geschrieben, um NT-Server zu überwachen. Das Addon enthält einen Dienst, der auf Ihren NT-Servern läuft und einige Plugins, die vom Nagios-Server aus laufen. Das nsservicer-Addon kann das Event-Log, Festplatten-Ausnutzung, Prozess-Werte und andere Informationen auswerten.

Sie können das Addon in dem "contrib"-Bereich der Download-Seite finden.

Sie können grundlegende Daten, wie die Festplatten-Ausnutzen, User-Verbindungen, "LRU sitting time", Cache Buffer, Langzeit Cache Hits und Prozessor-Last Ihrer Novell-Server mit dem check_nwstat-Plugin (dieses ist in der Plugin-Distribution enthalten) überwachen.
Um das Plugin benutzen zu können, müssen Sie James Drew's MRTGEXT NLM auf Ihrem Novell-Server installiert und laufen haben. NLM können Sie hier finden.

Nagios kann SNMP-Traps versenden, allerdings nicht direkt. Nagios basiert auf dem Konzept, das Plugins die Daten über Hosts und Dienste sammeln und Event-Handler-Skripte eine Reaktion auf die Events auslösen.
Falls Nagios also SNMP-Traps an Management-Hosts senden sollen, wenn ein bestimmter Service ein Problem hat, müssen Sie hierfür ein Event Handler-Skript schreiben und dieses in der event_handler-Option in der Dienst-Definition eintragen. Falls Sie das UCD-SNMP-Packet auf Ihrem Server installiert haben, können Sie über das Skript den snmptrap-Befehl aufrufen, um eine Trap-Nachricht zu versenden, je nachdem was mit einem Dienst passiert. Schauen Sie sich das Beispiels Event Handler-Skript an um einen Überblick zu bekommen, wie man solch ein Skript am besten schreibt.

Nagios kann auch SNMP-Traps empfangen, allerdings nicht direkt. Nagios wurde nicht als Ersatz für ein voll ausgebautes SNMP Management-System entworfen, aber Sie können Nagios so konfigurieren, dass Warnungen aufgrund von SNMP-Traps, die von irgendeinem Host im Netzwerk empfangen werden, ausgelöst werden.
Wenn Sie das UCD-SNMP (heißt jetzt NET-SNMP)-Paket auf Ihrem System installiert haben, können Sie den snmptrapd-Daemon so einstellen, dass er SNMP-Traps an Nagios weiterleitet, indem man passive Überwachungen benutzt.
Weitere Informationen zu diesem Thema finden Sie hier.

Nein, funktioniert nicht direkt, aber dieses kann relativ einfach eingerichtet werden. Sie können z.B. einen globalen Host- und Dienst-Event Handler anlegen, um dies zu tun. Dieser globale Event Handler kann z.B. ein Skript aufrufen, welches die entsprechenden Event-Informationen in eine Datenbank Ihrer Wahl einfügt.
Dies erlaubt Ihnen dann Datenbank-Abfragen zu stellen um noch detailliertere Reports als durch die CGIs zu erhalten.

Ich habe einige Jahre für Tech-Support und einige Zeit am Helpdesk gearbeitet. Die meisten Leute die einen Fehler melden, haben leider nur eine sehr vage Vorstellung wie Sie ein Problem herausfinden können, wollen aber das es sofort behoben wird. Ich hoffe, dass Sie nicht so eine Person sind...
Nagios ist relativ neu und ist eventuell voll mit Fehlern, deshalb wird nicht alles sofort und immer problemlos laufen. Falls Sie vermuten, dass entweder eine Dienst-Überprüfung oder eine Benachrichtigungs-Routine nicht richtig funktioniert, können Sie einige Dinge tun, um das Problem genauer herauszufinden und evtl. selbst zu beheben...

Die erste Sache, die Sie tun können, ist Ihre Konfiguration von Nagios mit der -v Option überprüfen lassen.
Beispiel:

/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Falls keine Fehler gefunden wurden, können Sie zum nächsten Schritt gehen...
Falls Nagios hier einen oder mehrere Fehler meldet, können Sie das Problem beheben, indem Sie die Konfigurations-Datei editieren.

Der nächste Schritt wird etwas länger dauern, gibt Ihnen aber auch mehr Informationen über das was in Nagios selbst abläuft. Als ich anfing Nagios zu entwickeln, habe ich jede Menge Debugging-Code hinzugefügt, um selbst Probleme besser einschränken zu können. Ich benutze immernoch diesen Code, wenn ich neue Features hinzufüge, oder selbst Bugs beheben möchte. So können Sie auch den Debugging-Code benutzen:

Führen Sie erneut das "configure"-Skript in der Nagios-Distribution aus und aktivieren Sie eine oder mehrere Debug-Informationen wie folgt, indem Sie "--enable-DEBUGx" mit einem oder mehrere Werte aus der folgenden Tabelle ersetzen:

./configure --prefix=/your/nagios/directory --enable-DEBUGx

Debugging Options

Kompilieren Sie Nagios erneut.

Überprüfen Sie erneut Ihre Konfigurations-Daten - Sie werden wesentlich mehr Informationen erhalten, wenn Sie die DEBUG1-Option aktiviert haben. Versuchen Sie die Ausgaben in eine Datei umzuleiten, so dass Sie diese später lesen oder ausdrucken können.

Falls Sie die DEBUG3- oder DEBUG4-Option benutzt haben, lassen Sie Nagios als Prozess im Vordergrund laufen und beginnen Sie damit Ihre Dienste zu überwachen.
Beispiel:

/usr/local/nagios/bin/nagios /usr/local/nagios/etc/nagios.cfg

Beenden Sie Nagios an einer geeigneten Stelle (z.B. nachdem eine Dienst-Überprüfung fehlgeschlagen ist) und schauen Sie sich die Ausgaben an. Dies sollte Ihnen helfen die Ursache des Problems herauszufinden. Auch hier ist es empfehlenswert die Ausgaben in eine Datei umzuleiten um Sie später einfacher diese studieren zu können.
Evtl. müssen Sie etwas am Source-Code von Nagios optimieren, um das Problem zu lösen. Bitte lassen Sie es mich wissen, falls Sie solch eine Veränderung vornehmen müssen, um diese in zukünftige Veröffentlichungen einfliessen zu lassen.

Falls es Ihnen trotzdem nicht möglich ist, dass Problem selbst herauszufinden, senden Sie mir eine eMail mit den folgenden Informationen (warnen Sie mich vor, falls Sie grosse Attachments mitsenden!):

1. Die Version von Nagios die Sie benutzen
2. Eine Beschreibung was genau falsch läuft und was Sie glauben, wo das Problem liegt
3. Das OS, die Distribution, Version und Architektur die Sie nutzen (z.B. RedHat Linux 7.2 for Intel)
4. Ihre Konfigurations-Datei
5. Die Ausgaben von Nagios (mit den Debugging-Optionen aktiviert)