Nagios: CRITICAL - Тайм-аут сокета через 10 секунд - PullRequest
Новая
       10

Nagios: CRITICAL - Тайм-аут сокета через 10 секунд

7 голосов
/ 24 октября 2011

Я запускаю nagios около двух лет, но недавно эта проблема стала появляться с одним из моих сервисов.

Я получаю 

CRITICAL - Socket timeout after 10 seconds

за check_http -H my.host.com -f follow -u /abc/defпроверьте, что раньше работало нормально.Другие службы не сообщают об этой проблеме.Удаленный сайт работает и исправен, и я могу сделать wget http://my.host.com/abc/def с сервера nagios, и он прекрасно загружает ответ.Кроме того, выполнение check_http -H my.host.com -f follow работает просто отлично, то есть только когда я использую аргумент -u, что-то ломается.Я также попытался передать ему другую строку агента пользователя, без разницы.Я пытался увеличить время ожидания, не повезло.Я попытался с -v, но все, что он получил, это: 

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

... что не говорит мне, что происходит не так.

Есть идеи, как я мог бы решить эту проблему?

Спасибо!

Ответы [ 4 ]

16 голосов
/ 20 декабря 2011

Попробуйте использовать -N параметр check_http.

Я столкнулся с подобными проблемами, и в моем случае веб-сервер не разорвал соединение после отправки ответа (https работал, http не работал). check_http пытается читать из открытого сокета, пока сервер не закроет соединение. Если этого не произойдет, то произойдет тайм-аут.

Опция -N указывает check_http получать только заголовок, но не содержимое страницы / документа.

1 голос
/ 15 апреля 2014

Я отследил свою проблему до проблемы с поставщиками безопасности, настроенными в самой последней версии OpenSUSE.

Из сводки других веб-страниц, похоже, проблема с попыткой использовать протокол TLSv2, которыйне работает должным образом или в конфигурациях по умолчанию отсутствует что-то, что позволяет ему работать.

Чтобы решить эту проблему, я закомментировал рассматриваемого поставщика безопасности из файла конфигурации безопасности JRE. 

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

Security.provider.значение может отличаться в вашей конфигурации, но, по существу, это проблема поставщика SunPKCS11.

Эта конфигурация обычно находится в 

$JAVA_HOME/lib/security/java.security

используемой вами JRE.

0 голосов
/ 02 марта 2017

Для тех, кто заинтересован, я тоже наткнулся на эту проблему, и проблема оказалась в mod_itk на веб-сервере.

Патч доступен, даже если кажется, что он не включен в текущие пакеты CentOS или Debian:

https://lists.err.no/pipermail/mpm-itk/2015-September/000925.html

0 голосов
/ 02 июня 2014

Исправлено с этим URL в nrpe.cfg: (на Deb 6.0 Squeeze с использованием nagios-nrpe-server) 

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