1.案例现象
这天收到监控平台发来的告警,说有台机器程序崩溃了
因为以前也有过相关的错误,根据经验,用 dmesg
命令看下内核信息
发现有点不对劲,报错信息的时间跟告警时间不一致,正常来讲报错时间应该跟告警时间一致
使用 date
命令查看一下当前系统时间
然后我们查看一下系统日志
grep error /var/log/messages
Mar 28 09:12:01 kernel: error info
Mar 30 10:36:00 kernel: error info
由上面的输出可以看到:dmesg 显示错误信息的时间跟系统日志 /var/log/messages
显示错误信息的时间不一致
2.定位问题
我们知道, dmesg
和 /var/log/messages
都是用来记录服务器启动、运行期间的日志的
当机器出现问题时,运维人员可以从这两个日志输出中进行初步排查
我们来看下 dmesg
输出和 /var/log/messages
的区别:
dmesg
显示内核和内核模块的相关信息,/var/log/messages
不但显示内核信息,还显示系统活动信息- 可以说
dmesg
输出的信息是/var/log/messages
的子集,dmesg
输出的信息在 ring buffer 中维护,大小有限制 /var/log/messages
包含所有系统消息以及dmesg
中的信息
那为什么这台机器上 dmesg
显示错误信息的时间跟系统日志 /var/log/messages
显示错误信息的时间不一致呢?
由上面得知,我在查看 dmesg 信息的时候使用了 -T 参数,我们来看一下这个参数的含义
-T, --ctime
Print human-readable timestamps.
Be aware that the timestamp could be inaccurate! The time
source used for the logs is not updated after system
SUSPEND/RESUME. Timestamps are adjusted according to current
delta between boottime and monotonic clocks, this works only
for messages printed after last resume
这个 -T 参数可以直接转换为人类可读时间(即年月日小时分钟秒),但是不一定精确,如果系统挂起或者恢复之后,日志使用的时间源是不会更新的
也就是说,dmesg -T
输出的内核信息并不能保证时间的准确性
又因为 dmesg -T
中记录的时间是系统启动时间到事件发生时间的时间差,这台机器每天都会进行 NTP 时间同步以及每隔一段时间会进行重启
所以就会出现内核日志的时间与系统日志时间不一致的现象
3.解决问题
关于dmesg -T
时间戳不精确的情况,我查了好多资料都说没有解决方法
所以在这里我建议大家如果想要获得准确的时间信息,就去查看系统日志——/var/log/messages
最后附上相关 issue 链接: