pixel
Seite wählen

Umstieg von NRPE auf den Icinga 2 Agenten

von | Okt 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.
Mehr Beiträge zum Thema Icinga | Windows

ServiceNow Data Asset Import mit dem Director

Hallo Liebe Leser dieses Blogs, nach einer weile der Abwesenheit hab ich heute die Freude ihnen etwas näher bringen zu dürfen. Da viele unserer Kunden inzwischen auch ServiceNow verwenden und diese auch als Assetmanagement / CMDB verwenden. Kommt doch die Frage auf...

Modifier im Icinga-Director selbstgemacht

Ich bin sowohl als Consultant als auch als Ausbilder ein großer Fan von Hilfe zur Selbsthilfe. Der Blogpost wird also zum einen dem geneigten Leser hoffentlich helfen sich bei Bedarf seine eigenen Modifier für den Icinga-Director zu bauen, zum anderen will ich anhand...

Icinga for Windows – Performance Boost mittels REST-Api

Seit dem ersten Release von Icinga for Windows hat sich eine Menge getan, um sowohl die Funktionalitäten, die Usability als auch die Sicherheit der Lösung zu erhöhen. Ein großer Fokus lag parallel jedoch auch immer auf der Performance, was sowohl auf den Aufbau des...

IDO-Snap: war vorher wirklich alles besser?

Kürzlich entstand im Rahmen eines Kundenprojektes ein nettes kleines Icinga-Modul, welches ich hier vorstellen möchte. Ein Monitoring-System ist abgesehen vom Desasterfall immer dann gefragt, wenn man Änderungen an seiner IT-Umgebung vornimmt. Firmware- oder...