给节点装心跳：uptime、getconnectioncount 与 ping 的监控组合

为什么从三条只读 RPC 开始

比特币节点的监控可以很复杂，也可以从三条永远只读的 RPC 起步：uptime 返回进程已运行的秒数，是个纯内存计数器，节点一重启就归零；getconnectioncount 返回当前连接总数，数字是出站到入站的总和；ping 让节点向它的所有对等发送探测，虽不直接返回耗时汇总，但配合日志与常规响应能判断进程是否在正常干活。这三条调用成本几乎为零、不改任何状态，适合脚本每隔几十秒跑一次——这正是”心跳”的含义：用最便宜的方式，区分”没事”和”出事了”。

每个指标的真实含义

uptime 归零只有两类原因：进程真的重启了，或者 RPC 连到了另一个数据目录的实例。监控里把 uptime 归零当作最高优先级事件是对的，因为重启意味着可能有人手动维护、系统自动重启、甚至崩溃拉起，每一种都该有人知道。getconnectioncount 的阈值要按经验设：节点默认希望维持的出站连接是个位数到二十左右的量级，加上别人连进来的入站连接，总数通常在几十以上；长期掉到个位数说明网络质量出问题（DNS 失败、出站端口被封、运营商限制），但不一定是宕机。真正危险的是”连接数正常但同步不前进”——那是另一类故障，必须配合链高度类指标才看得见。ping 的价值在于它的响应是否干脆：进程卡死在锁或磁盘 I/O 上时，对等连接可能还挂着，但 RPC 响应开始发黏。

三个常见误读

第一，把连接数当健康分：连接多不代表节点同步到位，只代表网络层活着。第二，把 uptime 当同步时长：uptime 是进程时长，不是数据追平时长，跑了一年的节点也可能昨天才刚追上链尖。第三，把 ping 失败当断网：ping 的调用只是触发探测，RPC 超时可能只是本机负载，未必是公网断了。健康的监控面板应该像这样分层：进程层（uptime）、连接层（getconnectioncount）、请求层（RPC 响应时间）、数据层（区块高度与链尖对比）。前三层能覆盖绝大多数”节点出事”的形态，数据层则负责那些”活着但落伍”的慢性故障。

一条低成本告警线的写法

脚本每 30 秒采一次三项指标：uptime 相比上次记录减小（归零）则发告警；连接总数连续 10 次低于一个保守阈值（比如个位数）则发提醒；RPC 响应超过设定的超时值连续 3 次则发提醒。再加一个每日巡检：uptime 若低于 24 小时且没人手动重启过，把它当成未登记的重启来查。这套规则不需要任何外部监控系统，一台小机器加一段循环脚本就够。阈值宁可保守，宁可稍微吵一点——监控初期误报的成本，远比漏报一次节点假死便宜。

运维监控的本质是把”我以为没事”换成”我知道没出事”。本文不构成投资建议。

把这组脚本跑起来的细节

实现层面有几个坑值得提前绕开。RPC 调用本身要设超时：一个卡死的节点会让没有超时的脚本永久挂起，反而让你错过告警时机，正确姿势是给 curl 或客户端设一个几秒的上限，超时即视为一次请求层告警。采样要记录时间戳连续序列而不是单点值，uptime 归零这类事件只有和上一次读数对比才能判定。数据落盘用最简单的追加文本即可，不必引入时序数据库；查询时用相邻两条记录做差分就够。第二个坑是权限：监控脚本只需要只读 RPC 权限，不要复用带钱包发送权限的凭据，避免监控机成为攻击入口时造成更大损失。第三个坑是节点刚重启的正常窗口：维护计划内主动重启会让 uptime 归零，值班流程里应有”维护中标记”跳过这一类预期告警，否则每周例行维护会变成告警疲劳的训练课。把这三条加进脚本，前文那套心跳规则才真正可用。