uptime 数的是秒表不是钟表：Bitcoin Core 节点运行时长为何不会跳变

把比特币节点接进监控，uptime 是最顺手的一个数字：返回一个整数，单位秒，节点跑了多久一目了然。但有两个问题值得先想清楚再把它接上仪表盘：这个数字从哪一刻起算？调整系统时间会不会让它跳一下？Bitcoin Core 31.0 的源码给出的答案，会让一部分既有的监控直觉需要修正。

起点是进程，不是开机

RPC 命令 uptime 在 rpc/server.cpp 里注册，实现只有一行核心逻辑：调用底层 GetUptime() 并把结果折算成秒返回。而 GetUptime 的定义在 common/system.cpp，短到值得贴出来：函数内部持有一个静态变量 g_startup_time，第一次被调用时记下 SteadyClock::now()——也就是进程运行到这一瞬间的单调时钟读数；此后每次调用，返回当前单调时钟读数减去这个起点。

注意两个细节。其一，起点记的是进程时间轴上的位置，与这台机器的开机时长无关：机器凌晨四点开的机、节点早上九点才被拉起，uptime 从九点开始数。其二，静态变量在首次调用时定格——节点启动早期若有内部代码先调过一次 uptime，起点就定格在那一刻，通常与进程创建几乎同时，差异可忽略，但严格说它标记的是「第一次有人问起运行时长」的时刻。

用的是秒表，不是钟表

真正让 uptime 与日志时间戳分道扬镳的是 SteadyClock。C++ 标准里的 std::chrono::steady_clock 是单调时钟：它只向前走、永不调头，走的是系统秒表而非墙上时钟。操作系统管理员手动改时间、NTP 把时钟向回拽、夏令时（在采用它的系统上）把钟拨快一小时——这些动作调整的都属于墙上时钟，单调时钟不为所动。

这带来一条监控语义上的铁律：uptime 不会因改时间而跳变。一个跑了 3600 秒的节点，无论你是把系统时间快拨一天还是回拨到上月，下一次查询依然在一小时量级附近增长。反过来，它突然变小只有一种解释：进程重启过——起点变量随旧进程消亡，新进程重新定格。

哪些常见解读会出错

第一，用 uptime 推算「节点处理了多少时间的数据」不可靠。uptime 大只说明进程活着且从未重启，同步进度要用区块高度与 tip 类指标衡量（三者的分工见 给节点装心跳：uptime、getconnectioncount 与 ping 的监控组合）。第二，把 uptime 与 getnetworkinfo 的 timeoffset 混着用会闹笑话：后者度量的是本机墙上时钟与对端样本的中位偏差，而 uptime 根本不走墙上时钟——时钟飘了十几分钟，uptime 岿然不动，而它提示你日志时间戳与真实时刻对不上了（时钟告警的触发链见 区块时间只能领先两小时）。第三，想区分「机器重启」与「节点重启」，uptime 帮不了你——它只认节点进程；机器级时长请读操作系统的 uptime 或 /proc/uptime 一类接口，两个数字相减还能近似出「开机后过了多久才启动节点」。

接进仪表盘的建议

把 uptime 当重启探针用是它的最佳岗位：规则写成「uptime 低于阈值即视为刚重启」，比抓取进程退出事件更轻量；与日志文件的重开标记、getrpcinfo 里请求记录的起点交叉核对，可以拼出一次重启的完整时间线。阈值别设太苛刻：计划内维护（升级、调参重启）同样会归零，需要人工或部署系统把预期重启与意外重启在告警上分开。

最后回到源码本身：这个 RPC 的全部实现不足十行，却把「进程活了多久」这个看似朴素的问题回答得滴水不漏——用单调性换掉了对系统时钟正确性的依赖。顺带一条版本脚注：uptime 属于 Bitcoin Core 的通用 RPC（无需钱包），在任何启用了 RPC 服务的节点形态下都可以直接调用，返回值为无符号整数秒；如果你的监控面板需要毫秒级精度，得自己加密采样节拍，而不是指望这个数字更细。监控里那些看起来简单的数字，往往值得先看清它站在哪块基石上。