Monitoring von Puppet Nodes mit Hilfe von PuppetDB

Konfigurationsmanagement und Monitoring sind heutzutage die wichtigsten Teile des Betriebs von größeren Computerlandschaften. Gerade beim Konfigurationsmanagement können aber leicht Fehler passieren, die Fatal für den Betrieb sein können. Ein korrektes Monitoring des Konfigurationsmanagements ist deswegen enorm wichtig.

Wenn man mit Puppet oder anderen Konfigurationsmanagement-Systemen arbeitet, kann es manchmal vorkommen, dass nach einer Änderung manche Nodes keine Konfigurationsänderungen mehr annehmen oder gar der Konfigurations-Dienst nicht mehr startet. Aus diesem Grund sollte man den Zustand der einzelnen Nodes überwachen und bei Problemen schnell handeln.

Sofern Puppet mit Icinga oder Nagios überwacht wird, wird hierfür oft ein Script verwendet, welches die Status-Datei /var/lib/puppet/state/last_run_summary.yaml auswertet. Dieses kann auf allen Puppet Nodes via NRPE aufgerufen werden, wie mein Kollege Roland beschreibt. Alternativ lässt sich das gleiche Script als lokaler check_mk Check ausführen.

Es gibt jedoch Setups, bei denen man evtl. auf NRPE verzichten möchte oder zumindest nicht den gleichen Check auf jeder Maschine ausführen möchte. In diesem Fall kommt einem PuppetDB gerne zur Hilfe. Grundsätzlich ist PuppetDB in jedem größeren Puppet Setup zu empfehlen, da diese das Cachen von Katalogen und das exportieren von Ressourcen erlaubt. Sofern die PuppetDB nicht nur Kataloge, sondern auch Reports der einzelnen Nodes speichert (via reports = store,puppetdb in der puppet.conf des Puppet Masters), lässt sich der Zustand der einzelnen Nodes mit wenigen API Aufrufen abfragen. Für die Integration dieser Aufrufe in Icinga/Nagios haben wir ein kleines Skript geschrieben: check_puppetdb_nodes.

Das Skript benötigt eine aktuelle (1.5 oder neuer) PuppetDB und einige Perl Module, die auf den meisten Systemen sowieso schon installiert sind: JSON, LWP, Date::Parse und Nagios::Plugin). Beim Aufruf fragt das Skript zunächst die PuppetDB auf localhost:8080 (oder auf einem anderen Host oder Port, wenn via -H und -p übergeben) nach der Liste der bekannten Nodes und den Zeitstempeln ihrer Kataloge. Sofern ein Katalog älter als 2 bzw 24 Stunden ist, wird WARNING bzw CRITICAL an das Monitoring zurückgeben. Andere Intervalle lassen sich mit -w und -c minutengenau einstellen.

Da ein erfolgreich kompilierter und abgerufener Katalog nicht bedeutet, dass der Puppet Agent diesen auf der Maschine auch anwenden konnte, ist es notwendig zu überprüfen, ob der Puppet Agent nach dem Durchlauf Fehler gemeldet hat. PuppetDB exportiert derartige Informationen über den Events und Event-Count Endpoint der API, hierzu muss jedoch das Speichern von Reports in der PuppetDB aktiviert sein. Für ein Monitoring reicht der Event-Count, da hierüber eine einfache Statistik des letzten Durchlaufs abrufbar ist. Standarrdmäßig wird check_puppetdb_nodes bei einer Fehleranzahl größer Null sofort CRITICAL melden, dies lässt sich jedoch mit -W und -C weiter konfigurieren.

Mit check_puppetdb_nodes lässt sich das Monitoring einer ganzen Puppet Landschaft mit Hilfe von Icinga/Nagios schnell und ressourcenschonend implementieren. Die einzige Anforderung ist eine PuppetDB mit aktivierter Speicherung von Reports, welche auch in anderen Szenarien bereits stark zu empfehlen ist.

Dieser Artikel wurde ursprünglich geschrieben von Evgeni Golov.