案例現象

這天收到監控平臺發來告警，說有臺機器程式崩潰了

因為以前也有過相關的錯誤，根據經驗，用 dmesg命令看下核心資訊

發現有點不對勁，報錯資訊的時間跟告警時間不一致，正常來講報錯時間應該跟告警時間一致

使用 date 命令檢視一下當前系統時間

然後我們檢視一下系統日誌

由上面的輸出可以看到：

dmesg 顯示錯誤資訊的時間跟系統日誌 /var/log/messages 顯示錯誤資訊的時間不一致

定位問題

我們知道， 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 引數可以直接轉換為人類可讀時間（即年月日時分秒），但是不一定 準確 ，如果系統掛起或者恢復之後，日誌使用的時間源是不會更新的

也就是說， dmesg -T 輸出的核心資訊並不能保證時間的準確性

又因為 dmesg -T 中記錄的時間是 系統啟動時間到事件發生時間的時間差 ，這臺機器每天都會進行 NTP 時間同步 以及 每隔一段時間會進行重啟

所以就會出現核心日誌的時間與系統日誌時間不一致的現象

解決方案

關於 dmesg -T 時間戳不準確的情況，我查了好多資料都說沒有解決方法

所以在這裡我建議大家如果想要獲得準確的時間資訊，就去檢視系統日誌—— /var/log/messages

如果有小夥伴知道該如何解決的，可以告訴我

最後附上相關 issue 連結：

3. https://blog.tankywoo.com/2015/02/03/about-timestamp-in-dmesg.html