脚本里那句”字段等于空字符串就说明节点一切正常”的健康检查，某天突然永久成立了——这是很多自建监控在比特币核心升级后遇到的第一怪。原因不在你的代码，而在接口：getblockchaininfo、getnetworkinfo、getmininginfo 三个 RPC 的 warnings 字段，从 v28.0 起返回的不再是”一条警告文本”，而是”当前所有生效警告的数组”。
为什么过去只有一条
warnings 承载的是节点自己认为你需要知道的健康异常：磁盘空间不足、区块索引有问题、交易池出现不一致、数据目录读写失败等等。这类状态在节点内部是分项维护的，每种问题各自有一个”当前是否成立”的标记。旧接口在序列化时只能把这些状态压成一段文本、挑其中一条输出。于是就有了运维最讨厌的一种现象：机器同时有两个问题，脚本读到的字段里只写着其中一个；你熬夜修完它，另一个才浮出水面。
数组化之后，节点把所有生效的警告原样列全，没有生效警告时返回空数组。这个方向也不是从 v28 才开始铺：钱包侧的 createwallet、loadwallet 等接口早在 v25.0 就把单条 warning 字段换成了 warnings 数组，旧的字符串字段在 v26.0 被彻底删除，节点侧的三大信息接口是这条统一路线上较晚的一环。
兼容开关的用法与两个陷阱
如果你维护的脚本暂时改不动，v28.0 的发布说明给了一条明确的退路：在配置里加 -deprecatedrpc=warnings，字段退回旧的字符串形态。这个开关是通用的：deprecatedrpc 可以重复出现，每次带一个被显式许可的旧行为名，只有列出来的那一项会退回旧语义。
两个陷阱要提前知道。第一，带这个参数跑，返回的仍然是”其中一条”，仍然会掩盖其他问题——它是止血带，不是修复。第二，它属于临时兼容措施，发布说明的措辞就是 temporarily，将来的版本会连退路一起删掉，届时脚本又要再坏一次。正确用法是拿它买几天时间，把解析逻辑改成”接受数组、空数组视为正常、非空时逐条上报”。
脚本改造的三条原则
第一，别再用相等判断做健康检查。字段类型变了以后，“等于空字符串”这个条件永远不成立，节点会被误判成一直在报警。改成”长度为 0 即健康”，两种形态都兼容。
第二，把每条警告当作独立事件处理，附来源。同一个”磁盘相关”的告警，在空间不足和索引损坏时对应的处置动作完全不同，合并处理只会拖慢恢复。
第三，不要只在 RPC 里看它。同一个健康状态在启动日志里也有对应告警行；无人值守节点把日志告警级别接入监控，通常比几秒一次的轮询更早发现问题。RPC 字段的定位是”给人或脚本做即时判断”，不承担历史留痕。
顺带一个易混点：warnings 说的是”这台节点自己遇到了问题”，与”网络出了状况”无关。它和区块高度、连接数、同步状态一起构成节点健康的最小四件套，缺一件就容易把一个正在出问题的节点当成正常节点继续供数据。
同一个思路也适用于对外提供数据的服务：如果这台节点同时给钱包或索引器供后端，把告警数组接入告警通道比写进本地日志更有价值——一条”索引落后”的告警如果只落在没人看的日志文件里，等发现时，你的用户可能已经对着旧数据做了错误决策。反过来，把告警数组接进监控系统时要注意去抖：某些告警在磁盘清理、索引追平的短暂窗口里会一闪而过，瞬时触发就发通知会被噪声淹没，合理做法是持续若干个采样周期仍非空才升级成告警。
风险提示：本文描述接口字段演变与运维实践，不构成投资建议；节点告警可能涉及数据完整性问题，处置前请备份数据目录，重要判断请结合日志与官方文档复核。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。