Seite 1 von 1

Kommunikationsrichtung Icinga2: Master -> Client

Verfasst: 1. Dez 2018, 21:49
von gehrke
Moin *,

ich hadere gerade wahlweise mit der Dokumentation zu Icinga2 oder mit dem System selbst oder mit mir, weil ich zu doof bin.

Gegeben ist eine einfache Installation mit einem Master und N Clients. In quasi allen bislang gesichteten Dokumentationen lese ich, dass der Client mit dem Master (Server) via tcp/5665 kommuniziert. Also mit einem Port auf dem Master, welchen die Clients aufrufen.

Was aber, wenn ich das aus Gründen so nicht will? Stattdessen hätte ich gerne, dass der Master die Clients ansteuert, die Kommunikationsrichtung also andersrum ist (Port offen auf den Clients).

Gibt es diese Option bei Icinga?
TNX

Glückauf,
gehrke

Re: Kommunikationsrichtung Icinga2: Master -> Client

Verfasst: 2. Dez 2018, 09:23
von marce
Mit Icinga2 in der Tiefe (Distributed Monitoring) habe ich mich noch nicht beschäftigt (und genau Dein Szenario würde ich _nicht_ wollen), aber für mich klingt das ggf. nach einem Job für NRPE.

Re: Kommunikationsrichtung Icinga2: Master -> Client

Verfasst: 2. Dez 2018, 13:04
von StephanS
Wenn ich die Doku richtig lese, dann ist Port 5665 von Icinga die API-Schnittstelle des Masters, also wo man den Master steuern kann.
NRPE wird dagegen üblicherweise benutzt, um auf den Clients Checks auszuführen. Damit kannst du den Master nicht so einfach beeinflussen.
Kommt jetzt darauf an, welche Art der Kommunikation du möchtest bzw. was du damit erreichen willst.

Re: Kommunikationsrichtung Icinga2: Master -> Client

Verfasst: 2. Dez 2018, 15:35
von Gräfin Klara
gehrke hat geschrieben:
1. Dez 2018, 21:49
...
Gegeben ist eine einfache Installation mit einem Master und N Clients. In quasi allen bislang gesichteten Dokumentationen lese ich, dass der Client mit dem Master (Server) via tcp/5665 kommuniziert. Also mit einem Port auf dem Master, welchen die Clients aufrufen.
So ist typischerweise TCP.
Der Master (ein sinnloser Name) oder TCP-Server, heißt in Wahrheit Listener.
Der Listener tut das, was sein Name besagt, der hört nur auf diesem einen geöffneten Port das er offen hält und wartet auf einen Anruf. Aktiv kann der nicht werden, er kann von sich aus keine Verbindung (Connect) aufbauen.

Ein Client hört nie auf ein Connect, der kann das gar nicht. Der Client weiß nur, wo ein Listener wartet, z.B. auf tcp/IP_Adresse:Port. Dorthin schickt er sein Connect und der Listener akzeptiert das oder weißt den Wunsch aus bestimmten Gründen zurück. Will ein Client mit einem anderen Client kommunizieren, dann geht das NUR über einen Listener. In diesem Fall wären beide Clients mit dem selben Listener verbunden und der Listener vermittelt die Daten zwischen den beiden. Funktioniert nur so! (Das mir hier niemand etwas über PPP labert.)
gehrke hat geschrieben:
1. Dez 2018, 21:49
Was aber, wenn ich das aus Gründen so nicht will? Stattdessen hätte ich gerne, dass der Master die Clients ansteuert, die Kommunikationsrichtung also andersrum ist (Port offen auf den Clients).
...
Wollte man das so realisieren, dann dürften diese Clients keine Clients sein, sondern Listeners und dieser "Master" müßte ein Client sein.
Natürlich gibt es Lösungen, die in alle Richtungen funktionieren. Dann aber muß jede Seite Listener und Client gleichzeitig sein UND es braucht für diese Lösung ein eigenes Protokoll. Ob Icinga (ich habe kein Ahnung was das ist) das kann, darf man mit Sicherheit ausschließen.

Gruß
Gräfin Klara

Re: Kommunikationsrichtung Icinga2: Master -> Client

Verfasst: 2. Dez 2018, 17:44
von marce
Gräfin Klara hat geschrieben:
2. Dez 2018, 15:35
Ob Icinga (ich habe kein Ahnung was das ist) das kann, darf man mit Sicherheit ausschließen.
Ohne Dir nahetreten zu wollen - aber eine unnötige Grundsatzdiskusstion über Begrifflichkeiten dient hier niemanden - und wenn man von der Grundthematik "Icinga" keine Ahnung hat sollte man sich besser raushalten.

Das was der TE will kenne ich eher unter Agent-driven / Agent-based Monitoring - Der Grundansatz von Icinga ist anders herum, Alternativen gibt z.B. über NRPE, ggf. auch noch NSCA in besonderen Konfigurationen.

Re: Kommunikationsrichtung Icinga2: Master -> Client

Verfasst: 4. Dez 2018, 11:02
von Geier0815
Da ich selber über eine einfache Grundkonfiguration bei icinga (ein nagios-fork) nicht hinaus gekommen bin, kann ich dir nicht wirklich weiter helfen. Aber worüber ich selber in dem Zusammenhang immer wieder gestolpert bin und dies auch in deinem ersten Post wieder tue: Bei icinga (oder allgemein snmp) ist das Verständnis von master und server auf den Kopf gestellt. Du hast nur wenige clients (die icinga ausführen und auf denen Du dich einloggst um Daten abzufragen) und viele master (die Rechner die Du überwachst). Die Kommunikation läuft vom Client (icinga-Rechner) zu den Mastern (überwachte Rechner). Nur wenn Du per Browser oder Konsole auf den icinga-Rechner zugreifst, fungiert er als Server (Master) und das nur deinem Rechner gegenüber.
Es gibt bei snmp noch einen weiteren "Kanal" worüber die Master von sich aus an den Client senden, aber den meinst Du wohl nicht (emergency-Meldungen).

Also letztlich scheint deine Anforderung an den Kommunikationsweg erfüllt zu sein, es sei denn wir reden durch die Bezeichnung master und client aneinander vorbei. Dann erläutere bitte deine Anforderung mittels Worten wie "überwachter Rechner" etc, genauer.
Wobei, wenn wir ehrlich sind, ist das Ganze sogar noch etwas komplizierter, da icinga nicht nur auf snmp beschränkt ist. Aber das sind nachher dann auch die Dinge mit denen ich mich nicht weiter befasst habe.

Re: Kommunikationsrichtung Icinga2: Master -> Client

Verfasst: 5. Dez 2018, 19:44
von spoensche
Du kannst Master-Client und Client Master Kommunikation.

Du musst Icinga 2 als Top Down Command Endpoint konfigurieren. Der Master führt dann die Kommandos auf dem Satelite aus.

Re: Kommunikationsrichtung Icinga2: Master -> Client

Verfasst: 5. Dez 2018, 22:33
von gehrke
Leute, vielen herzlichen Dank für die vielen Antworten. Leider habe ich mich etwas verzockt, was meine aktuellen ToDos angeht, weshalb ich dieses Thema erst mal schieben muss. Wird wohl noch etwas dauern, bis ich das aufarbeiten kann. Sorry... :zensur: