[PoC] MQTT als Übertragungsweg zwischen Slave und Master möglich? Oder eine andere Alternative?

Global Community Deutsch
1

Hallo zusammen.

Eine kleine Gedankenspielerei meinerseits, die nun langsam Formen annimmt.
Ursache für dieses Experiment sind nicht vorhandene oder unübliche Kommunikationswege sowie “seltsame” Sicherheitsrichtlinien.
Beispiel: Kein VPN/Tunnel/Verbindung vom Master zum Slave möglich.
Alternativer Lösungsansatz (bisher): Tunnel vom Slave zum Master für Reverse-SSH-Tunnel (wird nicht mehr genehmigt).
Möglicher Lösungsansatz: Die Cloud-Edition könnte helfen, aber bei 5 Agenten und 500 SNMP-Devices leider nicht zielführend.
Weiterer alternativer Lösungansatz: livedump/cmcdump, verpackt als S-MIME-Mail (oder irgendwie von A nach B). Geht, aber hat auch Nachteile.

Was könnte helfen bzw. wie gehen andere Applikationen vor?
Beispiel IoT: Lokal läuft ein Collector, der alles per MQTT in die Cloud (zum Broker) schickt. Da steht nicht “VPN”, “Tunnel” oder anderes “böses” Zeug im Namen? Genehmigt!
[ja, ich finde viele Ansätze und Alternativen zu den “bösen” Dingen auch gruselig, aber man muss nehmen was man kriegt].

Meine Idee ist nun, über einen Alert Handler alle Ereignisse auf dem Slave abzufangen (Alert Handler - Auf Probleme automatisiert reagieren) und per MQTT-Client einem Broker zu übergeben (Policy für MQTT: 1x erfolgreich abliefern beim Broker).

Der Master holt sich über eine MQTT-datasource dann die Zustände vom Broker und tütet diese direkt in den Livestatus ein (Livestatus command reference; PROCESS_*_CHECK_RESULT).
Liefert die datasource kein Ergebnis mehr, wird der Slave-Status CRIT/DOWN und ich kann entsprechend alarmieren. Einzig das dopplete Anlegen aller Hosts auf dem Master gefälllt mir an dieser Idee nicht. Vielleicht löse ich das über einen Slave-Fake-Host mit “Piggyback”-Services.

Wenn es bessere Ansätze dafür gibt, sei hiermit das Brainstorming eröffnet.

Gruß
Stefan

1 Like
2

@StefanM ich habe gestern mit @robin.gierse über einen Ansatz gesprochen, der diesem Ansatz ähnelt

livedump/cmcdump, verpackt als S-MIME-Mail (oder irgendwie von A nach B). Geht, aber hat auch Nachteile.

Einer unserer Partner hat diesen Ansatz so implementiert, dass sie den Dump auf eine Nextcloud legen und der von dort abgeholt wird. Das vermeidet den ganzen Email-Aufwand.

@robin.gierse weiß da sicher noch ein bisschen mehr.

3

@elias.voelker
Ein kleiner Makel des cmcdump Ansatz ist das auf der Empfänger-Seite nur angezeigt aber nicht alarmiert werden kann.

Es fehlt ein Modus bei dem die Remote Seite das Einsammeln der Metriken und die Central Site das Alarmieren (Check-Attemps, Timeperiods, Notification, BI usw.) übernimmt so ahnlich wie bei einem MRPE/Local Check.

1 Like
4

Hallo Elias,

Der Transportweg war nur ein Beispiel. Es bleibt der Nachteil, den Lars angesprochen hat: Man hat zwar den Status, kann darüber aber nicht alarmieren. Und man ist auf cron (1-Minuten-Intervalle) auf beiden Seiten angewiesen. Wie gesagt, ich möchte das gerne mal ausprobieren und bin gespannt, wie weit ich mit meinem Collector-Ansatz komme.

Gruß
Stefan

5

Ich meine das alarmieren kann man durch die hintertür umsetzen, weil Alert Handler wohl greifen. (Wenn ich das richtig in Erinnerung habe.)

Ist ein extra aufwand, aber zumindest hätte man erstmal einen weg.

1 Like