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

я запускаю 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 работает просто отлично, т. е. это только когда я использую

7
nagios

4 ответов

попробуйте использовать на check_http.

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

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

15

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

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

для решения проблемы я закомментировал поставщика безопасности в вопрос настройки безопасности среды JRE файл.

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

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

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

$JAVA_HOME/lib/security/java.security

JRE, который вы используете.

1

исправлено с помощью этого url-адреса в nrpe.cfg: (на Deb 6.0 сожмите с помощью nagios-nrpe-server)

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

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

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

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

0