Linux dmesg命令查看内核日志方法

直接键入 dmesg 查看内核日志，可能是许多工程师面对系统异常时的第一反应。但结果往往不尽人意：屏幕上快速滚过数万行历史启动信息，真正的错误早已淹没在信息海洋中，难以定位。

实际上，内核日志是一座金矿，只需掌握正确的"挖掘"方法。关键在于利用 dmesg 自身的过滤与格式化能力，结合具体场景进行解读。

只看 error/warning 级别，别再 grep 关键词了

内核为每条日志都标记了清晰的级别标签，例如 err、warn、info。这些内部标记比在字符串中搜索 "error" 或 "fail" 可靠得多。

• 最直接的方法：dmesg -l err,warn。该命令直接筛选出错误和警告级别的信息，绝大多数硬件异常、驱动加载失败或 I/O 超时问题最终都会落在此范围内。
• 想更醒目？添加 -L 参数开启彩色输出：dmesg -L -l err,warn。鲜红色高亮的关键错误行，扫一眼即可定位。
• 必须警惕 dmesg | grep -i error 这种写法。许多日志本身只是信息记录，但内容恰巧包含"error"一词，这样 grep 反而引入大量无用信息，干扰判断。

时间戳必须用 -T，别管那串开机秒数了

dmesg 默认显示的时间戳是系统启动以来的秒数（如 [1.234567]）。该数字每次重启都会归零，一旦系统休眠过，便无法与现实时间对齐，排查历史问题时基本失效。

• 正确做法是使用 dmesg -T。它会将时间戳转换为易读的本地时间格式，例如：[Wed Jun 11 13:22:45 2026]。
• 组合使用是常规操作：dmesg -T -l err,warn 既能显示关键信息，又能知道具体发生时间。
• 注意例外：部分非常老旧的 Linux 内核可能不支持 -T 参数。若命令无效，可改用 journalctl -k --since "1 minute ago" 查看指定时间段内的内核日志。

实时监控关键硬件事件，-w 才是唯一选择

像 USB 设备热插拔、NVMe 固态硬盘链路中断、网卡意外重置这类瞬态事件，等去翻阅历史日志时，早已被新消息顶出缓冲区。

• 此时需要 dmesg -w。这是内核原生支持的实时监控模式，持续监听并输出新产生的日志，当环形缓冲区翻转时能确保不丢失任何消息。
• 注意，部分文档可能提到 dmesg -f 或 dmesg --follow，但它们已被官方标记为可能弃用或不稳定，在某些内核版本下甚至会卡住，因此不推荐。
• 实战中可配合 grep 进行过滤：dmesg -w | grep -i "usb\|nvme\|ata"。当插入硬盘或试图复现问题时，终端立刻给出响应。
• 若执行 dmesg -w 后无任何输出，先别慌。这可能是因为内核编译时未启用 CONFIG_PRINTK 或启用了限制（常见于某些容器或精简内核），此时改用 journalctl -k -f 即可。

清空日志是危险动作，务必先导出备份

内核日志缓冲区大小有限（通常 128KB 到 256KB），遵循环形队列规则，旧消息会被新日志覆盖。但在排查问题时，贸然清空缓冲区，很可能将刚刚发现的关键线索冲掉。

• 最稳妥的习惯：清空前先用 dmesg > /tmp/dmesg-before.log 将当前日志完整导出备份。
• 若需边导出边清空，使用 dmesg -c。该命令先读取并输出当前全部内容，再清空缓冲区，相当于"一键备份并清空"。
• 绝对不要 使用 dmesg -C。它只做一件事：清空缓冲区，且不输出任何内容。一旦执行，除非有其他地方的日志备份（如 journalctl -k 或 /var/log/kern.log），否则丢失的日志线索几乎无法找回。

话说回来，掌握这些命令参数只是第一步。真正的难点在于判断：哪条日志是需要立即处理的致命错误，哪条只是无关紧要的噪音？例如：

• 短时间内连续出现三次 buffer I/O error 或 UNC error 这类日志，往往意味着硬盘很可能已开始出现坏块，数据存在丢失风险。
• 而像 ACPI: EC: GPE storm detected 这样的警告，很多时候只是主板固件（BIOS/UEFI）存在微小缺陷，系统已自动处理，通常无需人工干预。

这类判断，源于对系统整体表现（如卡顿、服务中断、设备失联）与日志信息的反复对照，是经验积累的结果，远非堆砌命令参数就能解决。