监控大屏上显示一片绿并不代表业务真的健康。我有一次排查线上问题某台主机在监控系统里始终在线ping通、端口通、告警规则全没触发可登录上去发现swap几乎耗尽内核日志里OOM kill刷了好几屏。网络层健康、主机层爆缸这种局面对做运维的人来说太熟悉了。要拿到CPU负载、内存余量、磁盘空间、进程数这些真正决定业务稳定性的指标监控中心必须能“进入主机内部”执行检查。NRPENagios Remote Plugin Executor解决的正是这个问题在被监控主机上常驻一个轻量守护进程让Nagios中心以拉取方式远程调用本地插件把主机内部数据实时采集回来。最近我在KeyarchOSKOS环境里从源码编译部署了nrpe-3.2.1-8整个流程走下来比较顺远程主机指标采集基本开箱即用。这篇文章把我实际操作中的步骤、参数选择和踩过的坑都记录下来适合正在用Nagios或正准备接入Nagios体系的运维同学参考。1. 监控盲区的本质为什么远程指标需要一个专用守护进程日常监控里大部分团队第一时间想到的是“能ping通就行”。但网络可用和主机健康完全是两码事。系统负载过高、进程僵死、磁盘写满、内存泄漏这些状态在主机外面看不到。你可以在Nagios上探测端口、检查HTTP响应可如果你想拿到主机本地的/proc数据、执行自定义脚本、读取服务状态就必须有一种能在远程主机内部执行命令的通道。1.1 人肉SSH查指标不是一个可持续的方案以前监控没有覆盖到位的时候我查一台服务器的内存占用流程是这样的SSH登录、敲free -m、看数值、再登出。机器少的时候还好主机一多就完全不现实。而且给监控人员开放SSH权限本身也有安全风险操作审计、密钥管理、误操作都是麻烦事。有些团队用SNMP采集远程主机数据SNMP确实是通用方案但它的指标树是固定的偶尔想跑一个自定义健康检查脚本、检查某个业务进程是否存在SNMP就帮不上忙了还得另外想办法。NRPE这类方案的优势在于它把“远程执行命令”这个问题从协议层面解决掉。监控服务器通过check_nrpe工具连接目标主机的NRPE守护进程远程守护进程根据配置执行相应的插件命令比如check_load、check_disk、check_procs然后把输出结果和退出状态码返回给监控服务器。这套机制足够简单又能复用Nagios生态里数量庞大的check插件。1.2 NRPE拉取模型与KeyarchOS场景适配拿我这个环境来说KeyarchOS本身是基于RPM体系的Linux发行版内核和系统工具链都是主流服务器生态里的东西systemd、firewalld、OpenSSL这些都齐备所以NRPE在它上面部署没有额外的门槛。NRPE的工作模式可以理解成客户机/服务器模式。监控中心的Nagios算是使用方它调用check_nrpe这个客户端程序去连接远端主机的5666端口远端主机的nrped守护进程收到请求后在本地执行配置里预先定义好的插件命令再把结果传回给监控端。整个过程对业务服务几乎无感因为NRPE只是一个独立运行的监控代理不会侵入正在跑着的应用进程。这套模型有几点我很喜欢。第一检查动作在目标主机本地完成因此能看到主机内部真实的资源状态第二插件执行完以后立即退出不会长期占用资源第三Nagios侧通过check_nrpe一条命令就能复用配置起来很直接。它天然适合把一批批新增主机快速纳入统一监控尤其适合那些已经有Nagios Core、Centreon、Icinga等监控平台的环境。2. 安装前的功课依赖、专用用户与目录规划NRPE 3.2.1版本比较新编译安装之前要把依赖准备齐全。题目标题里写的是nrpe-3.2.1-8实际它就是基于上游3.2.1主版本加上了后续的维护补丁编译方式和安装路径与标准源码包一致。省掉这一步直接开搞后面容易卡在一些莫名其妙的编译错误上。2.1 准备编译工具链编译NRPE需要gcc、make以及OpenSSL开发库因为NRPE 3.x默认启用TLS加密通信编译时要链接SSL。在KeyarchOS上我直接用系统包管理器安装dnf groupinstall Development Tools -y dnf install -y wget tar gcc make openssl openssl-devel如果你的环境属于离线内网没法用dnf拉包那就需要提前准备RPM包或本地软件源。实际操作中很多服务器在生产环境是不通外网的这时候建议在相同版本的一台测试机上先下载好rpm包再打包带进去安装。还需要说明一下如果你的系统里有xinetd或想用传统方式启动NRPE也可以安装xinetd但我在KOS上更推荐直接使用systemd托管后面会说为什么。2.2 创建专用监控账户部署任何监控代理我都不建议用root直接跑。专用账号的好处是权限收得干净即使插件被攻击者利用也只是普通用户权限。创建方法很简单id nagios || useradd -m -s /bin/bash nagios passwd nagios密码可以设置一个不为空但平时不会用到的密码之后NRPE守护进程以nagios用户身份运行插件脚本也以这个身份执行。若插件要读取某些系统日志或执行个别特权命令再通过sudo白名单单独放行别直接把整个代理跑在root下。2.3 下载源码包与版本确认NRPE源码可以从Nagios项目的官方发布渠道获取。下载时注意版本目录3.2.1版本对应的源码包是nrpe-3.2.1.tar.gz。下载后先校验一下校验和再解压wget https://github.com/NagiosEnterprises/nrpe/releases/download/nrpe-3.2.1/nrpe-3.2.1.tar.gz tar -zxvf nrpe-3.2.1.tar.gz cd nrpe-3.2.1这里单独说一句NRPE本身只是执行框架真正干活的是各种check插件。所以还得另外准备nagios-plugins或者至少把你需要的check_load、check_disk这些插件源码装上。我的做法是直接安装nagios-plugins主线版本因为它的插件齐CPU、内存、磁盘、进程检查都覆盖了。wget https://github.com/nagios-plugins/nagios-plugins/releases/download/release-2.4.6/nagios-plugins-2.4.6.tar.gz tar -zxvf nagios-plugins-2.4.6.tar.gz cd nagios-plugins-2.4.62.4 规划安装前缀默认安装前缀是/usr/local/nagios二进制、配置、插件都会有固定的目录结构。我个人建议沿用默认路径后续升级、迁移、备份都比较清晰。如果你是监控服务器和被监控主机分开部署那就在被监控主机上只需要安装NRPE守护进程和插件check_nrpe客户端放在监控服务器上两者别装反了。最终目录规划是这样的/usr/local/nagios/bin/nrpe远程守护进程/usr/local/nagios/bin/check_nrpe监控端客户端工具/usr/local/nagios/etc/nrpe.cfg主配置文件/usr/local/nagios/libexec/插件目录3. 源码编译NRPE 3.2.1-8的完整实操编译配置这一步是整个安装过程里最需要动脑子的地方。NRPE的configure脚本提供了一堆参数我的建议是不要在生成环境里盲目复制网上的命令先搞明白参数含义。3.1 配置参数选型与解读在NRPE源码目录里执行./configure --prefix/usr/local/nagios \ --with-nrpe-usernagios \ --with-nrpe-groupnagios \ --enable-command-args \ --with-ssl/usr/bin/openssl \ --with-ssl-lib/usr/lib64逐项说一下我的考量。--prefix指定安装根目录这个和前面规划的路径保持一致。--with-nrpe-user和--with-nrpe-group指定守护进程运行身份对应刚才创建的nagios用户。--with-ssl和--with-ssl-lib是让编译时正确链接系统OpenSSL库在64位系统上ssl-lib一般指/usr/lib64有的发行版是/usr/lib/x86_64-linux-gnu看自己机器的实际情况。--enable-command-args这个参数尤其关键。它允许远程监控中心在请求时给插件传入参数。比如check_disk后面可以追加要检测的挂载点。但是开启它也会带来命令注入风险远程调用方可以在一定程度上定制命令内容。因此这个开关通常要配合allowed_hosts白名单一起使用。如果你的监控服务器IP不固定、网络又比较开放我建议先不开这个参数把每条检查命令阈值写死安全性会高很多。3.2 编译、安装与关键文件检查configure执行成功后能看到类似“NRPE Configuration Summary”的提示里面会列出安装路径、用户、SSL状态等信息。确认无误后执行编译make all sudo make installmake install默认会把nrpe守护进程安装到/usr/local/nagios/bin/nrpe把客户端工具check_nrpe也放到bin目录同时把示例配置nrpe.cfg放到etc目录。装完先验证版本/usr/local/nagios/bin/nrpe --version正常会显示NRPE版本号比如3.2.1。再看一下关键文件是否齐全ls -l /usr/local/nagios/bin/nrpe ls -l /usr/local/nagios/bin/check_nrpe ls -l /usr/local/nagios/etc/nrpe.cfg实际部署中我遇到过configure阶段一切正常但make install之后bin目录里没有nrpe的情况多半是当前用户对/usr/local/nagios目录没有写权限。所以安装步骤要用有sudo权限的用户来执行或者直接切到root。3.3 编译nagios-plugins插件库刚刚编译完的NRPE还不能干活因为没有实际使用的检查插件。继续编译nagios-pluginscd nagios-plugins-2.4.6 ./configure --prefix/usr/local/nagios --with-nagios-usernagios --with-nagios-groupnagios make all sudo make install执行完以后/usr/local/nagios/libexec目录下应该能看到大量check_开头的脚本和二进制比如check_load、check_disk、check_procs、check_users。这些就是后面nrpe.cfg里调用检查命令时真正执行的东西。有一处容易疏忽插件编译时间通常比NRPE本身要长但不要因为等待时间长就跳过配置检查。configure阶段如果提示缺少某个依赖比如某个Perl模块就要先补齐再编译否则某些插件会少功能。4. 配置文件与守护进程管理让每个指标命令都自由可控NRPE装好以后真正决定它能监控什么的是nrpe.cfg配置文件。从某种角度说NRPE是一个仅执行预定义命令的白盒config里定义哪些检查远程就能调哪些检查。这个设计是出于安全考虑也方便审计。4.1 nrpe.cfg核心字段配置打开配置文件vim /usr/local/nagios/etc/nrpe.cfg我会重点关注这几个字段。server_port5666 allowed_hosts127.0.0.1,192.168.10.20 dont_blame_nrpe0 command_timeout60server_port是守护进程监听端口默认5666一般不用改。allowed_hosts是允许连过来的监控服务器IP列表这一步必须精确填写。我把127.0.0.1留在这儿是为了本机测试方便。生产环境建议只用一行写上你的Nagios服务器实际IP多个IP用逗号分隔。allowed_hosts写错了是故障排查时最坑的一个点因为NRPE的报错信息往往不直观后面我会专门讲。dont_blame_nrpe0表示默认禁止远程传入插件参数。如果你在configure时开了--enable-command-args想在监控服务端动态指定参数可以这里改成1但要在安全策略层面严格限制允许来源IP。我的生产环境一般保持0把所有检查命令的参数固化在配置里这样可以有效降低被人钻空子执行意外命令的风险。配置里的include_dir字段可以把命令定义拆到多个文件便于管理include_dir/usr/local/nagios/etc/nrpe.d在nrpe.d目录里按主机或按检查项写多个配置文件比如memory.cfg、disk.cfg比一个超大的nrpe.cfg好维护得多。命令定义长这样command[check_users]/usr/local/nagios/libexec/check_users -w 5 -c 10 command[check_load]/usr/local/nagios/libexec/check_load -w 0.70,0.60,0.50 -c 1.50,1.00,0.80 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_users的-w 5 -c 10表示登录用户数超过5个警告、超过10个严重check_load的-w 0.70,0.60,0.50按1分钟、5分钟、15分钟平均负载分别设定check_disk的-w 20% -c 10%表示磁盘剩余空间少于20%警告、少于10%严重。这些数值要结合机器实际规格来定8核机器和2核机器的负载阈值肯定不一样。4.2 用systemd把NRPE守护进程管起来配置写好后直接在前台启动一下检查语法/usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -f-f参数让NRPE以前台模式运行看到日志里没有报错再CtrlC停止接着创建systemd服务。这样做的原因是生产环境里我不希望守护进程因为一个小语法错误就静默退出systemd会负责自动拉起。创建服务文件sudo vim /etc/systemd/system/nrpe.service[Unit] DescriptionNagios Remote Plugin Executor Afternetwork-online.target Wantsnetwork-online.target [Service] Typesimple Usernagios Groupnagios ExecStart/usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -f Restarton-failure RestartSec5 [Install] WantedBymulti-user.targetTypesimple配合-f前台模式是常见的组合。如果不用-fNRPE默认会fork后台进程Type要改成forking还要指定PIDFile反而多几处容易出错的配置。我对生产环境的原则是尽量简单直接。启动并设为开机自启sudo systemctl daemon-reload sudo systemctl enable --now nrpe sudo systemctl status nrpe看到active (running)就说明守护进程起来了。顺手检查监听端口ss -lntp | grep 56664.3 防火墙与SELinux下的端口放行KeyarchOS默认启用了firewalld外部监控服务器要访问5666端口必须先放行。执行sudo firewall-cmd --permanent --add-port5666/tcp sudo firewall-cmd --reload sudo firewall-cmd --list-ports这里要注意如果你的监控网段和管理网段是分开的更精细的做法是只允许某个源IP访问比如sudo firewall-cmd --permanent --add-rich-rulerule familyipv4 source address192.168.10.20 port protocoltcp port5666 accept sudo firewall-cmd --reloadSELinux方面如果系统开启了SELinux且处于Enforcing模式NRPE监听非默认端口可能会被拒绝。可以这样检查getenforce sudo semanage port -l | grep nrpe如果SELinux策略里没有放行5666就添加sudo semanage port -a -t nrpe_port_t -p tcp 5666在没有semanage命令的系统上先安装policycoreutils-python-utils这个包再操作。另外NRPE要执行某些插件时可能会被SELinux限制比如读取进程状态目录。如果启用SELinux建议开启对应的布尔值或者直接在策略中给nagios域足够的权限。直接关闭SELinux是我见过不少团队的做法但我会建议保持默认开启并用semanage精确放行毕竟安全功能能开着就别主动拆。5. 接入中心监控本地自测与Nagios侧联调守护进程跑通只是第一步真正有意义的是监控中心能够通过NRPE拉到指标。这一部分要从本机自测开始再由外到内逐层联调。5.1 先在本机验证NRPE与插件链路先在本机执行check_nrpe测试此时NRPE守护进程、插件、配置都在同一台主机上链路最短最容易定位问题/usr/local/nagios/bin/check_nrpe -H 127.0.0.1正常时返回NRPE版本信息比如NRPE v3.2.1。这说明守护进程收到了请求并成功应答。接着测试单个命令/usr/local/nagios/bin/check_nrpe -H 127.0.0.1 -c check_load如果返回一段负载数据后面跟着OK说明插件也能正常执行。这一步做不通后面接监控服务器是完全没意义的。5.2 Nagios监控服务器侧的命令与服务定义Nagios服务器上需要有check_nrpe这个客户端工具以及纳管主机的配置。把编译好的check_nrpe复制到Nagios的libexec目录或者直接在监控服务器上单独编译一次NRPE源码也能得到客户端工具cp /usr/local/nagios/bin/check_nrpe /usr/local/nagios/libexec/ chown nagios:nagios /usr/local/nagios/libexec/check_nrpe然后在Nagios的command配置里新增命令定义define command { command_name check_nrpe command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ }这样每个监控对象就能用check_nrpe!check_disk这样的形式去调用远程命令。比如给一台远程主机配置CPU负载检查define host { host_name remote-kos-node address 192.168.10.31 max_check_attempts 3 check_command check_nrpe!check_load } define service { host_name remote-kos-node service_description CPU Load check_command check_nrpe!check_load check_interval 5 retry_interval 1 }这里的关键点是Nagios中心到被监控主机之间的网络要能通5666端口同时被监控主机nrpe.cfg里的allowed_hosts必须包含Nagios服务器的IP。缺一项都会导致监控界面出现UNKNOWN或CRITICAL。5.3 告警项设计与阈值策略NRPE适合做资源型告警我把常用的检查清单整理一下线上可以直接拿来参考。检查对象建议命令常见阈值备注CPU负载check_load按核数设定通常w0.7核数c1.0核数多核机器按负载均值换算内存使用check_mem或自定义脚本物理内存使用率w80,c95注意buffer/cache处理根分区空间check_disk剩余空间百分比w20,c10大数据分区单独监控登录用户数check_usersw5,c10防止多人同时登录导致资源拥塞进程总数check_procsw300,c400进程泄漏场景最常用关键业务进程check_procs -a 特定进程存在性检查用防崩溃守护逻辑写阈值时有一点我反复提醒自己和团队不要想一次性把阈值设到完美任何监控阈值都需要观察一段时间的基线数据再调整。数值设太紧凌晨三点告警轰炸值班同事会把报警当噪音设太松真正故障时又失去了预警意义。先按文档建议值上线跑两周再看历史数据和业务反馈做微调会比较稳妥。6. 常见问题排查与生产环境避坑清单NRPE整体结构不复杂但因为它涉及监控服务器、防火墙、SELinux、目标主机插件四个环节真正出问题时还是需要一套系统的排查思路。6.1 经典错误速查表我整理了实际运维中最常碰到的几类报错对应原因和解决方法都在表里。错误现象可能原因排查方法CHECK_NRPE: Error - Could not complete SSL handshake来源IP不在allowed_hosts或端口被防火墙挡了检查nrpe.cfg白名单检查firewalld规则Could not connect: Connection refusedNRPE守护进程没运行或5666端口未监听systemctl status nrpess -lntp grep 5666NRPE: Command check_disk not definednrpe.cfg里没定义该命令或include_dir没生效确认command[check_disk]存在并重载服务NRPE: Unable to read output插件执行超时或输出为空提高command_timeout手动执行插件命令看输出check_load: Unable to read output插件依赖或权限问题以nagios用户身份执行插件确认权限socket timeout监控端到目标主机网络不通telnet目标IP 5666分段测网络连通性其中SSL handshake这个报错最容易让人误判。很多人一看SSL第一反应是证书问题其实NRPE在这里报错绝大多数时候根本不是证书损坏而是allorwed_hosts不匹配导致守护进程直接断开连接或者网络层把连接掐掉。排查这个报错时别急着动证书先从白名单和防火墙入手。6.2 从现象到根因的排查顺序遇到NRPE采集失败我习惯按这个顺序推进效率会高很多。在被监控主机本机执行check_nrpe -H 127.0.0.1先确认NRPE进程和命令定义本身没问题。在本机用curl或者ss确认端口监听状态ss -lntp | grep 5666。在监控服务器上执行telnet目标主机5666验证中间链路通不通。在监控服务器上执行check_nrpe -H目标IP此时能复现完整业务链路。如果前面都正常但Nagios界面还是报错检查Nagios命令定义和confit语法/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg。这套顺序我称为“由近及远、由低到高”。先从离代码最近的本机验证逐步往外推比一上来就在Nagios界面里倒腾配置高效得多。6.3 几个容易忽视的操作细节NRPE在按源码编译之后有一个细节很容易被忽略插件脚本本身要以nagios用户身份能正常执行。很多自定义脚本是root安装编译的普通用户执行时缺少环境变量或者读不了某些文件最终都会变成NRPE Unable to read output。建议把所有命令先在命令行用nagios用户手动跑一遍再挂到NRPE上sudo -u nagios /usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /如果这里返回正常再走check_nrpe测一遍。这条命令能帮你把“插件本身报错”和“NRPE链路报错”清楚地区分开。另一个容易踩的坑是重载配置方式。修改nrpe.cfg或nrpe.d下的文件后大部分情况下需要重启nrpe服务才能生效。systemd管理下执行sudo systemctl restart nrpe不要以为NRPE会像某些agent一样自动热加载配置文件。改完配置不重启排查半天发现还在执行旧命令这种事我也干过。生产环境建议把所有自定义检查命令写进/etc/nrpe.d/独立文件文件名按业务模块区分比如web-service.cfg、database.cfg。这样下次要临时禁用一个检查项只需要注释掉对应文件里的命令重启NRPE即可不必在庞大的主配置里翻来找去。最后再分享一点实际体会NRPE部署本身不难难的是一直保持监控数据的准确和安全。我在实际操作后发现把allowed_hosts收紧、把dont_blame_nrpe保持为0、用独立文件管理检查命令这三件事做扎实NRPE就很少再出幺蛾子。等这批主机彻底纳入监控以后我还会从NRPE往主动推送型的监控Agent逐渐过渡毕竟不同业务场景对监控时延和扩展性的要求不一样但NRPE这套远程执行模型作为Nagios生态里最成熟的远程指标采集通道短期之内依然是稳定可靠的首选。