prometheus因系统时钟不同步（clock skew）丢弃样本，需从时间源一致性、target时间戳、日志线索三方面排查：先比对双端utc时间偏差是否超3秒；再检查target是否注入错误时间戳；最后通过debug日志确认“dropping sample”及时间差。
系统时钟不同步（Clock Skew）会导致Prometheus在抓取指标时，因时间戳“超出可接受窗口”而主动丢弃样本。这不是网络或配置错误，而是时间基准失准引发的数据可信性危机。排查需从时间源一致性、抓取逻辑机制和日志线索三方面切入。
确认时间偏差是否真实存在且超出容忍范围
Prometheus默认允许最多5分钟的时间偏移（由--scrape.timeout和内部采样窗口隐式约束），但实际丢弃行为往往始于几秒级偏差。先做最基础的双端比对：
- 在Prometheus服务器上执行
date -R，记录完整带时区的RFC 2822格式时间（如Tue, 19 May 2026 13:50:22 +0800） - 在你访问UI的设备（浏览器所在机器）上，打开开发者工具控制台，运行
new Date().toUTCString()，获取其UTC时间 - 将两者统一换算为UTC后相减，得出真实偏差值。若超过3秒，已足够触发样本丢弃
检查target暴露的时间戳是否与Prometheus服务器时间冲突
Prometheus本身不校正target上报的时间戳，它只信任自己系统时钟。如果被监控服务（如Node Exporter、自定义应用）在响应/metrics时，手动注入了本地时间戳，而该服务所在主机时间也不同步，就会形成双重偏差：
- 用
curl http://target-ip:9100/metrics | grep '^# TYPE\|^your_metric_name' -A 2查看原始指标输出，确认是否有显式时间戳（形如http_requests_total{job="api"} 12345 @1747643422.123） - 若有，检查该target主机的
date输出，对比Prometheus服务器时间。若偏差显著，需在target端禁用手动打标，或统一启用NTP/chrony同步 - 多数标准exporter（如node_exporter）默认不带时间戳，此时问题大概率出在Prometheus自身时钟
分析Prometheus日志中的丢弃线索
时间相关丢弃不会直接写“clock skew”，但会留下明确的行为痕迹：
- 启用详细日志：
prometheus --log.level=debug，然后观察抓取日志中是否频繁出现dropping sample with timestamp outside of the allowed time range - 该提示后会附带两个关键时间：样本携带的时间戳（t_sample）和Prometheus当前系统时间（t_now），以及允许窗口（通常为t_now ± 5m）
- 若t_sample持续小于
t_now - 5m，说明target时间严重滞后；若持续大于t_now + 5m，说明target时间超前或Prometheus自身时间过慢
验证并加固整个链路的时间同步服务
不能只修Prometheus服务器，要确保所有参与方使用同一权威源：
- 在Prometheus服务器上运行
timedatectl status，确认System clock synchronized: yes且NTP service: active - 检查chrony或systemd-timesyncd的上游服务器是否稳定：
chronyc tracking（看Offset和Leap Status）、chronyc sources -v（看MS column是否为^*） - 若使用阿里云等国内环境，推荐配置
server ntp.aliyun.com iburst并重启chronyd；避免使用ntpdate这类单次命令，它无法维持长期稳定 - 对Kubernetes集群，还需检查kubelet所在节点、etcd集群节点、以及Prometheus Pod宿主机的时间同步状态，任一环节脱节都可能传导至抓取层
