你有没有遇到过这样的情况：排查一个故障，翻看 Nginx 日志和 MySQL 错误日志，发现两份日志里同一事件的时间差了 8 分钟？或者运维同事说“问题发生在凌晨 2:15”，你查本地系统日志却只看到 2:07 的记录？别急着怀疑日志丢了——大概率是系统时间没同步好。
日志时间不是“自动生成”的，它靠系统时钟
很多新手以为日志里的时间是日志程序自己“算出来”的，其实不然。绝大多数日志工具（比如 rsyslog、journalctl、logrotate、甚至 Python 的 logging 模块）都直接读取操作系统内核返回的当前时间戳（通常是 gettimeofday() 或 clock_gettime()）。也就是说，系统时间歪了，日志时间就跟着歪，而且歪得一模一样。
常见“时间歪了”的场景
• 虚拟机刚克隆完，没关机直接复制，系统时间还停在原虚拟机关机那一刻；
• 云服务器启动后没配置 NTP，跑了一周，漂移了 40 多秒；
• 宿主机时间不准，而 Docker 容器默认共享宿主机时钟；
• Windows 双系统下，Linux 启动时把硬件时钟当成本地时间用，而 Windows 当作 UTC 时间用，互相覆盖导致每次重启后时间乱跳。
怎么快速检查？
打开终端，运行这三行命令对比一下：
date # 系统当前时间
hwclock --show # 硬件时钟（CMOS）时间
timedatectl status # systemd 系统的时间状态（含是否启用 NTP）如果 date 和 hwclock --show 相差超过 1 秒，基本可以确定时间不同步了。
简单靠谱的同步方案
对于大多数 Linux 发行版（Ubuntu/CentOS/Debian），推荐直接启用 systemd-timesyncd：
sudo timedatectl set-ntp true
sudo systemctl restart systemd-timesyncd然后等十几秒，再运行 timedatectl status，看到 “System clock synchronized: yes” 就说明活了。这个服务轻量、默认开启、不占资源，比手动跑 ntpdate 更稳妥。
如果你用的是老系统（比如 CentOS 6）或需要更高精度，可以装 chrony：
sudo yum install chrony # CentOS/RHEL
sudo systemctl enable chronyd
sudo systemctl start chronyd别忘了日志服务本身
有些日志收集工具（如 Filebeat、Fluentd）支持在采集时覆盖时间字段。如果你的业务对时间精度要求极高，且无法完全信任系统时钟，可以在采集端加一层校准，比如强制从 NTP 服务拉一次时间再打日志。但日常使用中，先把系统时间管好，才是最省心、最根本的办法。
时间一准，日志才真正可信。下次再看到时间对不上的日志，先敲 date，别急着翻代码。