"Ghost-Hosts" bei Distributed Monitorig

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

    ich habe ein paar abartige check_mk-Stunden hinter mir, die ich mir nicht erklären kann, und hoffe, ihr könnt mir helfen, was da passiert ist.


    Ich habe letzte Woche eine komplett neue Check_mk-Instanz aufgebaut. Debian 9, check_mk-raw 1.4.0p8, installiert als VM auf VMWare vSphere 6.5. Anfangs hatten wir nur einen Standort, da wir aber interkontinental Systeme eingebunden haben, ging die Performance in den Keller. Deshalb haben wir jetzt zwei Slave-Instanzen, Wato ist auf den Slaves deaktiviert. Dann war erstmal alles gut.

    Heute mittag habe ich ein Log-Pattern eingetragen, die Änderung übernommen und für 2 Minuten das Büro verlassen. Als ich zurück kam waren von ca. 120 Host 100 als Down angezeigt, die anderen 20 hatten 80 bis 100% Ping-Verluste. Die Systeme waren aber alle erreichbar, auch von check_mk aus, auch wenn ich check_mk manuell aufgerufen habe wurde die Hosts gefunden.

    Bei der Recherche habe ich dann festgestellt, dass eine sehr große Zahl an Hosts doppelt vorhanden war: einmal an dem Standort, an dem er sein sollte - dort war er grün, alle Services sind da. Und dann nochmal auf einer anderen Site, dort war nur ein Service vorhanden (Ping) und der war rot. Wenn ich versucht habe, den "falschen" host zu löschen, wurde gemeldet, dass er nicht gelöscht werden kann, weil er nicht existiert.

    Ich habe dann ein Backup von 02.00 Uhr eingespielt (der Fehler ist erst 11 Stunden später aufgetaucht), nach wenigen Minuten hatte ich aber genau das gleiche Bild wie zuvor. Ich habe dann auf dem Master-Server zuerst die Site gelöscht und per altem Backup neu eingespielt, weil das nix gebracht hat sogar omd mit "purge" entfernt, neu installiert und das Backup eingespielt, hatte aber jedes Mal das gleiche Ergebnis.

    Dann habe ich die Slave-Sites abgemeldet und dann nochmal ein Backup eingespielt - siehe da, aller lokalen host werden erfolgreich angezeigt. Sobald ich die beiden Slaves wieder eingeschaltet habe, kamen die Fehler zurück.

    Letztlich konnte ich es nur dadurch beheben, dass ich auf allen drei Servern die Sites entfernt habe, die MasterSite per Backup wieder eingespielt und die anderen Sites von Hand neu erstellt habe (hier sind mir jetzt leider meine PErf-Daten flöten gegangen...). Es funktioniert jetzt wieder alles, mich interessiert aber, was da passiert ist.


    Die einzige Änderung, die ich meines Wissens und auch nach den Logs gemacht habe, waren neue Patterns in der Logwatch regel. Was gleichzeitig offensichtlich passiert ist: vSphere 6.5 unterstützt "Large Receive Offset", was aber in Verbindung mit den virtuellen vmxnet3-Netzwerkkarten und Linux probleme verursacht: man muss das ausschalten, sonst riskiert man bei zu viel Traffic, dass die komplette Maschine einfriert und nicht mehr reagiert. Das habe wir in den letzten Tagen entdeckt, haben das dann auf dem Interface ausgeschalten, aber dann gemerkt, dass sich das automatisch immer wieder von selbst aktiviert. Das bringt dann den Server nach wenigen Minuten eben wieder zum Absturz. Genau das scheint in dem Moment passiert zu sein, als die komischen Geister-Hosts aufgetaucht sind und alles auf DOWN ging. Bei den Slave-Servern haben wir das Problem nicht, der eine läuft auf vSphere 5.5, der andere auf vmware Workstation 9.


    Das Problem ist jetzt wie gesagt erstmal behoben, deshalb keine Eile. Mich interessiert aber, ob jemand eine erklärung hat, wie das passieren konnte und wie wir uns in zukunft davor schützen. Ich habe vor dem ganzen einige neue Hosts eingetragen und einige Einstellungen vorgenommen, die jetzt natürlich weg sind, ganz zu Schweigen von den Perfdaten auf den Slaves (ich hatte nicht daran gedacht, dass ich die extra sichern muss...).



    Freue mich auf das Brainstorming und jeden nützlichen Hinweis!


    Schöne GRüße


    Tobias