pixel
Select Page

Umstieg von NRPE auf den Icinga 2 Agenten

by | Oct 30, 2015 | Icinga, Windows

icinga_logo_200x69
Heute will ich euch ein Migrationsszenario bei der Überwachung von Windows für Icinga 2 beschreiben. Bei vielen kommt zum Monitoring von Windows der NSClient++ zum Einsatz, der integrierte NRPE-Server wird dann mit dem Plugin check_nrpe abgefragt.
Ist das Plugin und der NSClient++ nicht selbst übersetzt und der DH-Schlüssel selbst gewählt, benutzt man den selben wie tausend andere. NRPE ist damit als unsicher zu betrachten. Der Icinga 2 Agent authentifiziert Verbindungen an Hand von Zertifikaten der eigenen PKI. Den Agenten gibt es in der aktuellen Version im Bundle mit dem NSClient, damit sind die Plugins des NSClient++ auch weiterhin vom Agenten aus nutzbar.
Nun aber wie man eine Icinga 2-Konfiguration gestaltet, um zuerst NRPE-Checks benutzen zu können und dann sukzessive auf den Agenten zu migrieren. Als identifizierendes Merkmal verwenden wir das Host Custom Attribut noagent. True bedeutet dieser Host ist per check_nrpe zu prüfen, bei false soll der Agent verwendet werden.

object Host "andromeda" {
  import "generic-host"
  address = "172.16.1.22"
  vars.os = "Windows"
  vars.noagent = true
  vars.nscp_memory_committed = true
  vars.nscp_memory_free = true
  vars.nscp_memory_warning = "200M"
  vars.nscp_memory_critical = "100M"
}

Am Beispiel eines Services zur Überwachung der Memoryauslastung, folgen hier die beiden Definitionen.

apply Service "Memory usage" {
  import "generic-service"
  check_command = "nrpe-legacy-memory"
  assign where host.vars.os == "Windows" && host.vars.noagent
}
apply Service "Memory usage" {
  import "generic-service"
  check_command = "my-nscp-local-memory"
  command_endpoint = host.name
  assign where host.vars.os == "Windows"
  ignore where host.vars.noagent
}

Die Check Commands, die auf github zum Download bereit stehen, bieten für NRPE und NSCP die gleiche Parametrisierung. Ein Anpassen bzw. Abändern der Custom Attribute nscp_memory_* ist damit beim Umstieg nicht erforderlich und auch im Mischbetrieb kann auf doppelte Definitionen verzichtet werden. Es ist somit nur noagent zu entfernen und das für den Agenten erforderliche Zonen- und Endpoint-Objekt anzulegen. Zu beachten ist noch, dass der Endpoint und der Host den selben Namen tragen müssen (wg. command_endpoint = host.name).

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.
More posts on the topicIcinga | Windows

Icinga Web 2 trifft Guacamole

In meinem heutigen Blogpost geht es um Guacamole in Icinga Web 2 und die Frage, wie Guacamole in Icinga Web 2 implementiert werden kann. Aber was sind eigentlich Guacamole und Icinga Web 2? Introducing Icinga Web 2 Icinga ist eine Open Source Verfügbarkeits-Monitoring...

Icinga Camp Berlin 2022

Das erste Icinga Camp nach 2019 fand nun fast 3 Jahre später statt. NETWAYS hat als Sponsor und Hilfe in der Organisation zusammen mit der Icinga das Event zusammen auf die Beine gestellt und zu einem vollen Erfolg gemacht. Es wurde der aktuelle Stand der Dinge...

Icinga for Windows Preview: Visualisiert eure Metriken!

Icinga hat in seinem Blogpost mitgeteilt, dass es mit Icinga for Windows v1.10.0 einige Änderungen an den Performance Metriken geben wird. Hier wollen wir einmal grob zusammenfassen, worum es geht und welche Auswirkungen diese Änderungen haben. Für alle Details ist...

Icinga DB v1.0 released

Das Icinga Team hat nach langjähriger Entwicklungszeit die Icinga DB veröffentlicht. Damit steht Icinga ein neues Backend zur Verfügung, welches mittelfristig die IDO ablösen wird. Was ist die Icinga DB? Die Icinga DB ist nicht eine zentrale Komponente, sondern...