Master Master Setup mit Satelliten und Clients bringt regelmäßigen configcheck Fehler

This forum was archived to /woltlab and is now in read-only mode.
  • Hallo zusammen,


    ich hänge grade an einer komischen Sache.


    Anfangs habe ich bei Änderungen in der Zone "global-templates" die Dateien vom Master1 (Configbase) auf Master2 kopiert, damit auch Master2 keine Fehler mehr brachte.

    Doch wenn ich das richtig verstanden habe, ist das gar nicht nötig, da Master2 von Master1 die Config-Dateien bekommt in "/var/lib/icinga2/api/zones/global-templates/_etc/" und die Dateien von der gemeinsamen Zone "master" bekommt er eh. Master2 hat inzwischen keine Dateien mehr im Verzeichnis "zone.d".

    Soweit sieht das auch dann alles erstmal prima aus, wenn die Datei in dem Verzeichnis noch nicht vorhanden ist auf Master2.


    Beide Icinga2 Instanzen machen ein configcheck und ein restart. Dann bekommt Master2 von Master1 das File, wo der Command-Check definiert ist, welche ich in die Zone "global-templates" gelegt habe und er bekommt das Serviceobject zu dem Check. Wenn ich jetzt auf Master1 configcheck ausführe ist alles in Ordnung. Nach der Synchronisation sagt mir Master2 das es in der Config Fehler gibt.



    Auf Master2:



    Code
    1. # /var/lib/icinga2/api/zones/global-templates/_etc/commands.conf
    2. object CheckCommand "java" {
    3. import "plugin-check-command"
    4. command = PluginDir + "/check_java"
    5. }


    Code
    1. #/var/lib/icinga2/api/zones/mmaster/_etc/local_agent_checks.conf
    2. apply Service "java" {
    3. import "generic-service"
    4. groups = [ "JAVA" ]
    5. assign where host.vars.java && host.vars.client_endpoint
    6. check_command = "java"
    7. enable_notifications = 0
    8. command_endpoint = host.vars.client_endpoint
    9. }


    Die zone.conf passt auch soweit, sonst würde erst gar nicht die Übertragung der Dateien stattfinden und mit anderen vorhandenen Checks würde es auch krachen.


    Warum findet Master2 plötzlich das CheckCommand "java" nicht, obwohl das CheckCommand in /var/lib/icinga2/api/zones/global-templates/_etc/commands.conf definiert ist, schließlich kann Master1 problemlos die Checks der Clients annehmen?


    Viele Grüße


    wiesel82:/

  • Die Zone haben alle Master, Satelliten und Agents in ihrer zone.conf stehen.


    Code
    1. object Zone "global-templates" {
    2. global = true
    3. }
  • Wenn du am zweiten Master das Debug-Log einschaltest, siehst du dann beim Start, dass die Datei "/var/lib/icinga2/api/zones/global-templates/_etc/commands.conf" eingelesen wird? Bitte diese Teile posten.

  • Hier ist die Ausgabe für beide Dateien auf Master2.


    Code
    1. 2017-01-24 14:43:56 +0100] debug/EndpointDbObject: update is_connected=1 for endpoint 'master1'
    2. [2017-01-24 14:43:56 +0100] information/ApiListener: Sending config updates for endpoint 'master1'.
    3. [2017-01-24 14:43:56 +0100] information/ApiListener: Syncing configuration files for global zone 'global-templates' to endpoint 'master1'.
    4. ...
    5. [2017-01-24 14:43:56 +0100] notice/ApiListener: Creating config update for file '/var/lib/icinga2/api/zones/global-templates/_etc/commands.conf'
    6. ...
    7. [2017-01-24 14:43:56 +0100] information/ApiListener: Syncing configuration files for zone 'master' to endpoint 'master1'.
    8. ...
    9. [2017-01-24 14:43:56 +0100] information/ApiListener: Updating configuration file: /var/lib/icinga2/api/zones/master//_etc/local_agent_checks.conf

    Laut überleg:

    Für die "global-templates" Zone macht er das für jeden Client und Satellit ebenfalls. Kann sowohl Master1 wie Master2 create config update file machen auf allen Satelliten wie Agents, wo sie parent sind?

  • Das können sie beide, allerdings merken sich die Instanzen welcher Knoten das ursprünglich geschickt hat (etwaige Loops sind damit ausgeschlossen). Was ich bei dir komisch finde ist die Tatsache, dass die Datei da ist, aber Icinga 2 diese dann nicht findet. Irgendwelche Unicode-Zeichen die sich da im Namen "java" eingeschlichen haben könnten?


    Du hast eingangs erwähnt, dass du da manuell Dateien synchronisierst. Kann das sein, dass du da auch Dateien in /var/lib/icinga2 angefummelt hast, etwa per Cronjob oder Puppet-Run?

  • Hatte nie einen Cronjob dafür laufen (nur manuell) und mit Puppet fange ich aktuell erst an die ersten Agents auf die Clients zu verteilen. In dem Sinne kann ich da noch beruhigt sagen ,dass es daran sicherlich nicht liegt.


    Ich habe mal die Verzeichnisse verglichen. In /var/lib/icinga2/api/zones/global-templates/_etc/ haben alle Master, Satelliten und Clients die gleichen Dateien, mit den gleichen Rechten, den gleichen Besitzern "nagios" und der gleichen Dateigröße. Selbst die MD5-Checksumme ist die gleiche auf allen. Wie kann sich da ein Unicode-Zeichen einschleichen, ohne dass Master1 sich nicht schon beschwert?

  • Ich habe den Check, der dem Master2 so Probleme macht wieder raus genommen.

    Muss nochmal genau schauen, was an dem CheckCommand oder dem Apply Service für java so Probleme macht.

  • Naja, für mich ist das Stochern im Heuhaufen, ich kann hier nur raten. Ich würde da /var/lib/icinga2/api/zones mal komplett leeren auf allen Instanzen und das nochmals syncen lassen.

  • Kaum habe ich die Zonen raus gelöscht, schon kommen ganz andere Fehlermeldung, wo z.B. 'NotificationCommand' re-defined ist.

    Und jetzt funktionieren auch die Checks.


    Danke dnsmichi