wir haben 2.0.0p25 (CEE) auf paar Slaves und einem Master laufen. Die Replikation von MKPs ist in der Konfiguration eingeschaltet und funktioniert an sich.
Es ist mir aufgefallen, dass das Verschieben von Hosts von einer Seite auf eine andere zum folgenden Problem führt:
Währen der Aktivierung der Änderung (drei Hosts von der einen auf eine andere Seite Verschieben) kommt es zu nicht Replizieren von MKPs auf die Ziel-Seite. Das führt direkt zu einer Warnung an der Ziel-Seite im Aktivieren-Screen, weil angeblich nicht genutzte Konfiguration gefunden wurde (zu der jetzt die entsprechenden MKPs fehlen). Das Verzeichnis “local/share/check_mk/checks/” in der Ziel-Seite ist tatsächlich leer. Das Fehlen der replizierten Plugins führt dann noch zu den anderen Unannehmlichkeiten wie Alerts und das Verschwinden von eingetragenen Acknowledgements/Downtimes für die Services, die auf den verschwundenen Plugins basieren.
Eine schnelle Abhilfe: eine Kleinigkeit wie einen Timeout-Wert in der Konfiguration der betroffenen Seite (Edit site connection) ändern und die Änderung aktivieren. Die Packages werden wieder repliziert und die Warnung im Aktivierungs-Screen verschwindet. Jetzt muss ich noch die verschwundenen Acknowledgements/Downtimes nachziehen.
Ich habe auf die schnelle nichts passendes in Logfiles gefunden. In Werks habe das gefunden: Werk #14051: Fix crash in activate changes
Das Problem könnte doch damit zusammenhängen, weil es erst jetzt auftaucht und die Version 2.0.0.p21 nicht betroffen war.
Kennst das jemand? Eine Idee, wo ich nach der Ursache suchen kann?
Zu dem Problem hab ich schon recht lange ein Ticket mit ausführlichem Troubleshooting laufen.
Zur Zeit sind wir an dem Punkt, dass das System glaubt alle Dateien auf dem Slave System müssen gelöscht werden → keine Ahnung warum
Das Problem hier ist einfach es tritt nur bei einem von meinen vielen betreuten Systemen auf.
Danke für die Info, Andreas!
Ja, ich kann bestätigen, dass bei Weitem nicht alle Slaves betroffen sind, sondern nur welche (in unserem Fall, 2 von 8). Wobei es doch noch auf die Änderung selbst ankommt, welche betroffen sind. Ich konnte jedenfalls kein Muster erkennen: jemand benennt einen Host um und eine bestehende Regel, in der auf den Host referenziert wird, wird auch mit geändert, und das führt zum Löschen der Plugins auf einem anderen Slave, als auf dem der zu umbenennende Host eigentlich läuft.
Bleibt der Support an dem Thema dran, läuft die Fehlersuche weiter?
die Änderungen in “Fix crash in activate changes” scheint auch in der RAW Edition zum Tragen zu kommen. In der 2.0.0p25 habe ich nur sporadisch den Session_info Fehler. Vor der Version p25 sind diese mir nicht aufgefallen.
Ich kann auch mal ein kurzes Update zu meinem eigentlichen Problem geben.
Wir konnten zusammen (mit Andreas Bösl) den Fehler erfolgreich eingrenzen.
Kurze Zusammenfassung
die Löschung der unter ~/local befindlichen Daten geschieht nur in Umgebungen wo es Salves mit mkp Sync und welche ohne gibt.
es wird die ~/local Struktur auf dem Slave dann gelöscht wenn in der Liste der zu aktivierenden Site eine Site ohne mkp Sync am Anfang der abzuarbeitenden Sites steht.
werden nur Sites aktiviert welche mkp Sync aktiv haben so ist alles ok
Sollte noch vorhanden sein der Bug. Habe jedenfalls noch keine Rückmeldung über erfolgreiches beseitigen bekommen. Ist nicht ganz so trivial, da zur Zeit das System intern wie folgt arbeitet.
Änderungen stehen zum Sync an
Erste Site in der Liste aller zu aktivierender Sites wird genommen
Es wird berechnet was gemacht werden soll (kopieren/löschen usw.)
Es wird der Snapshot für die Local Struktur für diese Site erstellt
alle anderen Sites bekommen nur nen Link auf diesen Snapshot aber keine eigene Kalkulation was diese brauchen
Snapshot wird an alle gepusht
Der Punkt im Ablauf wo nur die Links für alle Sites bereitgestellt werden ist der Knackpunkt.
Hier müssten immer zwei Snapshots erstellt werden einer für Sites mit Sync und einer für Sites ohne.
Ja, es muss unterschieden werden, das ist richtig. Vielleicht 2 Snapshots, vielleicht sollten MKPs und sonst etwas, was nicht zwingend synchronisiert werden muss, separat behandelt werden. Der Bug wurde vor nicht langer Zeit erst eingeführt, sollte sich relativ einfach nachvollziehen können, durch welche Änderung.
Die Änderung welche hier “dran Schuld” ist haben wir schon beim Troubleshooting gefunden.
Genug im Code gewühlt um zu finden was passiert
Hier kurz der problematisch Code
# Choose one site to create the first site config for
site_ids = list(self._site_snapshot_settings.keys())
first_site = site_ids.pop(0) <-------- klingt fast wie im Glückspiel
# Create first directory and clone it once for each destination site
self._prepare_site_config_directory(first_site)
self._clone_site_config_directories(first_site, site_ids)
Ich hätte sogar ne Idee für eine dirty Workaround nur hab ich keine Lust das immer wieder bei nem Update zu patche
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
