KeyarchOS上nrpe-3.2.1-8安装配置：打通Nagios远程监控链路

监控这种东西，最怕的不是“没监控”，而是“以为监控了，实际一片黑”。很多团队把Nagios服务器端搭得风生水起，主机组、服务模板、告警通知全套配齐，结果被监控的KeyarchOS机器上压根没装采集组件，CPU跑满、磁盘报红、关键进程挂掉，Nagios那边一个告警都没弹出来。这就是典型的监控盲区。要堵上这个洞，最直接的做法是在每台被监控主机上部署nrpe（Nagios Remote Plugin Executor），由Nagios服务器通过check_nrpe插件主动拉取远程主机的实时指标。这篇文章就围绕nrpe-3.2.1-8在KeyarchOS上的安装配置，把从环境准备、编译安装、配置调优到服务端联调的完整流程讲透，适合正在维护Nagios监控体系、或者给KeyarchOS服务器搭基础设施监控的运维工程师参考，照着一步步做基本能一次跑通。

1. 为什么是nrpe：监控盲区的本质与选型逻辑

1.1 Nagios与nrpe怎么分工：一个调度者，一个执行者

先把基础概念理清楚：Nagios本身不产生监控数据，它是一个调度和展示框架。Nagios想知道远程主机的CPU负载是多少，中间必须有一个“触手”伸过去执行采集动作再拿回结果。nrpe就是这根触手，它以一个daemon进程的形式常驻在被监控主机上，默认监听5666端口。当Nagios服务器的check_nrpe插件连上来时，nrpe会在本地执行预先定义好的检查命令，比如check_load、check_disk、check_users，然后把执行结果和退出状态码（0=OK，1=WARNING，2=CRITICAL，3=UNKNOWN）返回给Nagios。Nagios根据返回值和文本决定怎么展示、要不要告警。

用生活化的类比就是：Nagios像物业监控室的保安，他要检查每层楼的消防通道是否畅通，但不可能每层楼都亲自跑，于是他在每层安排了一个协管员（nrpe）。保安通过对讲机（check_nrpe）问协管员“你那层怎么样？”，协管员跑去楼道看一眼，把结果报回来。这样保安不下楼，整栋楼的情况也尽在掌握。

这个架构最关键的地方在于：所有监控插件的执行动作都发生在被监控主机本地，Nagios只负责发号施令和接收结果。所以只要网络层放通一个5666端口，就能完成采集，不需要在被监控端额外开放SSH或者共享文件系统。这对企业内网几百台服务器的场景尤其友好。

1.2 几种远程采集方案的横向对比：为什么NRPE更省心

搞过监控的都知道，能采集远程指标的工具不止nrpe一个。我在不同项目里试过SNMP、NRDP/NSCA被动上报、还有直接SSH远程执行命令的方案，各有各的优势和坑。把主流方案放在一起看会比较清晰：

从我实际体感来说，几十台到几百台KeyarchOS服务器、网络环境可控、Nagios是监控核心，NRPE是投入产出比最高的方案。因为NRPE的插件都是Nagios生态的标准组件，配置模板和告警策略可以大批量复制，后期维护成本很低。不用像SNMP那样研究OID树，也不用像check_by_ssh那样维护大范围的免密SSH。

1.3 为什么盯上3.2.1-8这个版本：3.x带来了什么

nrpe目前主流是2.x和3.x两个大版本。3.x相比2.x有几个实质性的改进：默认启用SSL加密通信，不再明文传结果，避免了监控数据在网络里裸奔；配置指令更完善，支持守护插件级别更高的delegates用法；日志和调试信息更丰富，出问题好查；对启动参数和配置文件的检查更严格，能把低级错误早点暴露出来。

我选的nrpe-3.2.1-8是目前3.x系列里比较稳的一个版本。如果你生产环境已经有跑得很好的2.x，不一定非要升级，但如果是新部署，建议直接上3.x，省得以后为老版本的加密和稳定性问题返工。

这里必须提一个容易踩的坑：服务端的check_nrpe插件版本要尽量和被监控端的nrpe版本保持一致。我见过太多次服务端2.15、被监控端3.2的混搭，结果两边协议协商不上，报各种SSL错误，排查半天才发现是版本不匹配。这也是我在标题里突出版本号的原因，监控这套东西，版本对齐越严格，现场越省心。

2. 安装前准备：KeyarchOS环境与依赖

2.1 系统信息与架构确认：先把底盘看清楚

KeyarchOS是浪潮信息面向数据中心和云环境推出的企业级操作系统，整体生态和RHEL/CentOS一脉相承，发行版里自带yum/dnf包管理器。开始装nrpe之前，先确认系统状态：

cat /etc/os-release uname -m

第一条看系统版本和代号，第二条看CPU架构。nrpe源码安装对x86_64、aarch64这些常见架构都支持，但如果遇到非常冷门的架构，编译时可能碰上内联汇编或优化参数问题，这时候建议直接用系统包管理器装官方打包好的版本，别硬编译。

另外确认一下网络状态。如果服务器在纯内网环境，需要提前把nrpe源码包和依赖的RPM包上传到机器上，或者搭建内网软件源。别等到编译时才发现缺依赖包，那就有点狼狈了。

2.2 编译工具链与OpenSSL依赖：为什么省不掉

nrpe是C语言写的，源码包安装需要先准备编译工具链。KeyarchOS上执行：

yum install -y gcc make openssl-devel

重点说说openssl-devel为什么必须装：nrpe 3.x默认开启SSL/TLS加密，编译时如果没有OpenSSL头文件和静态库，configure阶段会直接报错，就算强行走下去，make的时候也会卡在SSL相关函数上。这个依赖包省不了。

装完可以用下面命令验证：

gcc --version openssl version

还有一点要留意：某些精简版系统可能缺少kernel-devel，多数情况下不影响nrpe编译，但后续如果要自己写内核模块类的监控插件，那就需要提前装上。

2.3 防火墙与SELinux：在入场前就把路修好

nrpe监听在5666端口，要确保防火墙放通这个TCP端口的入站连接。KeyarchOS如果用的是firewalld：

firewall-cmd --permanent --add-port=5666/tcp firewall-cmd --reload

如果用的是iptables，可以这样：

iptables -I INPUT -p tcp --dport 5666 -j ACCEPT service iptables save

SELinux这块我的建议是：生产环境不要图省事直接setenforce 0，而是先看当前状态：

getenforce

如果SELinux是Enforcing状态，nrpe启动后可能因为端口绑定或目录访问策略被拦。可以先临时设置为Permissive观察：

setenforce 0

注意这行命令是临时生效，重启后就失效了。要想持久化，需要改/etc/selinux/config把SELINUX=permissive，但这步要结合你们的安全基线来定。最理想的做法是给nrpe放行对应的SELinux布尔值或自定义策略，但坦白说，多数内网监控场景下，大家会先把SELinux策略调成Permissive来排障。我的经验是：先把功能跑通，再来补安全策略的细节，不要一上来就双重约束，导致问题定位困难。

3. nrpe-3.2.1-8 编译安装：从源码包到systemd服务

3.1 下载源码包与创建运行用户：第一步别搞错

把源码包放到/usr/local/src下：

cd /usr/local/src wget https://github.com/NagiosEnterprises/nrpe/releases/download/nrpe-3.2.1-8/nrpe-3.2.1-8.tar.gz tar zxvf nrpe-3.2.1-8.tar.gz cd nrpe-3.2.1-8

下载地址以GitHub上NagiosEnterprises/nrpe Releases页面实际公布的链接为准，有些场景下还要用代理镜像或者内网中转，但文件校验值要对照官方发布页，防止包被篡改。如果你在完全没有外网的机房，这一步就得提前下载好源码包和依赖RPM一并带进去。

然后创建一个nrpe运行用户。安全起见，别让nrpe进程以root身份运行，给一个nologin用户：

useradd nrpe -s /sbin/nologin

这样即使nrpe被利用，攻击者也拿不到可交互的shell。后续编译安装过程中，make install会读取--with-nrpe-user参数把相关文件的属主设置好。

3.2 configure参数详解与编译安装：关键选项要心里有数

configure阶段是决定安装路径和编译特性的关键一步。我常用的参数组合：

./configure \ --prefix=/usr/local/nrpe \ --with-nrpe-user=nrpe \ --with-nrpe-group=nrpe \ --with-ssl=/usr/bin/openssl \ --with-ssl-lib=/usr/lib64

几个核心参数逐个说：

• --prefix：安装根目录。我习惯装在/usr/local/nrpe下，和Nagios的/usr/local/nagios呼应，路径清晰。
• --with-nrpe-user和--with-nrpe-group：指定运行用户组，和前面创建的nrpe用户对应。
• --with-ssl和--with-ssl-lib：指定OpenSSL可执行文件和库目录。64位系统一般是/usr/lib64，如果你的KeyarchOS库目录是/usr/lib，这里要改。
• --enable-command-args：这个参数要非常谨慎。开启后允许Nagios服务端在调用时传参，灵活但危险。我的建议是默认关闭，把每个检查项的参数固化在nrpe.cfg里。能少暴露一个口子就少暴露一个。

configure结束后，检查输出中有没有明显的警告或错误。看到类似“NRPE will be installed in...”的提示说明配置成功。接着执行：

make all make install make install-config make install-init

make install把二进制和插件装到prefix目录下，make install-config会生成一份默认的nrpe.cfg，make install-init会生成systemd服务脚本。如果最后一步执行报错，大概率是系统init方式不是systemd或权限问题，可以手动创建systemd unit文件，这个后面会讲。

3.3 nrpe.cfg重点参数解读：三行配置决定成败

安装完成后，默认配置文件在/usr/local/nrpe/etc/nrpe.cfg。用vim打开，重点看这几项：

log_facility=daemon pid_file=/run/nrpe.pid server_port=5666 server_address=0.0.0.0 nrpe_user=nrpe nrpe_group=nrpe allowed_hosts=127.0.0.1,::1,192.168.1.100 dont_blame_nrpe=0 command_timeout=60 connection_timeout=300

关键项逐一说明：

• allowed_hosts：最重要的一项，没有之一。填入Nagios服务器的IP地址，支持多个IP用逗号分隔。这里如果漏填或填错，Nagios那边怎么连都是连接被拒或者远端关闭连接。
• server_address：如果是多网卡机器，不想所有网卡都暴露，可以指定监听在特定IP上。一般场景保持0.0.0.0即可。
• dont_blame_nrpe：强烈建议保持0。设成1虽然能远程传参，但等于把被监控端的命令执行权暴露给了网络对端，一旦Nagios服务器被攻破或配置错误，影响面会很大。
• command_timeout：单个监控命令执行的超时时间，默认60秒。有些磁盘检查在高负载机器上可能慢，可以适当调大，但别调太大，因为Nagios端也有自己的服务检查超时时间。

然后定义监控命令。默认配置已经带了一些示例，比如：

command[check_users]=/usr/local/nrpe/libexec/check_users -w 5 -c 10 command[check_load]=/usr/local/nrpe/libexec/check_load -r -w 15,10,5 -c 30,25,20 command[check_disk]=/usr/local/nrpe/libexec/check_disk -w 20% -c 10% -p / command[check_zombie]=/usr/local/nrpe/libexec/check_zombie -w 5 -c 10

这里要注意插件路径。默认插件目录是/usr/local/nrpe/libexec。想检查哪个指标，就在command[]对子里加一条。比如我想检查内存和关键端口：

command[check_mem]=/usr/local/nrpe/libexec/check_mem -f -w 80 -c 90 command[check_ports]=/usr/local/nrpe/libexec/check_ports -p 8080 -p 3306

注意check_mem这个插件nrpe默认不带，需要自己从Nagios Exchange或GitHub下载编译，或者用shell脚本改一个。我一般会自己写一个简单的内存检查脚本，核心思路是解析free命令输出，计算使用率后按阈值返回对应状态码，省去额外编译插件的麻烦。

3.4 启动nrpe并验证监听状态：服务起来了才算数

配置改完，启动并设置开机自启：

systemctl start nrpe systemctl enable nrpe systemctl status nrpe

如果make install-init没生成unit文件，手动创建/etc/systemd/system/nrpe.service：

[Unit] Description=Nagios Remote Plugin Executor After=network.target [Service] Type=simple User=nrpe Group=nrpe ExecStart=/usr/local/nrpe/bin/nrpe -c /usr/local/nrpe/etc/nrpe.cfg -f Restart=on-failure [Install] WantedBy=multi-user.target

注意ExecStart里的-f参数，意思是前台运行，配合systemd的Type=simple正好。老版本nrpe如果不加-f，daemon会自己fork，systemd会以为进程启动后又退出，状态栏显示异常。这个细节我栽过跟头，当时就是systemctl status一直是inactive，后来一查是没加-f，加完立刻恢复正常。

启动后检查端口监听：

ss -lntp | grep 5666

如果看不到监听，优先去日志找原因：

journalctl -u nrpe -n 50

4. 服务端配置：让Nagios真正拉取到远程指标

4.1 安装check_nrpe插件：服务端这只手也要备好

Nagios服务器上需要check_nrpe插件才能和远程nrpe通信。如果你的Nagios是源码安装在/usr/local/nagios，插件目录通常是/usr/local/nagios/libexec。下载编译check_nrpe同样需要编译工具：

cd /usr/local/src wget https://github.com/NagiosEnterprises/nrpe/releases/download/nrpe-3.2.1-8/nrpe-3.2.1-8.tar.gz tar zxvf nrpe-3.2.1-8.tar.gz cd nrpe-3.2.1-8 ./configure --prefix=/usr/local/nagios make all make install-plugin

这样只安装check_nrpe插件，不会在被监控的KeyarchOS机器上装daemon。configure的prefix参数要指向Nagios的实际安装目录，否则插件会被装到别处去。

装完后先做一次连通性测试：

/usr/local/nagios/libexec/check_nrpe -H 192.168.1.101

如果一切正常，会返回NRPE版本号：

NRPE v3.2.1

这就说明服务端到被监控端的通道已经通了。如果这一步都过不了，先别急着配Nagios对象，回头查第3节的服务、防火墙和配置。

4.2 定义主机和服务对象：把主机纳管进Nagios

通道通了之后，在Nagios里加配置。找到Nagios的objects目录，新建一个keyarchos-host.cfg，典型写法：

define host { use linux-server host_name keyarchos-node01 alias KOS Node 01 address 192.168.1.101 max_check_attempts 5 check_period 24x7 notification_interval 60 contact_groups admins } define service { use generic-service host_name keyarchos-node01 service_description Current Load check_command check_nrpe!check_load check_interval 5 retry_interval 1 } define service { use generic-service host_name keyarchos-node01 service_description Disk Root check_command check_nrpe!check_disk check_interval 10 retry_interval 1 }

然后在Nagios的command.cfg里确认check_nrpe命令定义：

define command { command_name check_nrpe command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ }

$USER1$对应Nagios插件目录，$HOSTADDRESS$会被替换成主机定义里的address，$ARG1$就是service定义里check_command后面的那个参数，比如check_load。这个“感叹号传参”机制是Nagios的核心套路，理解了就一通百通。

检查配置并重载Nagios：

/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg systemctl restart nagios

4.3 命令行验证与Web界面确认：眼见为实

重启Nagios后，等一两分钟，在Nagios Web界面就能看到这台KeyarchOS主机的Load和Disk状态了。但更快速的验证方式是命令行直接调：

/usr/local/nagios/libexec/check_nrpe -H 192.168.1.101 -c check_load

正常返回类似：

OK - load average: 0.12, 0.08, 0.05|load1=0.120;15.000;30.000;0; load5=0.080;10.000;25.000;0; load15=0.050;5.000;20.000;0;

竖线后面是性能数据（perfdata），Nagios可以用这些数据画趋势图，配合PNP4Nagios或者Grafana+InfluxDB这类时序存储，能把历史趋势做出来。我的习惯是每个新服务加完，立刻用check_nrpe手动跑一次并看输出，再回Web界面确认。这样能把agent问题和Nagios配置问题分离开，不用等告警了才回头查。

4.4 常用指标一次配齐：把KeyarchOS主机体检做完整

上面只演示了check_load和check_disk。实际生产环境，我还会在nrpe.cfg里配置这几项：

• 进程数检查（check_procs）：防止进程异常堆积。
• 用户数检查（check_users）：防止异常用户登录。
• 僵尸进程检查（check_zombie）：僵尸进程多了说明有进程没被回收。
• 内存使用率检查（check_mem）：内存被吃满是最常见的故障源。
• 关键TCP端口检查（check_tcp）：端口挂了等于服务挂了。
• 自定义日志文件大小或错误关键字检查（脚本）：日志炸了通常伴随磁盘满。

每加一个服务，都先在nrpe.cfg里定义好command，重启nrpe，再到Nagios端手动check_nrpe验证一次。别直接配完Nagios就等半天，然后被告警打脸。批量操作时，用一个for循环在Nagios服务器上把所有主机的check_load跑一遍，几秒钟就能摸清整个集群的健康底细。

5. 排障指南：这些nrpe的坑我基本都踩过

5.1 连接超时：九成是防火墙或监听地址

现象是check_nrpe执行后一直卡住直到timeout，报错为“Connection timed out”。排查顺序：

1. 在Nagios服务器上ping被监控主机，确认网络通。
2. 在被监控主机上执行ss -lntp | grep 5666，确认nrpe在监听。
3. 确认allowed_hosts里是否包含Nagios服务器IP。
4. 在Nagios服务器上telnet 192.168.1.101 5666，看端口是否可达。

第4步是最快的判别方式。telnet不通，问题99%出在防火墙或SELinux。我之前有次排查了一个多小时，最后发现是新加的iptables规则顺序没排好，被前面的DROP规则拦掉了。

5.2 连接被拒：allowed_hosts和server_address的锅

报错“Connection refused”或“Connection closed by remote host”。如果telnet能通但check_nrpe被拒，十有八九是allowed_hosts没包含Nagios服务器IP。注意allowed_hosts里支持IPv4和IPv6地址，如果填了IP仍然被拒，检查server_address是不是绑定了127.0.0.1，这会让外部连接全部落到本地回环上。这种错误很隐蔽，因为本机测试可能一切正常，一到远端就失败。

5.3 SSL协议不匹配：版本对齐是根本解

现象是连接能建立，但check_nrpe报错类似“CHECK_NRPE: Error receiving data from daemon”或者“Remote host has closed the connection”。这种情况最常见于服务端check_nrpe和被监控端nrpe版本差异过大。两边尽量对齐到同一个大版本，如果升级成本太高，可以尝试在nrpe.cfg里调整ssl_version，但说实话最省事还是对版本。版本不匹配还容易出现在混合架构环境里，比如一边是官方打包的，一边是源码编译的，编译参数不同也会导致协商失败。

5.4 插件路径权限与前台调试：最后的排查手段

nrpe daemon以nrpe用户运行，当插件的可执行权限不对时，会返回“NRPE: Unable to read output”之类的信息。检查插件文件属主和权限：

ls -l /usr/local/nrpe/libexec/check_load

如果属主不对，用chown和chmod修正。还有一种情况是插件脚本第一行的解释器路径不对，比如#!/bin/bash在精简系统上不存在，脚本直接失败。先用前台模式手动跑一下：

sudo -u nrpe /usr/local/nrpe/bin/nrpe -c /usr/local/nrpe/etc/nrpe.cfg -f -d

-d参数会开启详细调试输出，你可以直接看到nrpe启动时加载了哪些配置、绑定在哪个端口、收到连接后做了什么。看完按Ctrl+C停掉，再回systemd去启动。这个模式是我排查所有nrpe疑难杂症的第一选择。

5.5 问题速查表：收藏这一张就够了

最后聊一点个人体会。nrpe这东西看着不起眼，但它是整个Nagios监控体系里最容易被忽略也最容易