У меня проблема с NRPE, все, что я нашел в сети, похоже, указывает мне на то, что я уже пробовал.
# /usr/local/nagios/plugins/check_nrpe -H nrpeclient
дает
NRPE v2.12
как и ожидалось.
Выполнение команды вручную (как определено в nrpe.cfg для "nrpeclient", дает ожидаемый ответ
nrpe.cfg:
command[check_openmanage]=/usr/lib/nagios/plugins/additional/check_openmanage -s -e -b ctrl_driver=0 bat_charge
"Expected response"
Но если я попытаюсь запустить команду с сервера Nagios, я получу следующее:
# /usr/local/nagios/plugins/check_nrpe -H comxps -c check_openmanage
NRPE: Unable to read output
Может ли кто-нибудь вспомнить, где еще я мог бы ошибиться с этим? Я сделал то же самое на нескольких других серверах без проблем. Единственное отличие, которое я могу придумать, заключается в том, что этот блок основан на RHEL 5, тогда как другие основаны на RHEL 4.
Те две части, которые я тестировал выше, - это то, что, кажется, предлагает большинство людей, когда у людей была эта проблема.
Я должен упомянуть, что при перезапуске я получаю странную ошибку в журналах nrpe:
nrpe[14534]: Unable to open config file '/usr/local/nagios/etc/nrpe.cfg' for reading
nrpe[14534]: Continuing with errors...
nrpe[14535]: Starting up daemon
nrpe[14535]: Warning: Daemon is configured to accept command arguments from clients!
nrpe[14535]: Listening for connections on port 5666
nrpe[14535]: Allowing connections from: bodbck,combck,nam-bck
Хотя это явно читается /usr/local/nagios/etc/nrpe.cfg файл, чтобы получить информацию о том, о чем идет речь.
У вас проблема с правами.
Измените команду на:
command[check_openmanage]=sudo /usr/lib/nagios/plugins/additional/check_openmanage -s -e -b ctrl_driver=0 bat_charge
(добавить sudo)
Затем добавьте пользователя nagios в sudoers:
nagios ALL=(ALL) NOPASSWD:/usr/lib/nagios/plugins/additional/check_openmanage
Или вы можете просто изменить файл ... Это тоже работает.
Если вы используете CentOS, Red Hat, Scientific или Fedora, обязательно отключите Defaults requiretty в файле sudoers.
Краткий ответ: если вы используете плагин Bash, убедитесь, что у вас есть Shebang указание, какой интерпретатор следует использовать: #!/bin/bash
Я столкнулся с той же проблемой с плагином Nagios, который я написал сам. Сценарий выполнялся должным образом при запуске локально, даже если выполнялся как пользователь. nagios используя следующий оператор:
$ sudo sudo -s -u nagios
$ /path/to/my/plugin.sh
STATUS: OK
Но удаленный запуск с помощью NRPE с сервера Nagios3 не увенчался успехом:
$ /usr/lib/nagios/plugins/check_nrpe -H my-nagios-client -c my_plugin
NRPE: Unable to read output
Я наконец решил этот случай, добавив Shebang в моем сценарии, поскольку оказалось, что запуск сценария через NRPE не использовал тот же интерпретатор, что и при запуске через sudo sudo -s -u nagios.
В моем случае проблема была просто - пользователь нагиос не удалось выполнить сценарий. После chmod все заработало. Судо не нужно. Это даже зло :)
check_nrpe получал "NRPE: Unable to read output", несмотря на то, что проверка работала локально, потому что плагин, который я использовал, не работал с SELinux. Отключите его и обязательно удалите контексты файла:
$ ls -l check_om_storage
-r-xr-xr--. 1 root nrpe 3808 Feb 27 17:54 check_om_chassis
$ setfattr -x security.selinux check_om_storage
$ ls -l check_om_chassis
-r-xr-xr-- 1 root nrpe 3808 Feb 27 17:54 check_om_chassis
В моем случае отказал только один плагин, а несколько других работали нормально. Оказалось, что это ЛОКАЛЬНАЯ проблема.
Плагин был check_mem.sh и он выполнил команду grep для Mem на выходе free. Но вернулась общесистемная LOCALE Speicher (Немецкий) вместо Mem, поэтому все полученные значения были пустыми строками.
Проверьте путь, разрешения, selinux, iptables.
У меня была проблема с путём в client: nrpe.cfg, дважды проверьте путь команды к имени плагина check_ *. Это может сбивать с толку (lib / local) (libexec / plugins) в качестве пути. Я по ошибке выдернул и поместил пути из предварительно запакованного cfg файла nrpe с комментариями для создания команд. При установке плагина make install или yum они помещаются в другой каталог.
управляемый: / usr / local / nagios / libexec / check_disk
против
реальный путь: / usr / lib / nagios / plugins / check_disk
С сервера я смог подтвердить, что это не проблема с брандмауэром, мог подключиться к порту 5666 по telnet, мог запустить blanket check_nrpe и получить статус в качестве возвращаемого значения. Могли запускать команды локально, но nrpe имел неправильный путь на клиенте в nrpe.cfg.
Это проблема с разрешением, просто дайте скрипту право на выполнение, и все будет в порядке:
вот пример: До / Удаленный хост:
[root@puppet1 nrpe.d]# ls -l /usr/lib/nagios/plugins/check_mem.sh
-rwxr--r-- 1 root root 1598 Jul 7 10:55 /usr/lib/nagios/plugins/check_mem.sh
NRPE сервер :
[root plugins]# ./check_nrpe -H 172.19.9.200 -c check_mem_vb
NRPE: Unable to read output
После : Удаленный узел :
[root@puppet1 plugins]# chmod o+x /usr/lib/nagios/plugins/check_mem.sh
[root plugins]# ./check_nrpe -H 172.19.9.200 -c check_mem_vb
Memory: OK Total: 1980 MB - Used: 139 MB - 6% used|Total=2076479488;;;Used=145076224;;;Cache=1528111104;;Buffer=211890176;;;
Проблема решена.
В моем случае проблемы были связаны с selinux (запущен RHEL 6.5, selinux настроен на принудительное исполнение).
Установка nagios-plugins- * через yum создаст ваши файлы плагинов в / usr / lib64 / nagios / plugins. Если вы проверите fcontext в этих файлах плагина (ls -lZ), вы увидите, что для файлов установлен тип контекста "nagios_system_plugin_exec_t", который является типом контекста, который ожидает check_nrpe.
В моем случае я создал собственный сценарий «check_mem.sh» с использованием «vi». Результирующий файл имел тип контекста, установленный на «lib_t». Это заставляло nrpe выводить сообщение «NRPE: Unable to read output».
Изменение контекста файла на «nagios_system_plugin_exec_t» решило проблему:
chcon -t nagios_system_plugin_exec_t /usr/lib64/nagios/plugins/check_mem.sh
Обычное устранение неполадок с selinux также указывало бы мне на эту проблему (проверка /var/log/audit/audit.log), но, конечно, это было последнее, о чем я думал
Изменить: chcon просто временно изменяет контекст. Чтобы постоянно его менять, используйте semanage fcontext -a -t nagios_system_plugin_exec_t /usr/lib64/nagios/plugins/check_mem.sh
restorecon -vF /usr/lib64/nagios/plugins/check_mem.sh
В случае пользовательских плагинов NRPE обязательно распечатайте какой-либо вывод вместе со значением выхода. Если нет вывода из сценария, NRPE будет жаловаться, говоря «NRPE не может прочитать вывод». Вы можете включить отладку в nrpe.cfg и наблюдать за этой ошибкой.
В моем случае отслеживаемый файл журнала принадлежал root: adm, поэтому добавление пользователя nagios в группу adm сделало команду check_log успешной, но только при выполнении непосредственно на отслеживаемых хостах. Он продолжал терпеть неудачу при использовании check_nrpe на сервере Nagios, пока я не перезапустил службу nagios-nrpe-server на наблюдаемых хостах, например
service nagios-nrpe-server restart
Таким образом, очевидно, что перезапуск службы был необходим, чтобы изменение разрешений вступило в силу для NRPE, но мне потребовалось время, чтобы понять это.
Только что возникла эта проблема на FreeBSD. После того, как в течение часа бился головой о стену, я понял, что проблема в том, что /usr/local/nagios/etc/nrpe.cfg указывал не на то место для sudo.
Чтобы найти правильное место для выполнения команды sudo:
# whereis sudo
Затем я изменил command_prefix в nrpe.cfg с:
command_prefix=/usr/local/sudo
кому:
command_prefix=/usr/local/bin/sudo
Затем побежал service nrpe restart и проблема была решена.
Может быть аналогичная проблема в других операционных системах, просто еще одна вещь, чтобы проверить, проверили ли вы все другие возможные проблемы с разрешениями, и вы все еще сталкиваетесь с этой проблемой.
У меня была такая же проблема, и мне удалось ее решить, убив процесс nagios (на контролируемой машине):
ps -ef | grep nagios
kill -9 [NagiosProcessNumber]
/etc/init.d/nagios-nrpe-server start
После этого все прошло нормально.
Еще одна вещь, которую следует проверить, это то, что если ваша команда использует sudo -u <another user> чтобы запустить команду, libexec каталог (и каталоги над ним) должен быть доступен для чтения пользователю, к которому выполняется sudoed.
Например, если ваша команда:
command[check_tomcat]=sudo -u tomcat /usr/local/nagios/libexec/check_tomcat ...
Пользователь tomcat должен иметь доступ к этому файлу.
Один из способов исправить это:
chmod 0775 /usr/local/nagios/
chmod 0755 /usr/local/nagios/libexec
Замена последней части на место, где живут ваши исполняемые файлы
Обычно это происходит, когда сервер NRPE запускается с пользователем nrpe, а не nagios.
Изменение nrpe_user ценность в нагиос в /etc/nagios/nrpe.cfg файл должен решить вашу проблему.
В nrpe_group при необходимости можно изменить.
Есть действительно хорошая статья, которая охватывает всю установку и настройку агента NRPE с множеством примеров check_commands. Я использую эту статью, когда мне нужно установить NRPE на новый сервер. Более того, в конце страницы вы можете найти классный скрипт, который автоматически устанавливает и настраивает NRPE для вас (в зависимости от заданных вами переменных), можно найти статью: Вот
У меня возникла проблема, что ты пишешь. Я провел тест на Perl. Поместите эту строку в файл /etc/nagios/nrpe.cfg чтобы заставить его работать.
command [check_memory] = /usr/bin/perl /usr/lib64/nagios/plugins/check_memory -w 75-c 90
Я думаю, вы должны добавить плагины в свой локальный каталог /usr/lib64/nagios/plugins/*. У меня была та же проблема, что и у вас, и я могу решить ее с помощью этого решения.
Возможно, вы не установили плагины Nagios, NRPE не может их найти или получить к ним доступ.
Мне никогда не приходилось добавлять свои команды в Sudoers. Убедитесь, что команды принадлежат пользователю Nagios и их можно читать.
Отсутствуют плагины Nagios на клиенте nrpe.
Не используйте yum install nagios-plugins (nagios-plugins-2.0.3-1.el6.x86_64). Он не устанавливает все плагины. Загрузите nagios-plugins-1.4.11.tar.gz и следуйте инструкциям в этом документе.
http://www.thegeekstuff.com/2008/06/how-to-monitor-remote-linux-host-using-nagios-30/
У меня была эта проблема, и я решил отключить selinux
setenforce 0