master kriegt keine Host/Service Informationen von Satelliten

This forum was archived to /woltlab and is now in read-only mode.
  • Hey, ich versuche mich gerade an einem master/satellite Setup und kriege es irgendwie nicht ganz hin. Evtl. habe ich

    da auch einen Denkfehler.


    Ich habe aktuell einen Satellite, der mehrere Hosts/Services in seinem internen Netzwerk überwacht, welche von außen nicht erreichbar ist. Der Master soll diesen Satellite als externe Zone einbinden und dann auch durch icingaweb2 schön anzeigen.

    Es werden auch mehrere Zonen hin zu kommen, sagen wir mal Berlin, London usw. und im master sollten diese dann nach Zone gruppiert angezeigt werden, sodass man sieht, wie ist der Zustand vom Satellite freiburg oder london.


    Der master kennt die Zonen:


    Die Satelliten sat und pls-freiburg haben folgendes in der zone.conf:

    Bei allen (Beide Satelliten und der Master steht in der features-enabled/api.conf

    Code
    1. object ApiListener "api" {
    2. cert_path = SysconfDir + "/icinga2/pki/" + NodeName + ".crt"
    3. key_path = SysconfDir + "/icinga2/pki/" + NodeName + ".key"
    4. ca_path = SysconfDir + "/icinga2/pki/ca.crt"
    5. accept_config = true
    6. accept_commands = true
    7. ticket_salt = TicketSalt
    8. }

    Die Zertifikate haben ich über den Node Wizard auch genehmigt und da meckert der jetzt auch nicht mehr in den Logs.


    Der master meldet mir jetzt Sachen wie:

    Quote

    warning/ApiListener: Discarding 'config update object' message from 'pls-freiburg'.


    Habe ich etwas falsch konfiguriert oder wieso kriegt der master nichts von den Hosts/Services der Satelliten Zonen mit?


    Danke

  • Der Config-Sync funktioniert nur im "top down"-Modus, das heisst eine Parent-Zone wird von einer Child-Zone keinerlei Konfiguration oder Commands via Endpoint annehmen. Das ist hinsichtlich Sicherheit im System relevant, da sonst der Master nicht mehr das eigentliche Steuerorgan ist, sondern X-beliebige Konfiguration von Child-Zonen bekommen würde. Das wird nicht klappen. Das warning im Log kam mal in alten Versionen vor, mit der 2.7.x taucht das aber nicht mehr auf. Ist eine reine Debug-Message.


    Zeig mal ein "icinga2 --version" von allen Knoten.

  • pls-freiburg:

    master server

    sat Satellite

    War das dann ein Denkfehler von mir, dass es möglich ist sich alle Hosts/Services der Satelliten auf dem Master mit icingaweb2 anzeigen zu lassen?


    Als Alternative wäre dann ein Browser der jeden Satelliten in einem Tab offen hat und durch diese durch schwitcht... Das wäre nicht so schick wie die von mir erdachte Lösung :-)

  • War das dann ein Denkfehler von mir, dass es möglich ist sich alle Hosts/Services der Satelliten auf dem Master mit icingaweb2 anzeigen zu lassen?

    Nein. Genau so ist es auch gedacht, sich auf dem Master alle Hosts/Services der eigenen Zone und der untergeordneten Zonen anzeigen zu lassen. Was mit Top Down hier gemeint ist, ist dass die komplette Konfiguration auf dem Master gemacht wird. Wenn du einen neuen Host oder einen neuen Service in der Zone satellite überwachen willst konfigurierst du das nicht auf dem Satellite Node sondern auf dem Master. Durch die Config Synchronisation bekommt der Satellite Node vom Master mitgeteilt "Du hast jetzt einen neuen Host/Service, bitte überwach diese ebenfalls". Der Satellite überwacht dann die Hosts/Services und teilt dem Master über das Icinga Cluster Protokoll mit, wie die Check Results und Performance Daten aussehen. Der Master empfängt diese Daten und weiß nun somit, wie es in seinen untergeordneten Zonen aussieht. Die Daten schreibt der Master dann in seine IDO Datenbank, auf diese greift wiederum Icinga Web 2 zu und am Ende siehst du alle Hosts und Services aus der Master Zone und den untergeordneten Zonen im Icinga Web 2.


    Die Version 2.6.0, die du auf deinem Master und deinem Satelliten hast, ist von Ende letzten Jahres. Ich würde als ersten Schritt die Versionen hier gleichziehen, sprich alle auf die 2.7.1, die du bereits auf deinem Freiburg Satelliten hast.

  • hhmm das passt dann glaub nicht ganz in meinen UseCase, wenn man alles auf dem master konfigurieren muss.


    Ich überwache in den Zonen der Satelliten dynamische Geräte die per API Calls erst zur Laufzeit bei den Satelliten erstellt und aktualisiert werden.


    Da habe ich vorher keine Ahnung von, was für Geräte da rum geistern werden. Die haben zum Teil nicht mal TCP/IP Funktionalität.


    Evtl. könnte ich das so einrichten, dass die Software welche die Hosts/Services auf den Satelliten per API Call erstellt, diese mit der jeweiligen info in welcher Zone die sich befinden auf dem master erstellt. Dann muss ich aber gewährleisten, dass die Geräte da immer eine Verbindung zu unserem master hat.


    Das wird glaub ich nicht immer gegeben sein. Die gehen da per VPN zu uns ins Haus und der Kunde hat meist miserables Internet...

    Deshalb sollte das eig. autonom bei den Satelliten laufen und wir haben bei aktiver Verbindung halt Einsicht in das Monitoring.


    Ich glaube ich muss mich da noch mal mit meinem Projektteam zusammen schließen, ob da doch noch eine aktive Internetverbindung gefordert werden kann.


    Danke für die Info.

  • Hauseigene Programme die als Dienste laufen und durch die Informationen durch fließen die zum Teil per NFC von Funkchips gelesen werden.

  • Überleg mal, worauf meine Frage abgezielt hat. Ich möchte wissen wie es aktuell technisch implementiert ist, um dann vielleicht einen Alternativvorschlag zu machen.

  • Es gibt verschiedene TCP/IP Geräte mit NFC Readern (im Prinzip Raspberry Pis) und wenn ein NFC Tag von einem Funkgerät an so einer Stelle gelesen wird, übermittelt dieser die Daten (Akkustand etc.) an einen ProxyServer der diese weiter verarbeitet.


    Dieser ProxyServer (von uns entwickelt) checkt dann ob es dieses Funkgerät bereits im Monitoring gibt und aktualisiert die Daten bzw. erstellt diesen dann.


    So werden dann zahlreiche Funkgeräte über die verschiedenen NFC Reader unregelmäßig überwacht und halt auch der Rest des Systems, die Pi's usw.).

    Der Server auf dem dieser Proxy und das Monitoring läuft hat zwei Netzwerkschnittstellen, eine für unser System mit den Readern usw. und eine zum Kunden hin über das der dann auch ins Internet kommen sollte.


    Evtl. kriege ich das doch so hin, dass der Proxyserver die API Aufrufe nicht mehr nach localhost schickt sondern zum master der dann über das Internet/VPN erreichbar sein wird.

    Dann müsste ich bei allen host/Service Objekten dann beim Erstellen noch das Attribut zone="berlin" setzen z.B.

  • Ok. Das heisst, dieser Daemon weiss quasi alles über deine Umgebung. Hat der eine HTTP Schnittstelle, wo man abfragen könnte, welche neu zu erstellenden Objekte dieser gefunden hat? Dann könntest du das auch vom Master aus erfassen. Umgekehrt würde es natürlich Sinn machen, die Daten von diesem Daemon an den Master zu proxien.


    Habt ihr auf diesem Setup etwas wie Ansible oder Puppet am laufen, oder geht das mangels Verbindungen gar nicht?

  • Es läuft kein Ansible oder Puppet.


    Es gibt aber anscheinend auch eine Möglichkeit wie man bei diesem Proxy abfragen könnte welche Objekte der bis jetzt alle kennt und dann dem sein Monitoring auf zu bauen. Aber dann wäre das zu viel an Daten was da sinnlos jedes mal rüber wandern müssen.


    Denke da ist der Ansatz mit, der Proxy sendet die API Calls an den master direkt, dass dieser die dann auf dem Satelliten erstellt angenehmer.


    Dann haben wir auch den Vorteil, dass wir Hosts die evtl. nicht mehr gebraucht werden einfach aus der Zone auf dem Master löschen können und diese dann auch beim Satelliten verschwinden, evtl. auch mit dem Icinga Director.


    Danke für die Denkanstöße

  • Oder wie wäre ein Setup, indem jeder Satellite bei Kunden als Master konfiguriert ist und mit dem eigentlichen master per Zone ein Cluster bildet?

    Habe hier mal eine Grafik gezeichnet wie ich das meine:


    Dann wäre der Master-Freiburg in einer Master Cluster Zone mit Berlin, in einer eigenen master Cluster Zone mit London usw.

    Dann würden alle Informationen im Cluster doppelt gehalten werden und der master-freiburg hätte alle Infos.


    Würde sowas funktionieren oder ist das zu weit her geholt?

  • Das knallt dann spätestens wenn du mehr als einen Config-Master in der gleichen Zone hast. Mit Config-Master meine ich einen Knoten, der in zones.d die Konfiguration ablegt - sei es statisch, oder via Director ausgerollt.


    Dementsprechend solltest du dir ein Top-Down-Setup überlegen, wo du eine Konfigurations-Masterzone hast und darunter liegend die Satelliten ansprichst.

  • okay dann bleibt es wahrscheinlich doch bei einer TopDown Variante.


    Noch eine Frage: Beim master liegen dann alle per API erstellten Hosts unter /var/lib/icinga2/api/packages/_api/monitoring-1508225094-1/conf.d/hosts ab.


    Kann man das nicht nach zonen sortieren? Bsp. mit Ordnern für die jeweiligen zonen.

    Wenn ich pro Satellit etliche Hosts habe müllt das mir den Ordner zu mit config Dateien und ich kann schlecht nach einzelnen Hosts suchen.

    Und es könnte auch in mehreren Zonen mit eventuellen gleichen Hostnamen auftauchen. Das würde ja dann im master einen Datenkonflikt geben.


    Danke

  • Es sollte dir egal sein, wie diese Dateien von Icinga abgelegt werden. Dort willst du im Normalfall auch nicht hineinschauen, sondern icinga2 object list sowie die REST-API verwenden, um dir die Objekte anzuzeigen. Sofern wir irgendwann mal die Dateistruktur in /var/lib/icinga2/api verändern (was nicht ausgeschlossen ist), findest du dich nicht mehr zurecht.


    Generell gilt - alles was in /var/lib/icinga2 liegt, gehört dem Daemon und der User sollte daran nichts verändern.