Update von 2.0.0p33 auf 2.1.0p20 stales werden nicht abgebaut

Hallo,
Wir haben heute unsere Multisite von 2.0.0p33 auf 2.1.0p22 upgegraded.
Auf dem Server befinden sich vier Sites, von denen eine der “Multisite-Manager” ist, also selbst keine Hosts enthält.
Es gibt dann 2 kleinere Sites mit wenigen Hosts die einwandfrei funktionieren.
Probleme haben wir mit der größeren Site, die aus 78 Hosts und 5239 Services besteht.

Sämtliche Checks gehen auf Stale, lassen sich jedoch durch Klick auf Check_MK / Reschedule Check manuell ausführen.
Die Anzahl der Stale Checks reduziert sich dann vorübergehend, steigt dann aber wieder an.

  • Automatisch findet kein Checken statt.
  • Das Service Speed-O-Meter zeigt permanent 0%.
  • CPU und Ram des Hosts sind unter 5% belegt.
  • Wir glaubten, einen Bezug zu der höheren Anzahl der Checkables in dieser Site zu sehen und haben sämtliche Hosts in ihr gelöscht, die Änderungen sodann appliziert, gefolgt von omd stop sitename omd start sitename - Das Ergebnis ist unverändert.
  • Analyze Configuration / Livestatus Usage zeigt:
CRIT: The current livestatus usage is 100.00% (!!), 20 of 20 connections used (!!), 
  You have a connection overflow rate of 0.00/s (!!)
  • Die Site läuft nun wieder prima unter 2.0.0.p33.

Für einen Tipp wäre ich dankbar.
Grüße, Stefan

Laut deinem Screen shot sind Host Checks, Service Checks, … alle abgeschaltet.

2 Likes

btw…dieses Phänomen hatte ich auch schon bei diversen Updates in meinen privaten virtualbox checkmk Umgebungen. Nach einem Update waren diese Schalter auf off gestellt, ohne das ich es vorher bewusst gemacht hätte…

Wenn ich mich recht erinnere war das “off” früher auch so richtig fett rot und damit kaum zu übersehen statt wie jetzt nur gedimmt grau.

Aber es gibt ja auch noch einen Service “OMD sitename Performance”, der entsprechend WARN/CRIT werden sollte. Hilft nur halt nicht, wenn der Checkmk-Server sich selbst überwacht :wink:

@thohenstatt Für dich :slight_smile:

1 Like

hm… für @thohenstatt wäre aber nur das es grau statt rot ist, oder :)? Der (vermeintliche?) Bug, dass die Schalter sich auto-magisch umstellen wäre ja auch noch spannend.

Hab das bisher noch nicht gesehen, waren das CRE oder CEE Instanzen?
Wirft cmk-update-config bzw. der Update-Prozess irgendwelche Fehler?

Hey Gerd, du verwechselt User Interface Design mit User Experience :wink:
Für Tanja wäre auch die Frage was das gewünschte Verhalten ist und was passieren sollte, falls das gewünschte Verhalten eben nicht eingetreten ist. Und da gibt’s die großen und die kleinen Sachen - der schnelle Fix wäre schon mal das wieder hervorzuheben. Aber wir gehen ja auch größere Themen an, die brauchen aber halt mehr Zeit

2 Likes

Erst Mal bleibt zu hoffen, dass die Schalter an seinem Problem Schuld haben :blush: aber sieht auf jeden Fall sehr danach aus.

Hallo,
Vielen Dank für die bisherigen Antworten.
Das habe ich übersehen, richtig.

Allerdings ist dies der zweite Versuch einer Migration gewesen, und beide Male war da alles “grün” und der Zeiger auf ca.10%-20% und schwankte da.
Die Stales haben sich über 90 Minuten nicht abgebaut.

Die kleineren Sites wurden einwandfrei gecheckt.
Als wir dann anfingen, manuell zu checken gingen natürlich die SMS los so dass ich erst dann alles (in Panik) abgedreht hab.
Ich glaube also nicht an diese “Lösung”, werde das aber erneut prüfen und berichten.

Wenn denn aber kein Host existiert, dann sollte das System doch aber auch nicht in den “Check-Rückstand” geraten und 0% anzeigen sondern ich hätte hier 100 erwartet.

Gruß, Stefan

@martin.hirschvogel vielen Dank für den Hinweis! Du hast recht, ich glaube da können wir aus UX Sicht noch einige Stellschrauben justieren!

@gstolz Du hast auch Recht, der erste Schritt ist, die Farben der Schalter anzupassen. :slight_smile:

@sru Ich habe dir eine direkte Nachricht geschrieben. Ich möchte mich gerne mit dir austauschen, um dem Problem auf den Grund zu gehen und zu schauen, wie wir den ganzen Prozess in Zukunft angenehmer gestalten könne, sodass Fehler einerseits vermieden werden können und andererseits, wenn sie doch auftreten, schnell behoben werden können.

1 Like

Hallo,
Ich möchte mal ein Status update geben.
Ich habe gestern erneut mehrfach die beiden relevanten Sites in der Version 2.0.0p33 aus dem Backup restauriert, auf 2.1.0p20 upgedated und gestartet.

Ergebnis: es funktioniert nun, aber ich kann nicht sagen warum.

@thohenstatt Nach Rücksprache mit meinem Manager möchten wir Dein Angebot nicht annehmen, würden dir aber Logdateien übermitteln können.

Was hab ich gestern anders gemacht?

  • Die Idee war, die produktiven Sites auf neue Sites zu kopieren.
  • Mit Ausnahme der monitoring2 Site (“Lokal”) wurden
    • im distributed Monitoring alle Sites disabled.
    • auf allen Sites die Notifications abgedreht Ja, nur die Notifications :slight_smile:
  • Die produktiven Sites wurden alle gestoppt
  • Die 2 relevanten Sites wurden kopiert
  • Die kopierten Sites wurden upgegraded und gestartet.
    • Das Passwort musste geändert werden.
    • in der Multisite-Konfig wurde versucht die kopierte Site als neu anzulegen.
      Hier sollte das Passwort in der GUI eingegeben werden, es war nicht möglich
      hier eine Authentifizierung zu erreichen - auch nicht via CLI nach setzen des Passwortes mit cmk_passwd auf beiden Sites.
    • Auch kam es auf der lokalen Site monitorig2 (die “Viewer” Site) zu Vermischungen zwischen produktiv und kopiert.
    • Da dies beides nicht funktionierte, wurden beide kopierten Sites gelöscht und die produktiven Sites erneut aus dem morgendlichen Backup restauriert und geupdatet.
    • Dies war der 8. Versuch - Die grosse produktive Site “woext” lief nun plötzlich an.

Dies ist alles was ich dazu noch beitragen kann, vielen Dank an alle die geantwortet haben.

Hi,
vielleicht bist du unter anderem bei deinem omd cp auch in diese Problematik gelaufen:

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.