API、数据库与日志中的时间戳

线上排查常要把 HTTP 链路、数据库行与多份日志对齐——各自时间表示法不同。

关联流程

1. 选定参考瞬间——用户反馈时间或 request ID 对应时间
2. 全部归一到 UTC epoch 毫秒（有纳秒则用纳秒）
3. 留时钟偏差余量——机器与容器会漂移；宽松系统 ±2 分钟常见
4. 先筛时间窗口——参考点 ± 5 分钟 再 deep grep
5. 记录来源单位（nginx: 秒、app: ISO UTC、db: timestamptz）

API

REST JSON 可能同时有：

{ "createdAt": 1700000000000, "updatedAt": "2023-11-14T22:13:20.000Z" }

服务演进会导致同一载荷混用类型。逐字段按定义解析。

GraphQL / protobuf 通常在 schema 里标明标量类型——客户端比较前先读文档。

数据库

• PostgreSQL TIMESTAMPTZ 内部存 UTC——良好默认
• BIGINT epoch 列——需永远记住 sec 还是 ms
• 无时区的 DATETIME（MySQL legacy）——存「写入时的墙钟」，全球业务风险高

日志与 SQL 关联时，先把两边转成同一瞬间再 join。

分布式日志

优先用带 trace ID 的链路。若只有墙钟字符串，用已知事件（发布标记、心跳）在各服务各抽一行，估算 skew。

要点

跨服务排查是 先归一、再比较、再扩窗口，不是猜本地钟点。先转换，再对比，最后再放大范围。