1. 从一次“重启告警”说起现场还原与第一反应凌晨一点钉钉群连响三声告警标题写着“MYSQL_PROD_01 instance restarted”触发表达式是changes(process_start_time_seconds{jobmysql}[5m]) 0。值班同事把截图丢进群里我的第一反应是看看数据库内部状态登录上去执行show status like uptime返回的是一个持续了两百多天的运行秒数线程数、连接数、慢查询统计全部正常没有任何重启痕迹。群里的对话几乎可以预料“数据库没动Prometheus是不是抽风了”这种场景在维护过 Prometheus 监控数据库的人眼里并不陌生监控判定数据库重启了数据库自己却坚持声称根本没重启。两边掌握的证据完全冲突而且谁都不是故意说谎。这个问题的核心在于Prometheus 眼里的“重启”和数据库内部的“重启”是两个不同维度的事件。这篇文章我会把这类误报的根因拆开讲清楚从 Prometheus 判定重启的原理、到最常见的几种“假重启”信号、再到真实案例复盘和告警规则优化一次讲透。如果你正在写数据库相关的 PromQL 告警规则或者被这类“幽灵重启”告警折腾过这篇内容应该能帮你省掉不少凌晨的折腾。1.1 告警长什么样DBA为什么坚决说没重启先还原一下告警本身。这类告警通常由 Alertmanager 聚合后发出正文里往往只有几条标签和一个简短的 PromQL 表达式。告警属性示例值告警名称MySQL process restarted触发表达式changes(process_start_time_seconds{jobmysql}[5m]) 0触发时间2025-06-11 23:58:17监控目标instance10.0.8.15:9104 jobmysql告警级别P1 / Critical收到告警后DBA 的第一反应通常是查数据库进程到底有没有重启show status like uptime看运行时长检查 processlist 里的连接创建时间或者看一眼 binlog 和 relay log 的文件序号。如果这些证据都指向“进程一直在线”DBA 就会理直气壮地回复“数据库没动”。站在他的视角这句话没有错因为数据库内部确实没有发生过重启事件。但 Prometheus 也不是无中生有。它观察到的process_start_time_seconds确实在窗口内发生了变化这个值代表着数据库进程的启动时间戳正常情况下恒定不变一旦出现跳变监控端有充分的理由判定“进程重启了”。两边说的都是各自视角下的客观事实问题出在“进程启动时间戳变化”这个信号本身能否等价于“数据库重启”。实际排查中这个等价关系经常不成立也就是我们要聊的“假重启”。1.2 常规排查路径先别改告警规则先看这五张图遇到这类告警我的建议是不要急着去修改告警规则、不要 silence先拉五张图把证据链补完整。第一张是process_start_time_seconds的曲线重点看它是单点跳变还是持续变化跳变幅度有多大。第二张是同一台机器的node_time_seconds或者系统时间曲线看同一时间窗内有没有出现时间回拨或跳变如果系统时间被 NTP 调整过进程启动时间戳的计算基准就会被带偏。第三张是采集器的up指标看数据库 exporter 在告警前有没有短暂置 0。第四张是数据库内部 uptime 指标MySQL 对应mysql_global_status_uptimePostgreSQL 对应pg_postmaster_start_time如果进程真的重启了这个值一定会归零重新开始累计。第五张要看部署环境容器场景下查 Pod 重启次数和漂移记录物理机场景下查 systemd 的服务状态变更和 journalctl 日志时间线。这五张图拉出来误报的方向基本就能锁定。很多人拿到告警的第一反应是打开 Alertmanager 把规则静默掉这是最危险的操作。因为“谎报重启”背后往往藏着一个真实问题可能是监控采集器不稳定、系统时钟异常也可能是数据库确实发生了自动恢复但没有被业务感知。silence 只能让告警不再打扰你却无法让问题消失所以我一直坚持“先看证据再动规则”。1.3 数据口径数据库uptime与Prometheus怎么看“重启”这里需要理清一个基础概念Prometheus 本身没有“重启事件”这种记录它只保存时间序列。我们判断一个进程是否重启通常依赖三类信号。第一类是进程启动时间戳也就是process_start_time_seconds一旦变化就说明进程的启动时刻变了。第二类是数据库内部的运行时长指标比如 MySQL 的 uptime 或者pg_postmaster_start_time归零重计才是真正的进程级重启。第三类是业务层面的信号比如连接数断崖、线程数清零、主从延迟突变这些指标能反映出服务可用性的变化。这三类信号在正常运行时是同步的进程真重启时启动时间戳变化、内部 uptime 归零、连接数重建会在同一时间窗内一起出现。但如果只有启动时间戳变化而内部 uptime 连续说明问题大概率出在采集端或时间基准上。我在排查中会把这句话当作一个基本判断框架先问自己哪个指标变了哪个指标没变变化之间能不能用“数据库进程重启”这一个假设统一解释解释不通就别急着下结论。2. “假重启”的机制解剖毫厘之间藏着哪些变量要理解为什么数据库没动、Prometheus 却说重启了必须先搞清楚 Prometheus 是如何得到进程启动时间戳的。这个过程不算复杂但里面藏着好几个容易出问题的细节每一个细节都可能让一个本来稳稳当当的监控项变得敏感异常。2.1 Prometheus判定重启的核心依据process_start_time_seconds与changes()在 Linux 环境下process_start_time_seconds通常由 node_exporter 或 mysqld_exporter 暴露。它的计算方式是读取/proc/[pid]/stat中的 starttime 字段这个字段记录的是进程自系统启动以来经过的时钟 tick 数再结合系统启动时间换算成 Unix 时间戳。对 mysqld 这类常驻进程来说这个值从进程创建那一刻起就固定了无论系统运行多久都不会改变所以它成了判断重启的天然锚点。PromQL 里有一个专门配合它使用的函数changes()作用是统计一个时间序列在指定时间窗口内发生变化的次数。changes(process_start_time_seconds[5m]) 0表达的就是“在最近 5 分钟内进程启动时间戳发生过变化”。这个判断逻辑本身是合理的一旦这个值变了说明被监控对象确实重新创建过。但它隐含了两个前提假设第一这个时间戳完全来自进程本身第二系统时间轴是稳定的。实际运维中这两个前提都可能被打破。Prometheus 默认的抓取间隔通常是 15 秒如果某个 target 在超过 5 分钟没有上报数据这个时间序列会被标记为 stale也就是过期。过期之后再恢复上报某些聚合函数的计算结果会出现波动这也是很多“假重启”告警在查询层面被放大的原因。你看到的可能不是进程真的重启了而是时间序列的新鲜度发生变化导致 changes 的计算结果出现了非预期跳变。2.2 四种典型的“类重启”信号根据我这几年排查监控误报的经验所谓“假重启”基本逃不出下面四类原因每一类背后的机制都不一样特征曲线也各不相同。类型表面现象根因特征曲线验证方法采集器自身重启start_time 变化internal uptime 连续mysqld_exporter / node_exporter 被 OOM 或手动拉起up 指标短暂置 0restart 计数增加查看 systemd 状态与 journalctl 日志系统时间跳变start_time 小幅突变NTP 回拨或手动调整系统时间node_time_seconds 同时出现台阶对比 node_time_seconds查系统日志PID 复用start_time 变化但进程其实没重启采集目标 PID 被新进程复用指标值和 /proc 实际信息不一致执行 cat /proc/[pid]/stat 对比容器漂移或高可用切换start_time 变化业务侧无感知调度器重排 Pod、VIP 切换后端实例连接数、线程数等曲线同时跳变查容器事件、VIP 变动记录第一种采集器自身重启非常常见尤其是内存比较紧张的机器上mysqld_exporter 这类小进程很容易被内核 OOM Killer 选中随后被 systemd 自动拉起来。数据库没动但它的“眼睛”眨了一下Prometheus 就把这次眨眼当成了数据库重启。第二种系统时间跳变是最隐蔽的因为调整的往往是毫秒级或秒级的偏移肉眼根本察觉不到但在计算启动时间戳时会留下清晰的痕迹。第三种 PID 复用主要影响 exporter 这类生命周期短的进程数据库主进程上概率较低。第四种容器漂移和高可用切换在云原生环境里越来越常见数据库数据没丢、业务无感但监控视角的实例已经换了一个。2.3 你的告警规则为什么这么容易被触发很多时候误报频发不是因为监控工具不行而是告警规则本身写得太粗糙。我自己早期也踩过不少坑总结下来最容易触发误报的写法有这么几种。第一是时间窗口设得太短。changes(process_start_time_seconds[1m]) 0这种规则只要采集端一个抓取周期内出现抖动就会命中Prometheus 的抓取偶尔延迟个一两秒或者网络产生瞬时拥塞都会造成指标值的异常波动被误认为重启。第二是忽略了时间基准变化。规则里只判断启动时间戳变化没有同时判断node_time_seconds是否变化于是 NTP 回拨就被当成了一次重启。第三是不区分“数据库进程重启”和“采集器重启”只要 start_time 变化就触发 Critical 级告警把监控链路的脆弱性放大成了业务故障。第四是for子句缺失或过短导致一次瞬时毛刺直接升级到最高级别通知。我后来在写告警规则时都会过一遍自检清单这个规则的判断窗口能不能覆盖至少两到三个抓取周期有没有结合其他指标共同确认变化幅度是否需要设置一个阈值如果这些问题回答不上来规则仍然处于“看见影子就开枪”的状态。2.4 疑似误报速查表排查过程中我习惯把判断口诀压缩成一张速查表遇到告警先对照一遍往往能在十分钟内定位方向。检查项正常情况异常含义process_start_time_seconds 是否跳变恒定进程创建时间发生变化同节点 node_time_seconds 是否跳变平稳递增系统时间被调整可能导致假重启up 指标是否连续为 1连续出现 0 说明采集器中断过mysql_global_status_uptime 是否连续单调递增归零重启才是数据库进程级重启容器场景 Pod 重启次数无变化发生变化说明运行时重建数据库连接数是否有断崖平稳波动整体归零可能意味着实例不可用这个表格的价值在于帮你快速区分“该处理的”和“该忽略的”。如果只有第一项变化其余全正常那大概率是时间或采集层面的问题如果多项同时异常就可能是数据库真的发生了一次无人察觉的自动恢复需要进一步追查原因。3. 三个真实案例复盘从“谎报”到“实锤”理论讲再多不如实际复盘几个案例有说服力。下面这三个案例都是我在日常维护中真实遇到过的每个的根因都不一样但它们的共同点是数据库进程本身都没有主动重启监控却给出了重启告警。3.1 案例一NTP回拨几十毫秒监控自证“重启”第一个案例发生在一套测试环境的 MySQL 实例上。凌晨四点告警触发process_start_time_seconds从 1738496000 变成 1738496032变化了 32 秒。从数字上看这不像一个大跨度的时间跳变更像是进程在 32 秒前被重新创建。但我登录数据库后uptime 显示实例已经运行了 18 天完全没有中断迹象。我把 Grafana 时间轴拉近叠加了node_time_seconds曲线发现在同一时刻节点系统时间出现了一个明显的回跳台阶幅度大约也是 32 秒和进程启动时间的变化完全吻合。再查系统日志确认是 NTP 服务在同步时对系统时间进行了一次回拨。原理上并不复杂node_exporter 计算进程启动时间时要结合当前系统时间做换算墙上时钟被回拨后倒推出来的进程启动时间就会向后偏移于是在 Prometheus 眼里一个已经跑了 18 天的进程突然变成了“32 秒前才启动”。这个案例的教训有两层。第一层是系统级对运行监控 agent 的机器要谨慎配置 NTP 同步策略避免出现大步回拨如果一个节点上同时跑着大量被监控进程主机时间任何一次微小调整都可能在监控端造成连锁误报。第二层是规则级判断重启时不能只盯着启动时间戳还要把节点时间变化作为排除项否则 NTP 的毫厘之误就会升级成一次数据库“重启故障”。3.2 案例二exporter被systemd静默拉起数据库毫发无损第二个案例更具迷惑性。告警显示 MySQL 进程重启但数据库的 uptime 连续我知道问题多半出在采集链路。打开 Prometheus 的 Target 页面up指标在告警前出现过一次 0 值持续时间大约 40 秒随后恢复为 1。这个细节说明数据库 exporter 在那段时间里不可达。再去被监控节点上执行systemctl status mysqld_exporter进程状态显示 active但 restart 计数已经增加了 1。翻看 journalctl发现了 OOM Killer 的行内存压力导致 mysqld_exporter 被杀systemd 随即把它从一堆日志里默默拉了起来。为什么 Prometheus 会把这次 exporter 重启当成数据库重启因为process_start_time_seconds本来抓取的就是 exporter 视角下 mysqld 进程的信息而 exporter 自己重启后它重新采集、重新上报的进程启动时间戳依然是从 mysqld 的/proc里读到的理论上不会变。真正变化的是 exporter 和 Prometheus 之间的通信上下文发生了变化up短暂置 0 后恢复配合抓取端对时间序列新鲜度的判断最终在查询层形成了一个“进程重启过”的假象。这个案例的启示是数据库虽然是核心服务但监控链路本身的稳定性同样重要。mysqld_exporter 这类小进程往往被忽视内存限制没配、资源争抢时第一个被牺牲结果就是数据库还稳稳跑着报警却已经打到值班电话上了。我后来把所有 exporter 都纳入统一资源限制管理并为 exporter 自身重建设立了单独的、低等级的告警和数据库重启告警区分开。3.3 案例三数据库节点漂移业务无感但监控“眼尖”第三个案例放在容器和主备切换的场景下。业务端通过一套 VIP 访问 MySQL 主库Prometheus 采集的也是这个 VIP 对应的 mysqld_exporter 端口一切看起来都很正常。某天告警触发说数据库重启但这次连数据库内部 uptime 都出现了归零重计的迹象看起来像是实锤。然而 DBA 再次坚持数据库没动因为两个数据库节点各自都运行正常没有主动重启记录。真相是 Keepalived 的 VIP 发生了漂移主库所在节点出现短暂的心跳超时VIP 被切换到备库Prometheus 依然对着 VIP 采集采集到的却是备库实例的指标。备库的process_start_time_seconds在 Prometheus 看来是一个“新的”时间戳内部 uptime 也是从另一个起点开始累计于是一组合计下来一个完整的“重启证据链”就拼出来了。但对业务来说VIP 切换过程中的连接重试让服务几乎没有中断应用日志里也没有出现大规模断连。这个案例说明在数据库主备切换或容器漂移场景下监控对象已经从“某一个具体进程”变成了“某一个服务入口”。如果还固执地用进程启动时间戳去判断服务是否重启必然会出现误报。正确的做法是区分实例监控和服务监控进程级重启看内部 uptime 和 start_time服务级可用性则要结合 VIP 探活、连接数、查询成功率和主从状态来判断。4. 把误报扼杀在规则层告警优化与监控架构加固排查根因的过程固然有意思但真正让运维省心的还是把规则改成“不轻易说谎”的状态。我见过很多团队被误报折磨到把所有重启告警全部静默这等于把监控的双眼蒙上反而危险。更好的路径是在规则层面加入多重确认逻辑让监控在报警之前先自己排除常见干扰。4.1 单一changes()为什么不够组合判断怎么落单一的changes(process_start_time_seconds[5m]) 0有太多误报空间把它作为唯一判据本质上就是在用“猜”代替“确认”。我的做法是把规则拆成两层判断先确认启动时间戳确实变化了再确认这个变化不是一个已知干扰源导致的。第一类干扰排除是系统时间跳变。如果节点时间在同一个窗口内发生了变化那么启动时间戳的变化就不可信可以这样抑制( changes(process_start_time_seconds{jobmysql}[15m]) 0 ) and on(instance) ( changes(node_time_seconds{jobnode}[15m]) 0 )这段表达式的含义是只有在节点时间保持稳定的前提下启动时间戳变化才被认定为可疑事件。如果系统时间自己也跳了那我暂时不认为数据库发生了重启。这个规则能过滤掉案例一里的 NTP 误报。第二类干扰排除是采集器自身重启。要确认数据库进程真正重启最好的证据来自数据库内部MySQL 的mysql_global_status_uptime是一个单调递增的运行秒数进程重启会让它瞬间归零重新累加而 exporter 重启不会影响它的值。所以可以加一个内部 uptime 下降判断( changes(process_start_time_seconds{jobmysql}[15m]) 0 and delta(mysql_global_status_uptime{jobmysql}[15m]) 0 )如果启动时间戳变了但数据库内部 uptime 在窗口内始终保持单调递增说明 mysqld 从来没有重启过问题出在采集端或者环境层。这套组合规则虽然多写了几行 PromQL但能过滤掉绝大部分误报值得为每个核心数据库单独配置一套。4.2 外部探针与服务视角让监控自己排除干扰白盒指标只能告诉我们“进程视角发生了什么”要判断一个数据库服务是否真正可用还需要黑盒探针来补位。我通常会给核心数据库配置两个额外的监控维度TCP 层面的拨测探针和 SQL 层面的执行探针。TCP 探针可以用 blackbox_exporter 来做定期尝试连接数据库端口只要端口能连通、握手成功就证明服务入口是活的。SQL 探针则需要一个很小的探活脚本定时执行select 1把返回结果作为指标上报。这样即使 Prometheus 从白盒指标上看到了“重启”的信号只要黑盒探针连续正常我们就有足够的底气判断这是误报而不是数据库真的不可用。从监控架构设计上我更建议把数据库监控分成三层节点层负责主机资源与系统时间进程层负责 mysqld 或 postgres 进程本身服务层负责客户端视角的可用性。三层指标互相印证单一层级的异常就不会轻易升级成高等级告警。关键数据库实例的告警配置也应该符合这个分层逻辑而不是把所有指标塞进同一条规则里让一个采集器的抖动引发全局红色警报。4.3 告警设计上的几个务实建议最后聊几个告警设计的务实原则。第一不要把“可能重启”和“确认重启”混在同一级别只有拥有了数据库内部证据的告警才值得走 Critical 路由只有启动时间戳变化的告警可以先走 Warning人工看一眼再决定是否升级。第二给每套 exporter 单独建一条“exporter 进程重启”的规则。这条规则的指标也是process_start_time_seconds但监控对象要明确指向 exporter 自身。这样数据库重启和采集器重启可以被一眼区分不需要每次误报的时候人工去翻日志。第三所有涉及重启判断的规则for子句至少设置 5 分钟也就是至少覆盖 15 到 20 个抓取周期。时有时无的抖动不值得触发告警持续翻转才值得关注。第四关于目标实例的标签体系要规范。同一个数据库的 node_exporter 和 mysqld_exporter 最好带上相同的 instance 标识这样 PromQL 里做多指标组合判断时才能正确对齐。我见过不少规则因为 instance 标签不一致而无法生效明明该被抑制的误报硬是漏了出来。还有一点容易被忽略数据库的自动恢复能力越来越强很多数据库在主进程异常退出后会被守护进程快速拉起业务无感但进程启动时间戳确实变了。这种时候监控报一声“重启”其实是合理的信息不该被当作误报完全抹掉。所以我的建议是把这类告警降级为一个需要次日确认的事件而不是直接 silence毕竟一次无人知晓的自动重启往往意味着系统层或者数据库层存在隐患值得花时间查明。我把上面这些规则在测试环境里模拟验证过人为调时间不会触发人为 kill exporter 不会触发真正重启 mysqld 会立刻报警能达到“谎报变少实报更准”的效果。再遇到“数据库没动Prometheus 却说起重启了”我建议你先看一眼节点时间、再看一眼 up 指标、最后看一眼数据库内部 uptime三个证据对不上就千万别急着去重启数据库先把问题定位到采集链路和时间基准上。这套排查顺序帮我避免了好几次对健康数据库的“暴力修复”算是这条路上最值得分享的一点经验。