Seite wählen

NETWAYS Blog

Es lebe die NagiosCommunity!

Die Nagios Community ist außerordentlich lebendig. Es gibt zahlreiche gute Foren, Wikis, … Diese dezentrale Struktur hat leider auch ihre Nachteile. So fehlt es dem Nagios Einsteiger an Überblick, wo er wirklich brauchbare Informationen und Ansprechpartner findet. Die meisten befragen dann eine Suchmaschine.
Ethan Galstad hat nun diesen Mangel erkannt und versucht nun diesen Umstand etwas zu verändern. Mit der https://www.nagios.org/about/community/ website hat er eine Plattform erstellt, die wundbar als Ausgangspunkt für weitere Recherchen dienen kann. Der Blog berichtet über interessante Neuigkeiten in der Community. Daneben sind auch die zur Zeit aktiven Wikis und Foren mit zahlreiche Links vertreten. Im eigenen Wiki finden Dokumentationen zu interessanten Themen rund um Nagios vorhanden.
Daher mein Aufruf: wer auch immer etwas weiß, was Nagios User interessieren könnte, möge das doch bitte auf NagiosCommity.org veröffentlichen oder zumindest dort einen Link hinterlegen. Ich werde versuchen dort auch meine Inhalte abzulegen. Angefangen habe ich bereits mit 3 Artikeln:

Ich hoffe einige folgen meinem Aufruf.

Wer überwacht den Überwacher, oder Nagios hochverfügbar

An die Verlässlichkeit von Nagios gewöhnt man sich schnell und nach der Einführung von Nagios verliert man gerne das Bedürfnis sich aktiv die eigenen Systeme anzusehen. Stattdessen verlässt man sich auf die Alarme durch Nagios. Was passiert nun aber, wenn Nagios oder der Nagios Server selbst ein Problem hat? Wer überwacht den Überwacher? Oder wie stellt man sicher, dass Nagios Ausfälle erkannt werden?
Klar ist, dass das Monitoring von außen und nicht vom Nagios-Server selbst erfolgen muss, ansonsten wird man bei einem Ausfall des Nagios-Servers selbst nicht informiert. Um den Ausfall von Nagios zuverlässig zu erkennen reicht es auf von außen über nrpe oder ssh check_nagios auszuführen. Liefert es kein OK muss man sich um Nagios kümmern. Diese Lösung reicht für einfache Setups sicher aus. Anders ist dies jedoch, wenn die Überwachung Grundlage für das Reporting zu vereinbarten SLAs ist oder man wirklich alle Checkergebnisse möglichst lückenlos benötigt. Dann darf das Protokoll der ermittelten Messwerte, Verfügbarkeit oder die Ergebnisse der Tests keine Lücken aufweisen. So muss Nagios hochverfügbar werden.
Für die Hochverfügbarkeit kennt die Dokumentation von Nagios 2 einface Ansätze, nämlich Redundant Monitoring und Failover Monitoring . Beiden gleich ist, dass nur der primäre Nagios Server Notifications verschickt. Weil beim Failover Monitoring der Server im Standby Mode keine aktiven Servicechecks (jedoch Hostchecks!) ausgeführ, ist dieses Verfahren das bessere Setup. Mit der Ergänzugn von oscp/ohcp wird die Aufzeichnung lückenlose.
Failover Monitoring hat allerdings auch seinen Nachteil. Die Konfiguration und Installation muss synchron gehalten werden! Dieser Nachteil lässt sich natürlich mit einem SAN-System für beide System erschlagen. Stehen beide Nagiosserver nicht am gleichen Standort, so ist dies auch kein Problem. Mit DRBD steht ein „Netzerwerk-RAID1 System“ zur Verfügung. Damit lassen sich beide System automatisch synchron halten.
Meiner Ansicht nach ist allerdings eine Lösung mit einem Storage-System nur etwas für wirklich erfahrene Linux Administratoren. Im Echtbetrieb tritt leicht mal eine Splitbrain Situation ein, bei der keiner der beiden Nagios Nodes weiß ob der andere noch lebt. Beide Systeme überwachen, schicken Notifications und schreiben Ihre Logfiles auf Platte. Mit der von SAN/DRBD Lösung erfordert ein Wiederzusammenführen dieser getrennten Systeme allerdings den manuellen Eingriff eines Administrators. Anders ist dies mit der Nagios Failover Lösung aus der Dokumentation. Nachdem Splitbrain schaltet der zweite automatisch wieder zurück. Den Nachteil der Synchronisation der Installation muss man da allerdings in Kauf nehmen. Wobei man meist nach der ersten vollständig Installation den ersten einfach klonen kann. Damit erschlägt man die ersten Probleme. Spätere Änderungen (neue Plugins, neue Software, …) muss man allerdings leider von Hand nachziehen. Rsync kann man verwenden, dass beide mit der gleichen Konfiguration arbeiten.
Mein Fazit
Ich empfehle den meisten die einfache Nagios Failover Methode. Der große Vorteil, dass Nagios nach der Splitbrain Situation wieder normal weiter macht wiegt meiner Ansicht nach den Synchronisationsaufwand auf.
Wie immer freue ich mich auf Feedback 🙂

Die richtige Distribution für Nagios?

Nachdem ich bei fast jedem Nagios Projekt gefragt werde, welche die richtige Distribution für Nagios sei, ist die Antwort mal einen Blog Beitrag wert. Oft will man von mir wissen welches Linux (RedHat, SuSe, Debian, …) die erste Wahl ist und in welcher Version es installiert werden soll. Natürlich gibt es auf die Frage keine immer gültige Empfehlung. Zwar läßt sich Nagios selbstverständlich unter allen gängigen Linux Distributionen gut betreiben, die Antwort ist dennoch nicht ganz einfach.
Zuerst die Wahl der Distribution: Meine erste Frage ist hier immer welche Distribution bereits eingesetzt wird bzw. mit welcher sich die zuständigen Mitarbeiter auskennen. Bekomme ich darauf eine eindeutige Antwort ist meine Empfehlung klar: genau diese Distribution, die schon eingesetzt wird! So verwenden wir bei NETWAYS Debian auf allen produktiven System. Damit steht für uns auch gleich die Distribution für Nagios fest. Bekomme ich allerdings keine eindeutige Antwort so fehlt meist die Linux Erfahrung beim Kunden und er ist nicht nur bei der Einrichtung und Betrieb von Nagios auf Unterstützung angewiesen sondern auch bei Linux. Wichtig ist auch, dass die Distribution sich reibungslos auf der Hardware des Kunden installieren lässt und läuft. Nicht vergessen sollte man auch andere Abhängigkeiten, wie die Unterstützung durch Backup Software, Virenscanner oder Datenbankclients. Weniger linuxerfahrene sollten da der Empfehlung der Hersteller ihrer Soft- und Hardware folgen. Bei meinen letzten Projekten fiel die Wahl dann eigentlich immer wieder auf RedHat. Es hat sich herausgestellt, dass RedHat und hier insbesondere RedHat Enterprise Linux diese Anforderungen am Besten erfüllt. Vor allem Nagios lässt sich per Yum und Dank Dag Wieers, der sich um die rpms Pakete kümmert, auf Knopfdruck immer in der aktuellsten Version installieren.
Aber welche Version der jewiligen Distributation soll man nun nehmen? Für alle Distributionen gilt für mich, dass eine Stable Version Pflicht ist. Alles andere führt häufig zu unnötigen Nebenschauplätzen. Beim RedHat Enterprise Server ist diese Voraussetzung bei der aktuellsten natürlich auch erfüllt. RedHat unterscheidet bei dieser Distribution auch noch zwischen verschiedenen Support Levels. Da muss jeder selbst entscheiden, wie viel Unterstützunge er braucht. Ich habe allerdings noch niemanden getroffen, der sehr häufig bei RedHat angerufen hat. Daher empfehle ich keine zu großen Support Verträge. Evtl. kommt sogar CentOS in Frage. Das OpenSource Projekt will 100% binärkompatible zum RedHat Enterprise Server sein. Garantie gibt einen jedoch darauf niemand.
Ich freue mich übrigens immer auf Kommentare zu meinen Blog Einträgen. Speziell dieses mal auf Erfahrungen anderer mit RedHat oder anderen Distris.

Nagios 3.x erreicht Beta Status

Seit gestern steht Nagios 3.0b1 zum Download bereit. Damit erreicht die Software nun Beta Status. Eigentlich hatte Ethan Galstad auf der letzten NagiosKonferenz 2006 eine stable Version bis Ende 2006 versprochen. Nun, das war wohl nichts. Verfolgt man den momentanen Zeitablauf der Realeses, so beschleicht uns der Verdacht, dass er die Stable noch vor der Nagios Konferenz 2007 liefern möchte.
Bisher setzen wir Nagios 3.x übrigens nur bei wirklich großen Kundenprojekten (>3000 Hosts) ein. Mit der alten Hostlogik ist Nagios 2.x dort am Limit angekommen. Die neue Version macht trotz des Beta Status einen relativ guten Eindruck. Abhängig vom Nagios Server schafft Nagios 3.x die hohe Anzahl von Maschinen und damit Servicehecks ohne Probleme. Ein Ausfall ganzer Segmente verursacht nun keine Flut der Hostchecks und damit einen Nagios Stillstand mehr. Jedoch hat die Erfahrung gezeigt, dass noch ab und an Memoryleaks auftreten, so empfiehlt sich ein regelmäßiger Neustart von Nagios. Mit der neuen Startprozedur in Nagios 3.x fällt dieser Restart nicht mehr auf.

RSS auf NagiosExchange

Das Linux-Magazin meldet in einer Newsmeldung vom 27.07.07 „Nagios-Plugin prüft Schreibrechte“. Der Text liest sich als sei ein neues Plugin für Nagios etwas seltenes. Erstaunlich, denn verfolgt man die RSS Feeds auf NagiosExchange aufmerksam, so merkt man schnell, dass fast täglich neue Plugins hinzu kommen. Zudem wurde check_writeable – so heißt das erwähnte Plugin – erst 2 mal abgerufen und weder bewertet noch kommentiert.