2011-10-24 13 views
7

Od dwóch lat prowadzę nagios, ale ostatnio ten problem zaczął się pojawiać w jednej z moich usług.Nagios: CRITICAL - Czas oczekiwania na gniazdo po 10 sekundach

Dostaję

CRITICAL - Socket timeout after 10 seconds 

do kontroli check_http -H my.host.com -f follow -u /abc/def, który kiedyś pracował w porządku. Żadne inne usługi nie zgłaszają tego problemu. Zdalna witryna jest sprawna i zdrowa, a ja mogę wykonać numer wget http://my.host.com/abc/def z serwera Nagios, i to ładuje odpowiedź w porządku. Ponadto, wykonanie check_http -H my.host.com -f follow działa dobrze, tj. Tylko wtedy, gdy używam argumentu -u, że coś się psuje. Próbowałem również przekazać mu inny ciąg agenta użytkownika, bez różnicy. Próbowałem zwiększać limit czasu, bez powodzenia. Próbowałem z -v, ale wszystko to jest:

GET /abc/def HTTP/1.0 
User-Agent: check_http/v1861 (nagios-plugins 1.4.11) 
Connection: close 
Host: my.host.com 


CRITICAL - Socket timeout after 10 seconds 

... co nie mówi mi, co się dzieje.

Jakieś pomysły, w jaki sposób mogę rozwiązać ten problem?

Dzięki!

+0

Czy próbowałeś dodanie '-4' lub' -6' do opcji check_http? Miałem już ten problem, zanim musiałem wymusić IPv4 dla czeku. – Starfish

+0

Dzięki, spróbowałem. Przy "-4" pojawia się ten sam błąd. Z '-6' otrzymuję: Nazwa lub usługa nieznana HTTP CRITICAL - Nie można otworzyć gniazda TCP – fulv

+0

Czy możesz opublikować wyjście swojego wget? Zakładam, że od kiedy używasz, obserwuj, że docelowy adres URL wykonuje przekierowanie. – Starfish

Odpowiedz

15

Spróbuj użyć opcji -N z check_http.

Wystąpiły podobne problemy, aw moim przypadku serwer WWW nie zakończył połączenia po wysłaniu odpowiedzi (https działał, nie było http). check_http próbuje odczytać z otwartego gniazda, dopóki serwer nie zamknie połączenia. Jeśli to się nie stanie, nastąpi przekroczenie limitu czasu.

Opcja -N mówi check_http o otrzymaniu tylko nagłówka, ale nie treści strony/dokumentu.

+1

Dziękuję, w końcu mój serwis nie jest w stanie "problem" już! – fulv

+1

Pozdrowienia za rozwiązanie, jednak połączenia nie są zakończone jest oznaką możliwego problemu w stosie. Czy OP może skomentować, jaka zmiana spowodowała tę zmianę, jeśli jest znana? – cosimo

+0

Miał ten sam problem i było spowodowane "optymalizacją" urządzenia sieciowego. – Vegard

1

Śledziłem mój problem do problemu z dostawcami zabezpieczeń skonfigurowanymi w najnowszej wersji OpenSUSE.

Z podsumowania innych stron internetowych wynika, że ​​problem polega na próbie użycia protokołu TLSv2, który wydaje się nie działać poprawnie lub brakuje czegoś w domyślnych konfiguracjach, aby umożliwić jego działanie.

Aby rozwiązać problem, skomentowałem danego dostawcę zabezpieczeń z pliku konfiguracyjnego zabezpieczeń JRE.

#security.provider.10=sun.security.pkcs11.SunPKCS11 

Zabezpieczający. wartość może być inna w konfiguracji, ale zasadniczo chodzi o dostawcę SunPKCS11.

Taka konfiguracja jest zwykle znaleźć w

$JAVA_HOME/lib/security/java.security 

na JRE, którego używasz.

0

Usunięto z tym adresem w nrpe.cfg (na Deb 6.0 Squeeze użyciem Nagios-NRPE serwer)

command[check_http]=/usr/lib/nagios/plugins/check_http -H localhost -p 8080 -N -u /login?from=%2F 
Powiązane problemy