# 

监控面板上有一条曲线，偶尔会掉到零以下。换算成微秒是负的两百多万，也就是「这个请求花了负二点八秒」。

值班的同事第一反应是采集程序有 bug。查了两天，最后定位到一行减法：两次取时间相减，而这段时间里机器被对时了。

## 负值是怎么算出来的？

监控代码取了两个时间点，相减得到耗时。取时间的接口读的是实时时钟，也就是「墙上时间」。

这个时钟的定义里就写着可被设置。云上尤其如此：实例启动、迁移、长时间运行之后，系统会定期与时间服务器同步，偏差过大时做一次跳变调整。

如果跳变发生在两次取值之间，第二次的值可能小于第一次，减法结果就是负的。

| 情形 | 第一次取值 | 第二次取值 | 差值 |
| --- | --- | --- | --- |
| 正常 | 十点零三分 | 十点零三分零二秒 | 正两秒 |
| 时钟回拨三秒 | 十点零三分 | 十点零零分 | 负三秒 |
| 时钟前跳一小时 | 十点零三分 | 十一点零三分 | 正一小时 |

第三行更隐蔽：它不会报警，只会让耗时统计整体偏大，把平均值和分位数全部污染。

## 为什么这个时钟可以被改？

手册里对它的描述很直接：

> A settable system-wide clock that measures real (i.e., wall-clock) time. Setting this clock requires appropriate privileges. This clock is affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the clock), and by frequency adjustments performed by NTP and similar applications.

拆开看，影响它的有三类操作：管理员手动改时间、时间同步的步进调整、时间同步的频率调整。

前两类是跳变，会让某一次测量直接出错；第三类是频率调整，会让测量值整体偏移，误差随时长累积。

手册还有一句容易被忽略的：这个时钟统计自纪元以来的秒数，但**忽略闰秒**。所以跨闰秒的两次测量之间，也会出现一秒的错位。

## 应该用哪个时钟测耗时？

用单调时钟。手册对它的描述是：

> The CLOCK_MONOTONIC clock is not affected by discontinuous jumps in the system time (e.g., if the system administrator manually changes the clock), but is affected by frequency adjustments. This clock does not count time that the system is suspended. All CLOCK_MONOTONIC variants guarantee that the time returned by consecutive calls will not go backwards, but successive calls may—depending on the architecture—return identical (not-increased) time values.

三句话都重要：不受跳变影响；受频率调整影响；保证不回退，但不保证递增。

最后一条带来一个实际细节：连续两次调用可能返回完全相同的值，耗时算出来是零。如果代码里有「耗时必须大于零」的假设，就会踩坑。

四个时钟放一起对比：

| 时钟 | 受手动改时间影响 | 受频率调整影响 | 计不计挂起 | 会不会回退 |
| --- | --- | --- | --- | --- |
| 实时时钟 | 会 | 会 | 不计 | 会 |
| 单调时钟 | 不会 | 会 | 不计 | 不会 |
| 原始单调时钟 | 不会 | 不会 | 不计 | 不会 |
| 含挂起单调时钟 | 不会 | 会 | 计 | 不会 |

## 云上还有哪些时钟风险？

除了常规对时，云环境还有几个额外因素。

第一，实例迁移。宿主机维护或故障时，实例可能在几秒内换一台物理机，期间时钟由新宿主机提供，可能出现跳变。

第二，容器与宿主共享时钟。容器的时钟来自同一个内核，所以宿主对时，容器跟着跳。

第三，部分低配实例的时钟精度较低。用高频取时间做基准测试时，会看到明显的粒度。

第四，快照回滚。从较早的快照恢复的实例，时钟可能落后于当前真实时间，恢复后第一步就是对时，跳变量可能很大。

这些因素叠加，**在云上用实时时钟测耗时的风险比物理机房更高**。

## 怎么改才彻底？

改三处：测耗时用单调时钟；日志时间戳继续用实时时钟；两者分开取，不要互相推算。

```c
/* 只取差值：单调时钟不会回退 */
static long long now_us(clockid_t clk)
{
    struct timespec ts;
    if (clock_gettime(clk, &ts) != 0) return -1;
    return (long long)ts.tv_sec * 1000000LL + ts.tv_nsec / 1000;
}

long long t1 = now_us(CLOCK_MONOTONIC);
handle_request();
long long t2 = now_us(CLOCK_MONOTONIC);
long long cost = t2 - t1;
```

返回值要检查。如果取时间失败返回负一，相减会得到一个荒谬的数字，比负耗时更难解释。

## 超时控制该用哪个？

看语义。请求级超时用单调时钟就够，因为中间不会发生挂起。

但如果业务是「任务必须在三十分钟内完成，中途实例可能休眠或被挂起」，就得用含挂起时间的那个时钟，否则休眠期间超时不会触发。

用实时时钟做超时则会有一个尴尬情况：对时把时钟往后调一小时，所有超时瞬间全部触发；往前调一小时，超时被无限延长。

## 排查这类问题按什么顺序看？

第一，确认指标是否为负。负值是时钟回拨的强信号，正常业务不会产生。

第二，看同一时间窗内的系统日志，是否有对时、迁移、快照恢复的记录。

第三，确认采集端用的是哪个时钟。很多监控 SDK 默认用实时时钟，需要显式改成单调时钟。

| 现象 | 大概率原因 | 验证方式 |
| --- | --- | --- |
| 耗时出现负值 | 时钟回拨 | 看对时日志 |
| 耗时整体偏大且不回落 | 时钟前跳 | 对比两台机器的时间 |
| 耗时长期缓慢偏移 | 频率调整累积 | 与外部时间源比对 |
| 大批超时同时触发 | 时钟前跳触发绝对时间定时器 | 看定时器实现方式 |

## 改完之后还有什么要注意？

三件事。

一是历史数据。负值已经写进时序库，做趋势分析时要剔除，否则平均值和分位数会失真。

二是告警规则。基于耗时的告警要加下界校验，避免负值触发「耗时骤降」之类的误报。

三是埋点一致性。如果链路里有的服务用单调时钟、有的用实时时钟，跨服务的耗时对不上，需要用请求 ID 加时间戳来对齐。

这套时钟选型规则我整理成了一份监控接入说明，最早散在几次耗时异常的排查记录里，用 AI墨衍 把其中的判断依据归拢成按「测什么、用哪个时钟、为什么」三列排的表，几个项目之间共用。

## 小结

三句话：测耗时用单调时钟，打时间戳用实时时钟，两个都取不要互相推算。

云上对时、迁移、快照回滚都会带来跳变，这些在物理机房不常见。把时钟选对，比事后解释负值省事得多。


监控面板上有一条曲线，偶尔会掉到零以下。换算成微秒是负的两百多万，也就是「这个请求花了负二点八秒」。

云服务器对时之后，接口耗时统计出现了负值

云计算

操作系统

运维

监控耗时出现负值或数据异常，核心是代码误用实时时钟导致。实时时钟受手动改时间、NTP步进等跳变影响，产生负耗时或污染统计。应改用单调时钟测耗时，日志时间戳用实时时钟，两者分离。云环境需额外警惕迁移、快照回滚带来的时钟风险，告警需加下界校验。

代码解释

服务器

容器

4核4G3M云服务器 新用户低至38元/年！

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

云服务器对时之后，接口耗时统计出现了负值-腾讯云开发者社区-腾讯云

云服务器对时之后，接口耗时统计出现了负值

云服务器对时之后，接口耗时统计出现了负值

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐