wir verwenden seit vielen Jahren CheckMK für unser Monitoring von Linuxservern, die in unterschiedlichen Rechenzentren laufen.
Seit einigen Monaten kommt es vermehrt zu Timeouts. Sei es bei den Check MK Agent Checks, check_http oder auch einfach nur nur den Pings.
Wenn Check MK z.B. meldet, dass seine Website per HTTP(S) einen Timeout liefert kann ich mir in 99,9% der Fälle sicher sein, dass dies ein Fehlalarm ist.
Ich nahm an, dass es vielleicht Probleme mit dem Netzwerk gibt, speziell dort wo die Monitoring VM läuft. Daher habe ich gestern eine zweite Instanz in ein zweites RZ gepackt, das zum selben Betreiber gehört wie das RZ in dem >80% unserer Server stehen.
Leider wurde es damit nicht besser sondern deutlich schlechter. Es geht kaum eine Minute in der nicht einer der >100Server einen Timeout liefert. Das Netzwerk zwischen den beiden RZs könnte besser nicht sein.
Auf der Konsole via telnet 1.2.3.4 6556 kann ich so oft wie ich will den Check ausführen und ich bekomme nie Timeouts. Auch Checks per HTTP (mit curl) schlagen manuell via Konsole nie fehl.
Mir fehlt gerade der Ansatz wie ich weiter vorgehen könnte um das Problem zu lokalisieren. Alle Systeme laufen mit Centos, bis auf wenige Ausnahmen mit CentOS 7. Alle Server sind virtualisiert.
Ich hoffe ihr könnt mir ein paar Hinweise geben, wie ich das Ganze debuggen und abstellen kann.
EDIT:
Ich habe eben mehrfach per telnet einen Host abgefragt und messe i.d.R. eine Laufzeit von 0,5-1sec. Manchmal 5-6sec, aber auch 2 mal 31sec und sogar 47sec. Es gibt also doch ein Problem, nur wie finde ich heraus ob’s am Netzwerk oder den VMs selbst liegt? Die abgefragte VM hat keinerlei Last.
Erste Frage wäre wie schaut der Monitoring Server selbst aus. Also CPU load und Utilization.
Hier vor allem mal drauf schauen ob es irgendwo I/O Probleme gibt.
Die manuellen Checks wurden von der Console des Monitoring Servers ausgeführt oder?
Der zweite (neue) Monitoringinstanz ist eine CentOS 7 VM mit 2 Cores / 8GB RAM.
Die Load liegt bei 0,1, CPU Usage punktuell bei 60-80% auf einem Core wenn Checks ausgeführt werden, normal aber bei eher 10-20%.
Erwähnenswert ist wahrscheinlich auch die Tatsache, dass ich in OMD ab und zu Timeouts zur zweiten Monitoringinstanz angezeigt bekomme.
Die manuellen Checks habe ich auf der Konsole von Instanz#2 ausgeführt.
Sicher, dass keine Firewall hier immer mal den Traffic abdreht?
Der Timeout bei den Agenten kommt der beim Connect oder das der Agent länger wie 60 Sekunden braucht zur Antwort?
Bei den Pings die selbe Frage ist dort der Fehler, dass alle Pakete verloren gehen oder “nur” hohe Antwortzeiten aber ohne Paketverlust?
Nachdem ich meine Erkenntnisse und Fragen in das Ticketsystem des RZ gekippt habe, kam kurz darauf eine Wartungsankündigung zur einer Notfallwartung aufgrund von Netzwerkproblemen.
Es scheint wohl tatsächlich ein Problem vorzuliegen dessen Symptome ich mittels CheckMK messe.
Ich habe heute knapp 2h MTR von der Instanz#2 zu einem überwachten Host laufen lassen. Der Paketloss bewegte sich bei den letzten 3 Hops um die 0,2-0,5%. Die Antwortzeiten lagen normal bei <40ms, aber in Abständen von ca 60sec bei 2000-3000ms.
Nun warte ich erstmal die Wartung ab, bevor ich selbst weitermache mit der Suche.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact @fayepal if you think this should be re-opened.
