CRITICAL - Socket timeout after 10 seconds

General
1

Hallo Forum

Ich benutze die 1.6.0.p16 raw version, mit verschiedenen Sites.

Für einen Host den ich als “status host” für eine site connection definiert habe bekomme ich immer wieder den Alarm “ CRITICAL - Socket timeout after 10 seconds “.

In den Parameters ist der Wert für “ Agent TCP connect timeout “ auf 60 Sekunden eingestellt

Wo kann ich die Zeit für den “socket timeout alarm” einstellen ?

Dasselbe für den Service des gleichen Host. Ich habe prüfe den TCP port 80 als active check, mit einem connection timeout von 60 Sekunden.

Wo kann ich diese timeout Werte einstellen ?
Wieso fassen die in Wato konfigurierten Werte nicht?

Vielen Dank für euer Feedback

Stefano

2

Vermutlich handelt es sich bei den 10 Sekunden um einen sogenannten Read Timeout.

Dieser Alarm … ist das ein Host Check oder ein Service Check? Welcher wird genau verwendet?

PS: Hier sind die verschiedenen Timeouts relativ gut erklärt.

3

Hi Simon

Danke für den Link !!!

Als host check command benutze ich den “TCP connect” zu port “80”.
Als service check command “check_mk_active-tcp! -p 80 -t 60 -H ‘$HOSTADDRESS$’”

Der Alarm tritt bei beiden auf.

4

Ja, wie gesagt, die eingestellten 60 Sekunden (-t) sind nur für den Connect Timeout, also Wartezeit bis die TCP Verbindung aufgebaut ist.
Irgendwas ist allerdings definitiv b0rken, denn die Antwortzeiten zb. jetzt mal vergleichweise von meinen Checks sehen so aus:

image
image1306×96 16.1 KB

Also ich prüf halt auf 6557 statt wie du auf 80.

5

Ich habe gestern noch auf den port 6557 umgestellt.

Dies hat aber keine Verbesserung gebracht.

DIe Verbindungen zum Master sind alle 3G Anbindungen.
Scheinbar, wenn keine kontinuirliche Kommunikation stattfindet, haben die ersten Daten eine ziemlich grosse Latenzzeit.
Ich habe mal versucht per ping eine Grundlast zu erzeugen. Siehe da, von 500ms oder mehr fällt die Antwortzeit auf ca konstante 80ms.
Wenn ich den ping Intervall auf 3 oder mehr Sekunden erhöhe fällt der Nutzen weg, die Antwortzeit fällt zurück auf 500ms oder mehr.
Als ein möglicher Lösungsanzatz sehe ich eine kontinuirliche Grundlast.
Ich werde dies mal über eine längere Zeit prüfen.

6

Ohje 3G…das hättest du aber auch ruhig mal erwähnen können. :wink:

1 Like
7

Ich würde nie eine Site per Livestatus direkt über 3G/LTE oder sonst eine nicht verlässliche Verbindung anbinden.
Hier solltet ihr euch eine andere Anbindung mal anschauen wie zum Beispiel Livedump/CMCdump.

8

Sorry wegen den 3G, meine Frage war / ist wo ich an diesem “socket timeout” level rumschrauben kann.

Dass 3G/LTE mit openvpn die Ursache für den Alarm und nicht die beste Wahl der Kommunikation ist. ist mir klar, aber eine Alternative steht nicht zur Verfügung.

Die Seiten sollten Zentral konfiguriert werden können, das Alerting ist dezentral.
Livedump/CMCdump erlaubt mir keine Zentrale konfiguration.

Bitte nicht schlagen, aber mein Workarround, eine Grundlast zu erzeugen, scheint zu funktionieren.
Zusätzlich werde ich mit dem 3G/LTE Anbieter in Kontakt treten und nach einer besseren Lösung suchen.

9

Du kannst natürlich mal ein bisschen an den Settings noch rumspielen, es gibt ja zb. auch die Möglichkeit die Livestatus Verbindung auf “persistent” zu stellen. Das kann eine Verbesserung bringen, muss aber nicht…

Und auf dem Livestatus Port (6557) sollte generell mehr “Backgroundtraffic” sein, als auf dem 80er.

10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.