wir bereiten gerade die Migration von der 2.1.0p33 CEE auf die 2.2.0 vor. Überlicherweise gehen wir bei den Migrationen so vor, dass wir auf den einzelnen Hosts per omd backup und omd restore jeweils einen Clone der jeweiligen Slave-Sites anlegen, diese dann zum Test migrieren und prüfen, wo Handlungsbedarf besteht. So war es nun auch bei dieser Migration geplant.
Nun stehen wir vor dem Problem, dass nach dem Clonen die geclonte Slave-Site plötzlich versucht, auch alle Hosts aller anderen Slave-Sites zu überwachen. Das Verhalten haben wir sowohl bei omd backup und dann omd restore als auch bei omd cp. Vermutlich steht dieses Problem im Zusammenhang mit Werk 13312, allerdings kann es ja nicht Sinn dieses Werks sein, durch ein einfaches Clonen die ganze Site-Config zu zerschießen.
Ist das ein Bug? Gibt es evtl. neue Optionen, die wir beachten müßten?
das hört sich zunächst nach einem Bug an. Allerdings ist nach Deiner Beschreibung noch etwas unklar, wo der Bug auftaucht.
Ich fange mal mit den zu beachtenden Dingen an, aka ‘bewährte Praxis’. Wir empfehlen stehts, erstmal auf das letzte Patch-Release zu gehen, also erstmal auf die v2.1.0p37.cee, und von dort direkt auf das aktuell letzte Patchrelease (aktuell v2.2.0p17.cee) zu gehen. Dadurch hast Du praktisch 2 Upgrades.
In der Vergangenheit hat Umbenennen und Kopieren von Sites Probleme gemacht. Natürlich hoffen wir, dass die Bugs in dem Bereich komplett weg sind, würden bei einem Testaufbau diesen Problembereich allerdings umgehen. Konkret bedeutet dies also einen Laboraufbau mit gleich benamten Sites. Je nachdem wie gut Ihr dass Labor in der Hand habt könnt Ihr auch die gleichen IPs nehmen, so dass möglichst keine Laboranpassungen nötig sind.
Bei einem mutmasslichen Bug haben wir ja immer die Herausforderung, möglichst reproduzierbar zu sein. Es wäre also hilfreich zu wissen, ob das Problem auch bei einem neuen kleinen verteilten Monitoring auftritt.
das hört sich zunächst nach einem Bug an. Allerdings ist nach Deiner Beschreibung noch etwas unklar, wo der Bug auftaucht.
Das Problem tritt unabhängig vom geplanten Update schon beim einfachen Clonen der Site auf. Gleicher Host, gleiche Check_MK-Version (2.1.0p33 CEE): Auf der Quell-Slave-Site wird nur 1 Host überwacht, alle anderen Hosts werden von anderen Sites aus überwacht. Die Quell-Site wird per omd backup und omd restore geclont (bei omd cp tritt das gleiche Problem auf). Schon beim omd restore werden etliche Hosts als unerreichbar gemeldet (die sind ja auch in einem anderen Netzwerksegment), sonst treten beim omd restore keine Fehler auf. Nach dem Starten der geclonten Site werden plötzlich alle Hosts der gesamten Umgebung von der Clone-Site überwacht. Zudem sind die vorm Sichern der Quell-Site deaktivierten Notifications wieder aktiviert, was auch ungewöhnlich ist.
Konkret bedeutet dies also einen Laboraufbau mit gleich benamten Sites. Je nachdem wie gut Ihr dass Labor in der Hand habt könnt Ihr auch die gleichen IPs nehmen, so dass möglichst keine Laboranpassungen nötig sind.
Auch, wenn wir das eigentliche Thema damit etwas verlassen: So etwas hatten wir früher mal betrieben. Abgesehen vom Aufwand war es in einer reinen Laborumgebung oft kaum möglich, Bugs bei Checks festzustellen, weil etliche überwachte Systeme einfach nicht mit der Laborumgebung sprechen dürfen. Gewöhnlich lagen die meisten Migrationsprobleme bei den Checks, daher sind wir vom Betrieb einer identischen Laborumgebung abgekommen.
leider ist das hier ein anderes Problem. Damals wurde nur der Eintrag in der multisite.d/sites.mk nicht umbenannt. Hier scheint beim clonen die Zuordnung von Hosts zur Monitoring-Site kaputtzugehen.
Du hast recht, dass die Bugklasse, die bei realen Abfragen auftreten, durch eine derartige isolierte Laborumgebung nicht abgefangen werden kann. Nichtsdestotrotz gibt es die Bugklasse, die selbst beim Upgrade der Konfiguration einer Zentralsite sichtbar wird. Ich bin sicher, dass Ihr für Eure Situation passend Aufwand und Nutzen abgewogen habt.
Ich kann das Problem noch nicht reproduzieren. Dabei ignoriere ich zunächst die Sache mit den Notifications uns konzentriere mich auf das Monitoring von Hosts anderer Sites.
Was ich gemacht habe:
Aufbau eines kleinen verteilten Monitorings mit v2.1.0p33.cee (Zentral- und Remotesite auf localhost, jeweils ein Host pro Site gemonitort, internes Skript omd-vonheute)
Stoppen beider Sites
omd cp p33_remote_1 clone
omd start clone
Einloggen in Site clone als cmkadmin, Prüfung auf Anzahl gemonitorter Hosts
→ nur ein Host, so wie es sein soll
Kannst Du in Richtung meines vereinfachten Setups gehen, und das Problem dort bestätigen? Oder welche Unterschiede bestehen noch?
sorry für die späte Antwort, mich hatte eine Erkältung erwischt.
Ich habe es wie bei Deinem Test auch mal mit omd cp probiert, das Ergebnis ist das Gleiche. Ich werde das nachher (spätestens morgen) nochmal in einer Testumgebung mit einer einfachen Konfiguration versuchen, nachzustellen.
Seltsam ist, dass die Zuordnung der Hosts in den jeweiligen .wato oder hosts.mk-Files richtig drinsteht. An welcher Stelle beim Restore oder Start könnte Check_MK auf die Idee kommen, diese Einstellungen zu ignorieren? Andere Einstellungen in diesen Dateien werden ja sauber angewandt.
Hi @miwu , ich würde beim derzeitigen Stand des Debuggings/ der Reproduktion noch nicht so weit gehen, dass besagte Einstellungen ignoriert werden, es könnte auch was anderes sein.
Bin gespannt auf Deine weiteren Tests.
so, ich habe das jetzt mal in einer Testumgebung in der gleichen Version (2.1.0p33 CEE, SLES15) nachgebaut. 2 Sites neu und leer erzeugt, Mastersite mit einem überwachten Host, Slave-Site mit einem überwachten Host konfiguriert, beides per separatem Login auf die Sites überprüft. Auf beiden Sites gibt es jeweils einen überwachter Host, die Mastersite zeigt in der GUI beide Hosts an.
Die Slave-Site habe ich dann per omd cp kopiert und hochgefahren. Das Ergebnis: Auf der Kopie der Slave-Site wird kein (!) überwachter Host angezeigt. In den Wato-Config-Dateien der kopierten Slave-Site stehen beide Hosts drin, der Host, der durch die kopierte Site überwacht werden sollte hat dort auch richtigerweise den Eintrag " {‘site’: ‘miwutest_sla_cpy’, 'address_"…
Wenn ich die Mastersite kopiere funktioniert alles wie erwartet. Die kopierte Mastersite überwacht den einen Host und zeigt den von der originalen Slave-Site überwachten Host an.
Das Problem scheint also nur beim Kopieren einer Slave-Site aufzutreten und ist hier reproduzierbar.
Nach einer sehr konstruktiven Session mit unserem Supporter (vielen Dank in Richtung Stuttgart !!!) haben wir nun eine Ursache des Problems gefunden: Beim Kopieren per omd cp oder auch beim Restore eines Backups in eine neue Site bleibt das File ~/etc/check_mk/conf.d/distributed_wato.mk leer, was zu dem eingangs beschriebenen Chaos führte. Das Problem konnte sowohl bei uns als auch bei unserem Supporter nachgestellt werden. Wenn man das File nach dem Kopieren händisch mit den notwendigen Parametern füllt (anschließend cmk -O nicht vergessen) sieht es schon besser aus. Als offenes Problem bleibt nun noch, dass in der kopierten Slave-Site noch immer zusätzlich zu den dort überwachten Hosts die Hosts der Master-Site auftauchen.
