Debian NSClient++；来自Icinga的用于Windows Server 2012的NRPE的命令

我已经研究这个问题好几天了，但我找不到解决办法。 我的Windows 2012服务器上安装了NSClient++。我还有一个安装了Nagios NRPE插件的Icinga服务器。此外，NSClient++配置为接受NRPE命令，并设置“allow arguments=1”。 从Icinga服务器，当我给出以下输入时：

/usr/lib/nagios/plugins/check\u nrpe-H 192.168.1.22-c alias\u cpu

它给出了： 正常CPU负载正常。|'5m'=27%；80;90‘1m’=26%；80;90'30秒'=26%；80;90

因此，一切看起来都很好，但从Icinga Web界面上，我发现以下错误： /usr/lib/nagios/plugins/check\nrpe:option需要一个参数--“a”

看起来我就是不能正确地使用命令。我尝试了我在互联网上找到的每一个命令，但没有一个可以正常工作。此外，NRPE的NSClient文档已经过时，因为他们说您应该使用check\u nt，但是该命令已经被弃用一年多了，所以我应该使用check\u NRPE，但这不起作用

因此，我在/etc/icinga/objects中创建了一个.cfg文件，目前正在使用以下命令：

define host{
       use windows-servers
       host_name host.domain.com
       alias host
       address 192.168.1.22
}

define service{
        use                             generic-service
        host_name                       host.domain.com
        service_description             Drive Usage
        check_command                   check_nrpe!alias_disk
        }


define service{
        use                     generic-service
        host_name               host.domain.com
        service_description     CPU Load
        check_command           check_nrpe!alias_cpu
}

在Windows服务器上，nsclient.ini中的设置如下：

[/settings/NRPE/server]
allowed hosts=172.16.0.7
allow arguments=1
port=5666
allow nasty_meta chars=1 
use SSL = 1

有人知道这里出了什么问题吗？我现在完全没有选择了。 我发出错误的命令了吗？有人知道正确的命令吗？还是我做错了什么？

---

谢谢

在Icinga/Nagios论坛的帮助下，我发现define_命令是这样的：

# this command runs a program $ARG1$ with arguments $ARG2$
define command {
        command_name    check_nrpe
        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$
}

# this command runs a program $ARG1$ with no arguments
define command {
        command_name    check_nrpe_1arg
        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

应该是这样的：

# this command runs a program $ARG1$ with arguments $ARG2$
define command {
        command_name    check_nrpe_1arg

        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$
}

# this command runs a program $ARG1$ with no arguments
define command {
        command_name    check_nrpe
        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

---

只交换了两行，但花了我几天的时间才找到。但幸运的是，它现在已经解决了。

在Icinga/Nagios论坛的帮助下，我发现define_命令是这样的：

# this command runs a program $ARG1$ with arguments $ARG2$
define command {
        command_name    check_nrpe
        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$
}

# this command runs a program $ARG1$ with no arguments
define command {
        command_name    check_nrpe_1arg
        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

应该是这样的：

# this command runs a program $ARG1$ with arguments $ARG2$
define command {
        command_name    check_nrpe_1arg

        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ -a $ARG2$
}

# this command runs a program $ARG1$ with no arguments
define command {
        command_name    check_nrpe
        command_line    /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
}

---

只交换了两行，但花了我几天的时间才找到。但幸运的是，它现在已经解决了。

这已经有几个月了，但我想加入进来

切换check\u nrpe和check\u nrpe\u 1arg的命令定义不是最佳解决方案。check_nrpe用于传递外部命令及其命令行选项，check_nrpe_1arg用于仅传递外部命令（这是您正在尝试执行的操作）

对于您的用例，最好的解决方案是保持check\u nrpe和check\u nrpe\u 1arg命令定义不变，并更改服务定义以使用正确的命令：

define service{
    use                             generic-service
    host_name                       host.domain.com
    service_description             Drive Usage
    check_command                   check_nrpe_1arg!alias_disk
    }


define service{
    use                             generic-service
    host_name                       host.domain.com
    service_description             CPU Load
    check_command                   check_nrpe_1arg!alias_cpu
}

另一方面，如果希望将命令行选项传递给nrpe，则可以使用check\u nrpe命令。像这样：

define service {
     use                            generic-service
     host_name                      host.domain.com
     service_description            Check SMART status of sda
     check_command                  check_nrpe!check_smart!/dev/sda
     }

（假设在nrpe.cfg中定义了以下check_smart命令）：

---

这是几个月前的事了，但我想加入进来

切换check\u nrpe和check\u nrpe\u 1arg的命令定义不是最佳解决方案。check_nrpe用于传递外部命令及其命令行选项，check_nrpe_1arg用于仅传递外部命令（这是您正在尝试执行的操作）

对于您的用例，最好的解决方案是保持check\u nrpe和check\u nrpe\u 1arg命令定义不变，并更改服务定义以使用正确的命令：

define service{
    use                             generic-service
    host_name                       host.domain.com
    service_description             Drive Usage
    check_command                   check_nrpe_1arg!alias_disk
    }


define service{
    use                             generic-service
    host_name                       host.domain.com
    service_description             CPU Load
    check_command                   check_nrpe_1arg!alias_cpu
}

另一方面，如果希望将命令行选项传递给nrpe，则可以使用check\u nrpe命令。像这样：

define service {
     use                            generic-service
     host_name                      host.domain.com
     service_description            Check SMART status of sda
     check_command                  check_nrpe!check_smart!/dev/sda
     }

（假设在nrpe.cfg中定义了以下check_smart命令）：

经过一些认真的调试后，我发现（在ICinga2上测试）将check命令的参数拆分为不同字符串的方式会影响它们传递给子进程的方式。这可能是一个非常大的问题，具体取决于子进程如何在内部处理命令行参数。下面是一个特别棘手的现实例子：

object CheckCommand "cc-cisco-interface-status" {
  import "plugin-check-command"

  command = [ PluginDir + "/check_snmp_ifname.sh",
             "-H", "$host.address$",
             "-P 2c",
             "-C", "$host.vars.snmpcommunity$",
             "-o", "IF-MIB::ifOperStatus",
             "-IF", "$service.vars.ifname$"
            ]

因此，通过此命令，子进程将接收：

$1 = -H
$2 = 1.1.1.1
$3 = -P 2c
$4 = -C
$5 = MyCommunity
$6 = -o
$7 = IF-MIB::ifOperStatus
$8 = -IF
$9 = Serial0/0/0:0

这让我们发疯，比如说

             "-IF", "$service.vars.ifname$"
$8 = -IF
$9 = Serial0/0/0:0

工作时

             "-IF $service.vars.ifname$"
$8 = -IF Serial0/0/0:0

没有

但我认为，一旦您了解了正在发生的事情，这将成为一个可管理的问题（甚至很方便，因为它可以让您非常好地控制带引号的字符串）。

关于我发现的东西（在Icinga 2上测试）经过一些认真的调试之后，您将check命令的参数拆分为不同字符串的方式会影响它们传递给子进程的方式。这可能是一个非常大的问题，具体取决于子进程如何在内部处理命令行参数。下面是一个特别棘手的现实例子：

object CheckCommand "cc-cisco-interface-status" {
  import "plugin-check-command"

  command = [ PluginDir + "/check_snmp_ifname.sh",
             "-H", "$host.address$",
             "-P 2c",
             "-C", "$host.vars.snmpcommunity$",
             "-o", "IF-MIB::ifOperStatus",
             "-IF", "$service.vars.ifname$"
            ]

因此，通过此命令，子进程将接收：

$1 = -H
$2 = 1.1.1.1
$3 = -P 2c
$4 = -C
$5 = MyCommunity
$6 = -o
$7 = IF-MIB::ifOperStatus
$8 = -IF
$9 = Serial0/0/0:0

这让我们发疯，比如说

             "-IF", "$service.vars.ifname$"
$8 = -IF
$9 = Serial0/0/0:0

工作时

             "-IF $service.vars.ifname$"
$8 = -IF Serial0/0/0:0

没有

但我认为，一旦您了解了发生了什么，这就变成了一个可管理的问题（甚至是方便的，因为它为您提供了对引用字符串的一些非常好的控制）