Webgui ERROR: No response

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Webgui ERROR: No response

      Mahlzeit,

      habe im Moment das Problem das immer wieder mal willkürlich Dienste von einem Host in der Webgui als "Unknown" oder "Critical" angezeigt werden obwohl der Host und auch der Dienst erreichbar ist.
      Nach Auswertung der Logs ist auch alles in Ordnung, zu diesem Zeitpunkt ist lt. Webgui der Service auf Unknown und wird in dem Log aber als "OK" gekennzeichnet. (Der Dienst bleibt teilweise mehrere Stunden auf dem fehlerhaften Status) - Das betrifft aktuell von diesem Host z.B. nur 2 von 8 Dienste die per SNMP abgefragt werden.

      Hier ein Auszug aus den Logs (IP Adresse wurde entfernt)

      [Apr 04 2018 13:22:02] NOTICE 7511 0.000696 "ip adresse" start checking service id 217 command check-snmp status OK (host id 17) (/usr/share/perl5/Bloonix/Server.pm, line 803)

      auch der Flap Count ist auf 0

      [Apr 04 2018 13:22:02] NOTICE 7511 0.000057 "ip adresse" flap count 217 0 (host id 17) (/usr/share/perl5/Bloonix/Server.pm, line 1187)

      Service ID und Host ID stimmen, extra nochmals geprüft.

      Der Fehler ist nicht reproduzierbar und tritt bei zufälligen Hosts zu zufälligen Zeiten auf deshalb tappe ich gerade ein wenig im dunkeln :/

      Nach einen Reboot ist der Fehler wieder weg, tritt aber nach einer nicht näher definierbaren Zeit wieder auf.

      Vielleicht hat jemand eine Idee

      Grüße
      Daniel

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von DannyF ()

    • Hi,

      wenn der Fehler besteht würde ich mal wireshark / tcpdump auf dem betroffenen Hosts und Agent mit laufen lassen, um zu sehen wie die SNMP Antworten aussehen. Alternativ schau mal was passiert, wenn Du das check-snmp plugin über die CLI auf dem Agent ausführst. Ist der Ziel Host zufällig Multi-homed mit zwei default gateways und hat eine ECMP Konfiguration?

    • Guten Morgen,

      habe leider aktuell keinen Host wo das Problem auftritt, aber lt. meiner Erfahrung nach tritt das Problem sicher in den nächsten 2 Tagen wieder auf, dann kann ich den manuellen Check + Wireshark mal anwerfen.
      Jap trifft zu, multihomed Host mit mehreren Gateways, ob ECMP eingesetzt wird müsste ich mal unsere Netzwerker fragen, wäre aber schon möglich. Habe aber einige multihomed Hosts die ich seit über einen halben Jahr im Monitoring habe wo das Problem noch nie aufgetreten ist, befinden sich im selben Netz.
      Auffällig oft habe ich das Problem bei virtuellen Servern, physikalische betrifft es kaum.

      Grüße
      Daniel

    • Okay,

      mit ECMP meinte ich, ob die Default GW am Server die gleiche Metric haben und ein Loadbalancing gemacht wird. Meine These ist, dass der Server mit IP Adresse von z.B. eth0 per SNMP angefragt wird, jedoch aufgrund der Netzwerkkonfiguration mit der IP-Adresse der zweiten Schnittstelle (z.B. eth1) gelegentlich antwortet. In diesem Fall fährt die Antwort am Agent gegen die Wand. Aber schau Dir das mal per Wireshark an.

    • Der Ansatz ist gut, aber bin zufällig über etwas gestolpert. Ich konnte das Problem mittlerweile auf 2 ESX Hosts eingrenzen. Die letzten 3x wo der Fehler aufgetreten ist lief ein Database Backup Job auf einer der Maschinen, der Host ist schon relativ alt - hab mir mal den PerfMon angesehen des Hosts. Der Arbeitsspeicher ist stark überprovisioniert und die Maschine holt sich während des Jobs so viel Arbeitsspeicher vom Host das dieser komplett am Limit läuft - sobald der RAM vom Host vollgelaufen ist läuft zwar das Front End der Maschine normal schnell aber die Latenz von extern zum Host schwankt teilweise ziemlich.Meine Vermutung ist das die Latenzprobleme diese eigenartigen "Ausfälle" verursachen.

      Hast du zufällig eine Ahnung wie lange es dauert bis der check merkt das der Service nicht mehr erreichbar ist ?
      Habe die Arbeitsspeicher Aufteilung der Maschinen etwas verlagert, Auslagern sollte jetzt nicht mehr passieren, vielleicht behebt dass das Problem.

    • Geht es um ESXi Hosts, welche per SNMP überwacht werden? Wenn ja dann ist meine These mit den zwei Interfaces und Default Gateways hinfällig - dies würde auf Linux Hosts zutreffen.

      Hast du zufällig eine Ahnung wie lange es dauert bis der check merkt das der Service nicht mehr erreichbar ist ?


      Schau mal in den Service rein, wie der konfiguriert wurde. Standardmäßig prüft bloonix alle 60 Sekunden und wechselt in der GUI den Status von Ok in den Rückgabewert des Scripts, sollte etwas nicht in Ordnung sein. Nach 3 Fehlversuchen geht normal die Alarmierung raus.

    • Nein es geht um die virtuellen Maschinen auf dem Host - hab mich wohl ein wenig undeutlich ausgedrückt sorry.
      Es sind auch keine Linux Hosts sondern Windoof :D Bei den Checks ist überall der Standard-Wert eingestellt.

      Seit ich die RAM Aufteilung der virtuellen Maschinen geändert habe ist bis jetzt kein Fehler mehr aufgetreten, kann Zufall sein - werde da noch ein paar Tage abwarten um keine voreiligen Schlüsse zu ziehen.
      Danke schon mal für deine Hilfe!