做运维最难受的不是故障本身而是故障发生在那台你以为有监控、实际根本没人采数的机器上。这些年我踩过太多次这种坑新扩容的机器加进了负载均衡监控平台上也添了主机但图形一直断断续续内网边界机只开放了业务端口采集 agent 根本装不进去还有一批临时拉起来做压测的机器等活动结束才发现整段压测过程都没有系统指标留存。把远程指标采集这件事彻底捋清楚之后我发现 NRPE 这种“被控端守护进程 监控端主动拉取”的模式依然是最省事的补盲方式之一。这篇就写我在 KOS 这套企业级 Linux 发行版上安装 nrpe-3.2.1-8 的完整过程从环境准备、编译安装到监控端对接再加上实际踩过的坑全部是能直接照抄的操作。1. 监控盲区到底从哪来NRPE 在远程采集里的位置1.1 三类最容易漏监控的机器我复盘了一下历年来的“监控事故”发现盲区往往集中在三类机器上。第一类是临时扩容机。负载一上来就急着加机器系统装完、服务跑起来监控平台上加了个主机名但真正执行采集的通道没建好等负载降下去之后这台机器就被遗忘了。下次再出问题就是磁盘满或者进程挂掉才发现时间线完全对不上。第二类是隔离区主机。有些内网区域和监控平台之间只放行业务端口传统的 agent 主动上报模式根本走不通因为 agent 连不上监控端或者连上了也会被安全策略干掉。这类机器的指标采集只能靠监控端主动往目标主机上探。第三类是“不让多装东西”的主机。出于安全合规要求目标机器上不允许额外部署 agent 程序只接受指定端口被外部访问。这时候 NRPE 这种轻量守护进程反而成了合理选择因为它占用资源极小部署路径可控比一堆 agent 的审计成本低很多。1.2 远程指标采集的三种典型姿势当时我对比了几种常见的远程指标采集方式各自的优劣势比较明确采集方式传输层部署成本适合场景主要问题SNMPUDP 161中网络设备、打印机、交换机Linux 服务器 CPU、磁盘、内存指标定义不成体系配置繁琐SSH 轮询TCP 22低临时排查、机器数量少每次采集都建连批量主机扛不住密钥管理麻烦NRPETCP 5666中低Linux 服务器指标采集、内网轮询需要维护插件白名单不适合实时流式推送传统采集 agentTCP 自定义高大规模集群、自动化部署一次性铺开成本高安全审计面大SNMP 的问题在 Linux 上尤其明显网卡流量、CPU 负载这类基础信息还能拿但像进程数量、磁盘 inode、系统平均负载这些运维高频指标MIB 表不一定有有的话不同版本取值口径也不一样调试成本远高于预期。SSH 轮询适合机器少的情况机器一多每五分钟跑一轮上百台主机的 SSH 连接光是建连和认证开销就够受的而且把密钥分发到所有被监控主机上本身也是个安全隐患。NRPE 的工作方式很直接监控端通过 check_nrpe 插件向目标主机的 5666 端口发起请求目标机上的 nrpe 守护进程收到命令后在本地执行配置里白名单规定的检查插件再把结果字符串和状态码传回监控端。它和 Linux 原生指标贴合度很好每次采集只有一条 TCP 连接不需要在目标机上开 shell也没法执行任意命令只要配置得当安全性可控。1.3 为什么把版本锁定在 nrpe-3.2.1-8版本选择这块我吃过亏。早期不少机器还跑着 NRPE 2.x2.x 对 SSL 的处理和命令行参数解析都比较老在系统升级之后经常出现编译通过但连接不上、返回信息乱码这些问题。NRPE 3.x 在 IPv6 支持、SSL 握手、参数解析上做了不少加固和现代操作系统的集成度明显更好。这次我选的是 nrpe-3.2.1-8。这个版本号里的 3.2.1 是上游功能版本-8 是发行版重新打包的补丁版本一般会包含一些安全修复和 systemd 适配。用这种带发行版打包后缀的版本好处是批量部署时大家版本完全一致不会出现“这台机器是 3.2.1、那台是 3.2.0行为还不太一样”的尴尬局面。KOS 的软件源里能直接认到它依赖关系也相对干净不用手工补一堆库。2. KOS 环境准备依赖、账号、目录规划一步到位2.1 装之前先确认系统信息和软件源很多安装失败不是 NRPE 的问题而是开始之前没确认环境。我会先跑三件事cat /etc/os-release uname -m dnf makecache第一条看系统版本第二条看架构第三条是让本地软件源缓存保持最新。KOS 这类企业级发行版基本都走 dnf/yum 这套包管理逻辑先把源刷新一遍后面缺依赖时能省很多时间。如果打算用官方源码包编译安装必须提前装好编译工具链和 SSL 开发库dnf install -y gcc make openssl-devel autoconf automake libtool这里的 openssl-devel 尤其重要。NRPE 在编译时会链接 OpenSSL 库用来对监控端和被控端之间的通信做加密和完整校验头文件缺失的话configure 阶段就会报错而且报错信息比较隐晦不会直接说“你少装了 openssl-devel”而是一堆找不到 ssl.h 之类的提示。2.2 专用账号和目录别用 root 跑 NRPENRPE 守护进程本身会以某个用户身份运行然后才去执行具体的检测插件。这个用户绝不能是 root。原因很简单NRPE 的配置里定义了可以执行哪些命令如果守护进程是 root一旦配置被人改掉或者出现漏洞目标机就完全暴露了。我习惯创建一个专用低权限用户useradd -r -s /sbin/nologin nrpe-r 表示创建系统账号-s /sbin/nologin 表示这个账号不能登录 shell只用于进程运行。然后规划好 NRPE 的目录结构路径作用/usr/local/nagios/binNRPE 主程序、check_nrpe 等二进制文件/usr/local/nagios/etcnrpe.cfg 配置文件/usr/local/nagios/libexec检测插件如 check_load、check_disk/usr/local/nagios/var日志和 PID 文件目录创建后把所有权交给 nrpe 用户保证它对自己的配置和插件目录有完整读写能力。实际部署时我会把上面四个目录统一 chown 到 nrpe:nrpe避免后续权限问题mkdir -p /usr/local/nagios/{bin,etc,libexec,var} chown -R nrpe:nrpe /usr/local/nagios2.3 防火墙规则提前收紧只放行监控端网段NRPE 默认监听 TCP 5666 端口。开始安装之前我会先把防火墙规则想清楚免得装完才发现外部访问不通又回头找问题。如果 KOS 上是 firewalldfirewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.0.2.0/24 port port5666 protocoltcp accept firewall-cmd --reload这里我建议用 rich rule 而不是简单地--add-port5666/tcp。rich rule 可以限定来源网段只允许监控平台所在网段访问 5666其他地址一律拒绝。对一个采集端口来说能收窄暴露面就不要开放给全网。如果系统用的还是 iptables对应规则也很简单但只需要放行监控服务器的地址即可。同时看一眼 SELinux 状态getenforce如果是 Enforcing不要急着关先记下来。NRPE 装好之后如果发现网络通、进程在、但连接始终无法建立大概率就是 SELinux 拦的具体排查我放到后面踩坑部分详细说。3. 安装 nrpe-3.2.1-8 的完整动作从包到自启动3.1 拉取源码包、校验、补编译依赖我这次采用的是源码编译方式。虽然发行版仓库里可能有现成 RPM 包但源码编译能更好地控制安装路径和用户参数也方便后续统一目录结构。下载 NRPE 源码包之后第一件事是校验压缩包的哈希值避免从不可信渠道拿到被改过的文件。cd /usr/local/src tar xzf nrpe-3.2.1.tar.gz cd nrpe-3.2.1进入目录后可以先看一眼 README确认版本和编译要求。整个编译过程并不复杂但有几个参数不能省略。3.2 configure 阶段最容易被 SSL 路径绊倒configure 是我觉得最容易翻车的一步。NRPE 编译时必须指定 OpenSSL 的位置写错一个路径后面 make 就会报错。我的完整命令是./configure \ --prefix/usr/local/nagios \ --sysconfdir/usr/local/nagios/etc \ --with-nrpe-usernrpe \ --with-nrpe-groupnrpe \ --with-ssl/usr/bin/openssl \ --with-ssl-lib/usr/lib64解释一下几个关键参数--prefix/usr/local/nagios把程序装到前面规划的目录下方便和管理也符合很多监控插件的默认路径习惯。--sysconfdir/usr/local/nagios/etc指定配置文件位置后续改 nrpe.cfg 就在这个目录。--with-nrpe-usernrpe --with-nrpe-groupnrpe告诉编译脚本以后守护进程以 nrpe 用户和组运行。--with-ssl/usr/bin/openssl --with-ssl-lib/usr/lib64指定 OpenSSL 可执行文件和库目录64 位系统通常是 /usr/lib64如果是 32 位则用 /usr/lib。configure 成功后继续执行make all make install make install-config make install-initmake install-init 在部分发行版上会自动安装 init 脚本或 systemd 文件但 KOS 上我更倾向于自己写 systemd unit这样路径和参数都在掌控范围内下一节会详细说。这里有个额外提醒新版 OpenSSL 在编译时可能出现一堆告警比如某些哈希函数被标记为弃用。只要 configure 通过、make 能顺利完成这些告警一般不用管不影响运行。3.3 配套插件必须装NRPE 只负责“执行”采集靠插件很多人以为装完 NRPE 就能采集指标了这是个误区。NRPE 本身只是一个命令执行器真正干活的是/usr/local/nagios/libexec下的检测插件比如 check_load、check_disk、check_procs这些插件通常属于监控基础插件包。我把监控基础插件包也下载到 /usr/local/src同样编译安装tar xzf plugins.tar.gz cd plugins目录 ./configure \ --prefix/usr/local/nagios \ --with-nagios-usernrpe \ --with-nagios-groupnrpe make make install装完之后验证一下插件是否存在以及能否手动执行ls -l /usr/local/nagios/libexec/check_load /usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20如果能返回 load average 相关的输出说明插件工作正常。这一步只能在本机执行验证的是 NRPE 之外的那层基础能力。3.4 用 systemd 管起来daemon 模式和 PID 文件NRPE 编译安装完成后还要让它以一个系统服务的方式运行、开机自启。我手动创建了一个 systemd 服务文件/etc/systemd/system/nrpe.service[Unit] DescriptionNRPE daemon Afternetwork.target [Service] Typeforking ExecStart/usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -d ExecReload/bin/kill -HUP $MAINPID PIDFile/usr/local/nagios/var/run/nrpe.pid [Install] WantedBymulti-user.target这里-d表示以 daemon 方式运行所以 Type 必须是 forking。启动并设置开机自启systemctl daemon-reload systemctl enable --now nrpe systemctl status nrpe看到 active (running) 之后用ss确认 5666 端口已经监听ss -lntp | grep 5666如果这里没有输出不要急着往前找先回头看日志journalctl -u nrpe -n 50日志里通常会把缺少配置、用户不存在、端口被占用这类问题直接打出来。4. 配置 nrpe.cfg让远程监控端能问到想看的指标4.1 监听地址与 allowed_hosts 的书写习惯NRPE 的核心配置文件是 /usr/local/nagios/etc/nrpe.cfg。编译安装后会生成一个默认配置但默认值通常不能直接用最需要改的就是监听地址和允许来源。server_address192.0.2.101 server_port5666 allowed_hosts127.0.0.1,192.0.2.100server_address 建议写被监控主机实际的内网地址而不是 0.0.0.0。虽然 0.0.0.0 也能工作但以后排查问题时你会希望 ss 输出里明明白白看到这台机器到底绑在哪个网卡上。allowed_hosts 支持逗号分隔的 IP、主机名或网段。我这里写的是监控平台服务器地址 192.0.2.100。特别注意默认配置里只允许 127.0.0.1如果只改了 server_address 忘了改 allowed_hosts远程监控端连过来会被直接拒绝而且 nrpe 日志里不会特别显眼。生产环境我一般直接写网段比如192.0.2.0/24方便监控平台后续扩容但不要写成 0.0.0.0/0。这个端口本质上是在给远程执行命令开的口子来源越精确越安全。4.2 command 白名单按需开放配置 NRPE 的一个原则是只开放你确实要监控的指标不要图省事把一堆命令全放进去。我的常用配置长这样dont_blame_nrpe0 command[check_load]/usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20 command[check_disk]/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p / command[check_procs]/usr/local/nagios/libexec/check_procs -w 300 -c 400 command[check_mem]/usr/local/nagios/libexec/custom_check_mem -w 80 -c 90 command[check_swap]/usr/local/nagios/libexec/check_swap -w 20% -c 10%这里的命令名比如 [check_load] 是远程调用时用的名字后面是真正执行的插件和参数。每个插件路径必须写成绝对路径因为 nrpe 守护进程运行时的 PATH 环境变量非常精简很多时候根本不包含 /usr/local/nagios/libexec。dont_blame_nrpe0 这个参数要特别说。NRPE 3.x 默认禁止远程传参这是合理的安全设计。如果你把它改成 1然后又在监控端用-a参数动态传给被控端就等于给远程命令执行打开了口子攻击者只要能连上 5666就可能通过参数注入执行一些计划外的命令。除非极端特殊场景需要动态参数否则我建议始终保持 0。4.3 从监控端发起第一次真实探测配置改好后reload 一下 NRPEsystemctl reload nrpe然后在监控平台服务器上同样需要一个 check_nrpe 插件。这个插件一般由 NRPE 源码包一起提供安装 NRPE 时执行cd /usr/local/src/nrpe-3.2.1 make install-plugin之后就能用它发起第一次真实探测/usr/local/nagios/libexec/check_nrpe -H 192.0.2.101 -c check_load如果一切正常会看到类似这样的输出OK - load average: 0.00, 0.01, 0.05这个输出格式是监控插件通用的状态 短横线 具体数据。监控平台拿到之后可以根据返回码判断告警等级。看到这段输出就说明监控端到被控端的整条链路已经打通了剩下的只是把这条命令填进监控逻辑里。5. 安装完容易踩的坑权限、SELinux、版本差异5.1 “NRPE: Unable to read output”先查插件能不能手动跑我第一次把 NRPE 配好之后从监控端执行 check_nrpe 遇到的是NRPE: Unable to read output。这个报错特别容易让人一头雾水因为 NRPE 进程本身是活着的端口也通。排查逻辑应该是这样的先确认插件在 nrpe 用户身份下能不能正常跑。注意不是用 root 身份跑而是切到 nrpe 用户跑su -s /bin/bash nrpe -c /usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20如果提示权限不足大概率是 libexec 目录或插件的权限不对。我自己遇到过一次目录是 700nrpe 用户进不去自然读不到插件。解决办法很简单chmod 755 /usr/local/nagios chmod 755 /usr/local/nagios/libexec chmod 755 /usr/local/nagios/libexec/check_*如果 nrpe 用户手动执行插件没问题再回来看 nrpe 日志journalctl -u nrpe -n 50日志里能看到守护进程到底在执行哪条命令、在哪个环节出错。这条排查链路适用于绝大多数“配置看着没问题但取不到数”的故障。5.2 端口通了但 check_nrpe 超时allowed_hosts 与反向解析另一个常见故障是端口通但探测超时。用 nc 测 5666 端口是通的但 check_nrpe 一直卡住最后直接超时。这种情况我一般按三步排查。第一步确认 nrpe 监听地址是不是限定为了某个具体 IP如果监控端访问的是另一个 IP数据包到了但进程根本不会处理。第二步看 allowed_hosts 是否真的包含监控端地址很多默认配置里只写了 127.0.0.1。第三步查反向解析。NRPE 在处理连接来源时可能会尝试解析来源主机名如果内网 DNS 解析很慢或没有相应记录整个连接就会被拖到超时。这类问题里allowed_hosts 写错最隐蔽因为日志里不会说得那么直白。比较好的习惯是配置里一律写 IP 或网段不要写主机名。主机名解析一旦出问题排查成本远超收益。5.3 SELinux 对 5666 端口的拦截排查在 KOS 这类比较重视安全的企业级系统上SELinux 一般是默认开启的。NRPE 安装完、防火墙也放行了但监控端还是连不上就要检查 SELinux。先看审计日志ausearch -m AVC -ts recent grep nrpe /var/log/audit/audit.log | tail -20如果看到 typeAVC 且关联到 nrpe 进程说明被 SELinux 拦了。临时验证可以把 SELinux 设为 permissivesetenforce 0然后再次从监控端探测如果通了问题就锁定在 SELinux 策略上。长期解法不建议直接关掉 SELinux而是用 semanage 放行对应端口或者为 NRPE 写一个小的本地策略模块。具体写策略模块的细节这里不展开但至少不要图省事把系统安全机制关掉尤其是这台机器以后还要承担采集任务被攻破的代价太大。5.4 NRPE 3.x 的参数传递变化最后说一个版本差异的坑。NRPE 2.x 时代很多人习惯在监控端这样带参数check_nrpe -H 192.0.2.101 -c check_disk -a /到了 3.x如果配置里dont_blame_nrpe0-a传过去的参数会被忽略命令执行结果可能还是默认参数甚至直接报错。这个行为变化很容易让旧脚本在升级后“静默失效”。如果确实有少量命令需要动态参数我会单独给这类命令开一个口子而不是全局把 dont_blame_nrpe 设为 1。比如在 nrpe.cfg 里单独定义一个带占位符的命令dont_blame_nrpe1 command[check_disk_arg]/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p $ARG1$调用时check_nrpe -H 192.0.2.101 -c check_disk_arg -a /data这种方式能解决问题但必须清楚开启动态参数传输会增加安全面没有特殊需求就不要开。5.5 关于批量轮询的一点后续经验NRPE 装好之后监控盲区其实已经补掉大半。剩下的工作就是把 check_nrpe 命令一条条做成监控项设置合理的告警阈值。我的习惯是先在环境里挑几台非核心机器跑一周观察 NRPE 进程的 CPU 占用、内存占用和连接失败率再逐步扩大范围。NRPE 本身很轻量但监控端轮询频率不要设得太激进常规五分钟一轮足够部分关键指标可以单独缩短到一分钟。在我这边的经验里监控盲区大多不是缺监控平台而是缺一个足够简单、足够可靠的探测入口。NRPE 装好之后后续扩展监控项只需要在 nrpe.cfg 里加一行 command 定义reload 一下就能生效比为了每个指标单独部署采集程序省心得多。