Diese Website existiert nur weil wir Werbung mit AdSense ausliefern.
Bitte den AdBlocker daher auf dieser Website ausschalten! Danke.

Kommunikationsrichtung Icinga2: Master -> Client

Alles rund um die Server (Web-, Mail-, Datenbank-, Datenaustausch-, etc.) die man unter Linux betreiben kann

Moderator: Moderatoren

Antworten
Benutzeravatar
gehrke
Moderator
Moderator
Beiträge: 1856
Registriert: 10. Nov 2012, 11:00
Wohnort: Münsterland

Kommunikationsrichtung Icinga2: Master -> Client

Beitrag von gehrke » 1. Dez 2018, 21:49

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

Werbung:
marce
Advanced Hacker
Advanced Hacker
Beiträge: 1083
Registriert: 19. Jun 2008, 13:16
Wohnort: Dettenhausen
Kontaktdaten:

Re: Kommunikationsrichtung Icinga2: Master -> Client

Beitrag von marce » 2. Dez 2018, 09:23

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.

Benutzeravatar
StephanS
Member
Member
Beiträge: 69
Registriert: 24. Jan 2005, 22:04

Re: Kommunikationsrichtung Icinga2: Master -> Client

Beitrag von StephanS » 2. Dez 2018, 13:04

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.

Gräfin Klara
Hacker
Hacker
Beiträge: 335
Registriert: 23. Jun 2008, 20:51

Re: Kommunikationsrichtung Icinga2: Master -> Client

Beitrag von Gräfin Klara » 2. Dez 2018, 15:35

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

marce
Advanced Hacker
Advanced Hacker
Beiträge: 1083
Registriert: 19. Jun 2008, 13:16
Wohnort: Dettenhausen
Kontaktdaten:

Re: Kommunikationsrichtung Icinga2: Master -> Client

Beitrag von marce » 2. Dez 2018, 17:44

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.

Benutzeravatar
Geier0815
Administrator
Administrator
Beiträge: 4292
Registriert: 14. Jun 2004, 09:12

Re: Kommunikationsrichtung Icinga2: Master -> Client

Beitrag von Geier0815 » 4. Dez 2018, 11:02

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.
Wenn Windows die Lösung ist...
kann ich dann bitte das Problem zurück haben?

spoensche
Moderator
Moderator
Beiträge: 7402
Registriert: 30. Okt 2004, 23:53
Wohnort: Siegen

Re: Kommunikationsrichtung Icinga2: Master -> Client

Beitrag von spoensche » 5. Dez 2018, 19:44

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.

Benutzeravatar
gehrke
Moderator
Moderator
Beiträge: 1856
Registriert: 10. Nov 2012, 11:00
Wohnort: Münsterland

Re: Kommunikationsrichtung Icinga2: Master -> Client

Beitrag von gehrke » 5. Dez 2018, 22:33

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:

Antworten