dmesg 时间误差现象

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: dmesg 时间误差现象

1.案例现象

这天收到监控平台发来的告警,说有台机器程序崩溃了

因为以前也有过相关的错误,根据经验,用 dmesg命令看下内核信息
image.png
发现有点不对劲,报错信息的时间跟告警时间不一致,正常来讲报错时间应该跟告警时间一致

使用 date 命令查看一下当前系统时间
image.png
然后我们查看一下系统日志

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 时间戳不精确的情况,我查了好多资料都说没有解决方法
image-20230330151155041.png
image-20230330151226584.png
所以在这里我建议大家如果想要获得准确的时间信息,就去查看系统日志——/var/log/messages

最后附上相关 issue 链接:

  1. https://serverfault.com/questions/576139/dmesg-time-vs-system-time-time-isnt-correct
  2. https://bugzilla.redhat.com/show_bug.cgi?id=895909
  3. https://blog.tankywoo.com/2015/02/03/about-timestamp-in-dmesg.html
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
3月前
|
存储 运维 监控
机器的coredump文件过多处理
【10月更文挑战第1天】
163 4
|
4月前
|
Linux
crash命令 —— runq
crash命令 —— runq
|
4月前
crash命令 —— sym
crash命令 —— sym
|
4月前
crash命令 —— p
crash命令 —— p
|
5月前
|
运维 监控 Linux
Linux系统读写硬盘慢,如何排查?四步教你定位问题!
【8月更文挑战第24天】在Linux系统运维中,硬盘读写速度慢是一个常见且影响重大的问题。它不仅会导致服务器性能下降,还会影响用户体验。本文将详细介绍四个步骤,帮助你快速定位并解决Linux系统硬盘读写慢的问题。
1059 0
进程crash报错1000
进程crash,在应用程序日志里看到有1000 的报错
进程crash报错1000
|
安全 应用服务中间件 Linux
系统启动提示oom的处理过程
entos 系统主机启动后提示oom,重启后第一时间也是oom
系统启动提示oom的处理过程