CentOS 6 上用 Ruby 1.8.7 编写 Nagios 插件实战指南

1. 项目概述为什么在 CentOS 6 上用 Ruby 写 Nagios 插件至今仍值得深挖Nagios 是运维监控领域绕不开的“老派基石”而 CentOS 6 虽已结束官方支持但在大量工业控制、金融后台、教育机房和老旧 ERP 系统中它仍是真实运行着的“生产环境常青树”。我接手过三个连续五年未重启的 CentOS 6.10 物理服务器集群它们跑着 Oracle 11g RAC 和定制化 SCADA 接口服务——这些系统严禁升级内核或更换发行版但监控告警又不能停。这时候“How To Create Nagios Plugins With Ruby On CentOS 6”就不是一篇怀旧教程而是一份生存指南。核心关键词Nagios、Ruby、CentOS 6、plugins在这里不是并列关系而是存在强约束链Nagios 插件本质是可执行脚本只要返回标准退出码0OK, 1WARNING, 2CRITICAL, 3UNKNOWN并输出一行状态文本可选性能数据它就合法Ruby 在 CentOS 6 默认源中仅提供 1.8.7p3742013年发布远低于现代 Ruby 生态要求但恰恰因其轻量、无 GC 压力、启动快、语法直白反而成为嵌入式监控脚本的隐性优选——你不需要 Rails也不需要 Bundler你只需要#!/usr/bin/ruby开头加几十行逻辑就能完成对一个私有 TCP 端口心跳、某个日志关键词出现频次、或自定义 SNMP OID 的毫秒级探测。这不是教你怎么搭一套新监控平台而是教你如何在“不能动”的系统上安全、低侵入、可审计地扩展监控能力。比如某银行网点终端机每小时生成一个加密 ZIP 包需校验其内部 XML 结构合法性再如某电厂 DCS 系统只开放串口通信需通过/dev/ttyS1发送 AT 指令并解析响应。这类需求Shell 脚本写起来晦涩难维护Python 2.6 缺少argparse和json模块而 Ruby 1.8.7 的open3、rexml、serialport需手动编译组合起来代码量少一半调试周期缩短 70%。我试过用 Ruby 1.8.7 写一个检测 WebLogic JVM 堆内存使用率的插件从读取jstat输出、正则提取、阈值判断到格式化输出共 43 行部署后三年零误报——关键在于它不依赖任何外部 gem只调用系统自带命令连require rexml/document都是内置模块。适合谁看三类人第一类是还在维护 CentOS 6 生产环境的 SRE/运维工程师你们手上有 root但没权限重装系统第二类是嵌入式设备厂商的固件支持工程师你们的设备刷的是精简版 CentOS 6资源紧张需要最小 footprint 的监控逻辑第三类是安全合规审计人员你们需要验证“监控脚本是否满足最小权限原则、是否引入未知依赖、是否可被静态分析”——Ruby 插件天然满足这三点无动态加载、无网络外连、源码即执行体。接下来的内容全部基于真实机房环境复现所有命令、路径、版本号、错误日志均来自我上周刚调试完的一台 Dell R710 物理机CentOS 6.10 x86_64内核 2.6.32-754.35.1.el6.x86_64不假设你有互联网、不假设你有编译工具链、不假设你有 sudo 权限——我们只用系统默认能提供的东西把事情做扎实。2. 整体设计思路与方案选型为什么放弃 Shell/Python死磕 Ruby 1.8.72.1 四种脚本语言在 CentOS 6 上的真实可用性对比很多人第一反应是“用 Shell 不就行了”——没错简单 ping 检测当然可以。但一旦涉及结构化数据处理如解析 JSON API 响应、XML 配置文件、CSV 日志、字符编码转换GBK/UTF-8 混合日志、或需要并发控制同时探测 5 个端口并统计成功率Shell 就迅速变得脆弱。我整理过一份真实故障归因表过去两年内我们团队在 CentOS 6 环境下因监控脚本失效导致的漏告警事件中68% 源于 Shell 脚本的IFS设置错误、read命令截断长行、或awk正则引擎在多字节字符下的崩溃。这不是理论风险而是每天都在发生的线上事故。Python 2.6.6CentOS 6 默认版本看似更现代但它缺了太多基础能力argparse模块要到 Python 2.7 才引入json模块虽存在但不支持object_hook自定义解析ssl模块无法验证现代 TLS 证书OpenSSL 1.0.1e 太老。更致命的是urllib2在处理重定向时会静默丢弃 POST body导致调用某些 RESTful 监控接口时永远返回 400 错误——这个坑我踩了整整三天最后用 WireShark 抓包才定位。而 Ruby 1.8.7 的net/http虽也古老但行为稳定、文档清晰、错误提示直接“Net::HTTPFatalError: 500 Internal Server Error”一眼就能判断是服务端问题而非客户端 bug。提示不要试图在 CentOS 6 上安装 Ruby 2.x。RVM/RBENV 全部依赖glibc 2.14而 CentOS 6 的glibc是 2.12强行升级会导致整个系统yum、ssh、ls全部瘫痪。我见过最惨的案例是同事用rpm -Uvh强装 Ruby 2.3结果libc.so.6被覆盖服务器只能进单用户模式用chroot恢复。Ruby 1.8.7 是唯一安全选项——它随系统安装路径固定为/usr/bin/rubyABI 兼容性经过十年验证。2.2 Nagios 插件架构的底层约束必须前置理解Nagios 插件不是普通脚本它运行在严格受限的上下文中。Nagios 守护进程nagios用户以setuid方式调用插件这意味着插件不能依赖用户家目录nagios用户家目录是/var/log/nagios且通常无写权限插件不能访问$HOME/.gem或任何~路径插件工作目录是/不是/usr/lib64/nagios/plugins/所以所有相对路径都必须显式指定插件环境变量极度精简只有PATH/bin:/usr/bin:/sbin:/usr/sbin没有RUBYOPT、GEM_HOME等因此我们的设计必须遵循“零配置、零依赖、零环境假设”三原则。所有 Ruby 代码必须使用绝对路径加载模块如require /usr/lib64/ruby/1.8/rexml/document.rb所有外部命令调用前检查是否存在File.exists?(/usr/bin/jstat)所有临时文件写入/tmp并设置0600权限File.open(/tmp/plugin.XXXXXX, w, 0600)退出前清理临时文件File.unlinkrescue Errno::ENOENT这种“防御式编程”不是过度设计而是 Nagios 插件的生存法则。我曾发现一个同事写的 Python 插件在/tmp下创建了未清理的.pid文件三个月后占满tmpfs导致rsyslog无法写日志最终引发整机告警风暴——根源就是没遵守这条铁律。2.3 Ruby 1.8.7 的能力边界与补全策略Ruby 1.8.7 缺少很多现代特性没有each_with_object、没有tap、没有String#start_with?得用index(prefix) 0但这恰恰迫使我们写出更清晰、更易审计的代码。我们采用“核心功能内置 边缘能力按需补全”策略网络请求不用net/http太重改用open3调用curl或wget通过-s -w %{http_code}获取状态码-o /dev/stdout获取响应体。这样既规避了 Ruby SSL 栈缺陷又利用了系统curl的成熟 TLS 实现。JSON 解析Ruby 1.8.7 无原生 JSON但我们发现yum install json可安装ruby-json-1.4.6-1.el6.x86_64EPEL 源提供它提供require json接口且纯 C 实现性能优于纯 Ruby 解析器。串口通信gem install serialport会失败缺少extconf.rb支持但我们手动下载serialport-1.3.1.gem解压后修改ext/serialport/extconf.rb将have_library(rt)改为have_library(c)再ruby extconf.rb make make install即可。这个补丁已在 12 台现场设备上稳定运行 47 个月。这种“用系统能力兜底只在必要处打补丁”的思路比盲目追求“最新技术栈”更符合生产环境本质。它让插件具备真正的可移植性——同一份代码在 CentOS 6.5、6.8、6.10 上无需修改即可运行。3. 核心细节解析与实操要点从 Ruby 语法陷阱到 Nagios 协议规范3.1 Ruby 1.8.7 必须规避的五个语法雷区CentOS 6 的 Ruby 1.8.7补丁集 p374存在若干已知行为差异不注意会导致插件在某些场景下静默失败第一雷Hash.new([])的全局引用陷阱错误写法h Hash.new([]); h[:a] 1; h[:b] 2→h[:a]和h[:b]都变成[1,2]正确写法h Hash.new { |hash, key| hash[key] [] }原因Ruby 1.8.7 中Hash.new([])的默认值是同一个数组对象所有 key 共享引用。我在写一个统计多个服务端口响应时间的插件时因这个 bug 导致所有服务的 P95 延迟都被合并计算误判为“全服务延迟飙升”。第二雷String#split的空字符串处理a,,b.split(,)在 1.8.7 返回[a, b]丢弃空字段而 1.9 返回[a, , b]。若你解析 CSV 日志且字段允许为空则必须显式指定limit参数line.split(,, -1)。第三雷Time.parse的时区歧义Time.parse(2023-01-01)在 1.8.7 默认解析为本地时区CST但 Nagios 性能数据要求时间戳为 UTC。必须强制Time.parse(2023-01-01).utc.strftime(%Y-%m-%dT%H:%M:%SZ)。第四雷IO.popen的信号继承IO.popen(sleep 10) { |io| io.read }在 1.8.7 中子进程会继承父进程的SIGPIPE处理导致 Nagios 主进程收到SIGPIPE后异常退出。解决方案是显式忽略IO.popen(trap PIPE; sleep 10) { |io| io.read }。第五雷Regexp.escape的 Unicode 问题Ruby 1.8.7 的Regexp.escape不处理多字节字符若你的日志含中文Regexp.escape(错误)返回错误非转义导致正则匹配失败。必须手动替换str.gsub(/([.^$|*?()[{\\])/,\\\\\1)。注意所有这些雷区我都封装进了公共库nagios_plugin_helper.rb后文详述新插件只需require ./nagios_plugin_helper.rb即可免疫。这是多年踩坑沉淀出的“防爆盔甲”。3.2 Nagios 插件协议的硬性规范与性能数据格式详解Nagios 插件输出必须严格遵循 Nagios Plugin Development Guidelines 否则会被 Nagios 主程序标记为UNKNOWN。核心规则有三条第一输出格式必须为两行或一行第一行STATUS: Human readable message | perfdataSTATUS 为大写冒号后空一格第二行可选详细诊断信息仅当--verbose参数存在时输出perfdata部分必须以|开头各指标用空格分隔格式为labelvalue[UOM];[warn];[crit];[min];[max]例如OK: HTTP response time 123ms | time123ms;200;500;0;10000 http_codes200c;;;0;1000这里time123ms;200;500;0;10000表示指标名time值123ms警告阈值200ms严重阈值500ms最小值0最大值10000mshttp_codes200c;;;0;1000表示200c200 响应次数无警告/严重阈值范围0-1000。第二退出码决定告警级别exit 0→ OK绿色exit 1→ WARNING黄色exit 2→ CRITICAL红色exit 3→ UNKNOWN灰色表示插件自身异常如超时、权限不足、命令未找到关键点exit 1和exit 2的语义由插件逻辑定义Nagios 不做解释。例如磁盘使用率 90% 应设为 CRITICAL但 85% 可设为 WARNING而某个业务队列长度 1000 是 CRITICAL500 是 WARNING——这个映射必须在插件中硬编码不能由 Nagios 配置。第三超时控制必须由插件自身实现Nagios 的check_command配置中虽有timeout参数但它是粗粒度的秒级且依赖kill -9强杀进程可能留下僵尸进程。最佳实践是在 Ruby 插件中用Timeout.timeout包裹核心逻辑begin Timeout.timeout(15) do # 所有耗时操作放在这里网络请求、文件读取、命令执行 end rescue Timeout::Error puts CRITICAL: Plugin execution timeout after 15 seconds | time15s;10;15;0;30 exit 2 end注意Timeout.timeout在 Ruby 1.8.7 中有已知竞态问题必须配合Thread.abort_on_exception true使用否则超时后主线程可能继续执行。3.3 CentOS 6 系统级限制与绕过技巧CentOS 6 的ulimit和sysctl设置对插件稳定性影响巨大必须在开发阶段就纳入考量文件描述符限制nagios用户默认ulimit -n为 1024而一个插件若需同时探测 20 个端口每个连接占用 2 个 fdsocket pipe很容易触顶。解决方案不是改全局limits.conf需重启 Nagios而是在插件开头主动降低并发数max_fd ulimit -n.to_i - 100 # 预留 100 个 fd 给系统 concurrent_limit [max_fd / 2, 10].min # 最大并发数不超过 10时间精度限制CentOS 6 内核的gettimeofday()精度为 10msTime.now.usec返回值总是0或10000的倍数。若你写一个毫秒级响应时间监控不能依赖Time.now而应调用clock_gettime(CLOCK_MONOTONIC)。Ruby 1.8.7 无此接口但我们用FiddleRuby 1.8.7 内置 FFI 库调用require fiddle CLOCK_MONOTONIC 1 struct_timespec Fiddle::CStructBuilder.new do long :tv_sec long :tv_nsec end ts struct_timespec.malloc Fiddle.dlopen(librt.so.1) { |lib| lib[clock_gettime].call(CLOCK_MONOTONIC, ts.to_ptr) } nanos ts.tv_sec * 1_000_000_000 ts.tv_nsecSELinux 策略干扰CentOS 6 默认启用 SELinuxnagios用户被限制在nagios_t域无法读取/proc下某些文件如/proc/sys/net/ipv4/ip_forward。sestatus -v查看当前策略若需访问必须用audit2allow生成自定义策略模块而非直接setenforce 0违反安全基线。我为一个读取网卡错包率的插件生成的策略模块仅 3 行module nagios_proc_read 1.0; require { type nagios_t; type proc_net_t; class file { read getattr open }; } allow nagios_t proc_net_t:file { read getattr open };这些不是“高级技巧”而是让插件在真实生产环境中不掉链子的基础设施层保障。忽略它们再漂亮的 Ruby 代码也会在凌晨三点因一个EMFILE错误触发误告警。4. 实操过程与核心环节实现从零编写一个 Web 服务健康检查插件4.1 环境准备与最小依赖验证在目标 CentOS 6 机器上首先确认基础环境# 检查 Ruby 版本和路径 $ ruby --version ruby 1.8.7 (2013-06-27 patchlevel 374) [x86_64-linux] $ which ruby /usr/bin/ruby # 检查 Nagios 插件目录通常为 /usr/lib64/nagios/plugins/ 或 /usr/lib/nagios/plugins/ $ ls -l /usr/lib64/nagios/plugins/ total 12 -rwxr-xr-x 1 root root 12345 Jan 15 10:23 check_http -rwxr-xr-x 1 root root 6789 Jan 15 10:23 check_ping # 检查必要系统命令是否存在 $ for cmd in curl wget nc; do echo $cmd: $(which $cmd || echo MISSING); done curl: /usr/bin/curl wget: /usr/bin/wget nc: /usr/bin/nc # 检查 json 模块EPEL 源需提前启用 $ yum list installed | grep json ruby-json.x86_64 1.4.6-1.el6 epel若ruby-json未安装启用 EPEL 并安装# CentOS 6 EPEL 源地址清华镜像站 $ sudo rpm -Uvh https://mirrors.tuna.tsinghua.edu.cn/epel/epel-release-latest-6.noarch.rpm $ sudo yum install ruby-json -y提示不要用gem install json它会安装到/usr/local/lib/ruby/gems/1.8/而/usr/bin/ruby默认不搜索该路径。yum install安装的包位于/usr/lib64/ruby/1.8/与系统 Ruby 完全兼容。4.2 编写核心插件check_web_health.rb我们以检测一个内部 Web 服务的健康状态为例要求检查 HTTP 状态码是否为 200解析响应 JSON 中的status字段是否为healthy测量响应时间毫秒支持自定义 URL、超时、警告/严重阈值完整代码保存为/usr/lib64/nagios/plugins/check_web_health.rb#!/usr/bin/ruby # Nagios Plugin: check_web_health.rb # Checks HTTP status and JSON health field of a web service # Usage: ./check_web_health.rb -u URL [-t TIMEOUT] [-w WARN_MS] [-c CRIT_MS] require open3 require uri require json # Helper method to safely parse JSON (handles Ruby 1.8.7 quirks) def safe_json_parse(json_str) begin JSON.parse(json_str) rescue Exception e return nil end end # Parse command line arguments url nil timeout 10 warn_ms 200 crit_ms 500 ARGV.each_with_index do |arg, i| case arg when -u, --url url ARGV[i1] when -t, --timeout timeout ARGV[i1].to_i when -w, --warning warn_ms ARGV[i1].to_i when -c, --critical crit_ms ARGV[i1].to_i end end # Validate required argument if url.nil? puts UNKNOWN: Missing required argument -u URL | time0ms;#{warn_ms};#{crit_ms};0;10000 exit 3 end # Normalize URL (add http:// if missing) uri URI.parse(url) uri.scheme || http uri.host || localhost url uri.to_s # Build curl command curl_cmd curl -s -w %{http_code} -o /dev/stdout -m #{timeout} #{Shellwords.escape(url)} # Execute with timeout start_time Time.now output status_code begin Timeout.timeout(timeout 2) do # Add 2s buffer for curl overhead Open3.popen3(curl_cmd) do |stdin, stdout, stderr, wait_thr| output stdout.read status_code stderr.read.strip[-3..-1] # Last 3 chars of stderr is HTTP code wait_thr.value # Wait for process to finish end end rescue Timeout::Error puts CRITICAL: HTTP request timeout after #{timeout}s | time#{timeout*1000}ms;#{warn_ms};#{crit_ms};0;10000 exit 2 rescue Exception e puts UNKNOWN: HTTP request failed: #{e.message} | time0ms;#{warn_ms};#{crit_ms};0;10000 exit 3 end # Calculate response time elapsed_ms ((Time.now - start_time) * 1000).round # Check HTTP status code if status_code ! 200 puts CRITICAL: HTTP #{status_code} for #{url} | time#{elapsed_ms}ms;#{warn_ms};#{crit_ms};0;10000 exit 2 end # Parse JSON response response_json safe_json_parse(output) if response_json.nil? puts CRITICAL: Invalid JSON response from #{url} | time#{elapsed_ms}ms;#{warn_ms};#{crit_ms};0;10000 exit 2 end # Check health status field health_status response_json[status] || response_json[health] || unknown if health_status ! healthy puts CRITICAL: Service unhealthy: #{health_status} | time#{elapsed_ms}ms;#{warn_ms};#{crit_ms};0;10000 exit 2 end # All checks passed if elapsed_ms crit_ms puts CRITICAL: Response time #{elapsed_ms}ms #{crit_ms}ms | time#{elapsed_ms}ms;#{warn_ms};#{crit_ms};0;10000 exit 2 elsif elapsed_ms warn_ms puts WARNING: Response time #{elapsed_ms}ms #{warn_ms}ms | time#{elapsed_ms}ms;#{warn_ms};#{crit_ms};0;10000 exit 1 else puts OK: Service healthy, response time #{elapsed_ms}ms | time#{elapsed_ms}ms;#{warn_ms};#{crit_ms};0;10000 exit 0 end4.3 权限设置与 Nagios 配置集成插件文件必须满足 Nagios 安全要求# 设置所有权和权限nagios 用户必须可执行 $ sudo chown root:nagios /usr/lib64/nagios/plugins/check_web_health.rb $ sudo chmod 755 /usr/lib64/nagios/plugins/check_web_health.rb # 验证能否被 nagios 用户执行切换用户测试 $ sudo -u nagios /usr/lib64/nagios/plugins/check_web_health.rb -u http://localhost:8080/health OK: Service healthy, response time 42ms | time42ms;200;500;0;10000在 Nagios 配置中添加命令定义/etc/nagios/objects/commands.cfgdefine command{ command_name check_web_health command_line $USER1$/check_web_health.rb -u $ARG1$ -t $ARG2$ -w $ARG3$ -c $ARG4$ }定义服务监控/etc/nagios/objects/services.cfgdefine service{ use generic-service host_name web-server-01 service_description Web Health Check check_command check_web_health!http://10.0.1.100:8080/health!15!300!600 normal_check_interval 5 retry_check_interval 1 }注意$ARG1$等参数在 Nagios 中自动替换!是参数分隔符。此处ARG1是 URLARG2是超时秒数ARG3是警告毫秒ARG4是严重毫秒。配置后重启 Nagiossudo service nagios restart。4.4 性能数据在 Nagios Web UI 中的可视化验证Nagios 自身不绘图但性能数据perfdata会被pnp4nagios或nagiosgraph等插件捕获。以pnp4nagios为例确认其已安装并启用$ rpm -qa | grep pnp4nagios pnp4nagios-0.6.25-1.el6.x86_64 $ ls -l /usr/lib64/nagios/plugins/process-perfdata.pl -rwxr-xr-x 1 root root 12345 Jun 10 2022 /usr/lib64/nagios/plugins/process-perfdata.pl在 Nagios Web UI 中点击对应服务选择 “Perf Data” 标签页应看到类似图表横轴为时间纵轴为time毫秒和http_codes计数。若图表为空检查nagios.cfg中process_performance_data1 service_perfdata_commandprocess-service-perfdata并确认process-service-perfdata命令指向正确的process-perfdata.pl脚本。5. 常见问题与排查技巧实录那些让你加班到凌晨的真问题5.1 典型问题速查表问题现象根本原因快速诊断命令解决方案UNKNOWN: Command not foundNagios 调用时 PATH 不包含/usr/binsudo -u nagios echo $PATH在command_line中使用绝对路径/usr/bin/ruby $USER1$/check_web_health.rbCRITICAL: HTTP 000 for ...curl无法解析域名或连接拒绝sudo -u nagios curl -v http://target/检查/etc/resolv.conf、防火墙、目标服务是否监听0.0.0.0UNKNOWN: Invalid JSON response响应体含 BOM 头或非 UTF-8 编码sudo -u nagios curl -s http://target/ | hexdump -C | head在 Ruby 中output.gsub!(/\A\xEF\xBB\xBF/, )去 BOM或用iconv -f GBK -t UTF-8转码CRITICAL: Plugin execution timeout after 15 secondsTimeout.timeout与IO.popen交互异常strace -u nagios -e traceclone,wait4,kill /usr/bin/ruby ...改用Process.spawnProcess.wait2替代Open3.popen3避免信号冲突WARNING: Response time 0msTime.now在高负载下精度丢失sudo -u nagios ruby -e 10.times{p Time.now.usec}改用Fiddle调用clock_gettime见 3.3 节5.2 我踩过的三个最深的坑及独家修复技巧坑一nagios用户的LD_LIBRARY_PATH导致curlSSL 连接失败现象插件对 HTTPS URL 返回HTTP 000但手动sudo -u nagios curl -v https://google.com正常。诊断strace显示dlopen(/lib64/libssl.so.10)失败原因是 Nagios 启动时设置了LD_LIBRARY_PATH/usr/lib64/nagios而该路径下有旧版libssl.so。修复技巧在插件开头强制清除ENV.delete(LD_LIBRARY_PATH) ENV.delete(LD_RUN_PATH)并在command_line中添加env -i前缀env -i /usr/bin/ruby $USER1$/check_web_health.rb ...。这是最干净的隔离方式。坑二/tmp目录被tmpwatch清理导致插件间歇性失败现象插件偶尔返回No such file or directory日志显示临时文件路径错误。根因CentOS 6 的/etc/cron.daily/tmpwatch默认清理 10 天未访问的/tmp文件而插件生成的临时文件名含 PIDtmpwatch会误删正在使用的文件。独家修复在插件中不使用/tmp改用/var/tmp/nagios_plugin_XXXXXX并设置sticky bittemp_dir /var/tmp/nagios_plugin_#{Process.pid} Dir.mkdir(temp_dir, 01777) rescue Errno::EEXIST temp_file #{temp_dir}/output_#{rand(10000)}01777权限确保只有文件所有者能删除tmpwatch默认不清理/var/tmp。坑三Ruby 1.8.7 的GC.disable导致内存泄漏累积现象插件运行一周后nagios进程 RSS 内存从 10MB 涨到 200MB最终 OOM。原因为提升性能有同事在插件中加了GC.disable但 Nagios 每次调用都 fork 新进程GC.disable状态被继承导致子进程内存永不回收。终极修复绝不调用GC.disable若需性能优化改用String#replace复用对象或用Array.new(size) { block }预分配数组。我在一个日志行数统计插件中用line_count 0; File.foreach(log_path) { line_count 1 }替代File.readlines.count内存占用从 50MB 降至 2MB。5.3 生产环境部署 checklist必须逐项核对在将插件推入生产前请用此清单交叉验证[ ] 插件文件权限为755所有者为root:nagios[ ]