dmesg 这个命令，我敢说一半的人都只用了三成功力

说真的，每次有兄弟问我"内核日志咋看"，我心里都会先嘀咕一句——你确定你真的会用 dmesg 吗？不是说这命令有多难，而是这玩意儿功能远比大多数人知道的要多。前阵子帮一个朋友排查一台服务器反复重启的故障，折腾了大半天没搞定，最后一句 dmesg -T -l err 直接把根因给扒出来了。当时他看我的表情，跟看怪物似的。所以今天就打算把这些年用 dmesg 攒下的经验，一股脑儿全倒出来。

最基础的用法，其实藏着不少坑

打开终端，输入 dmesg，回车，哗啦一下全是日志。很多人看到这一堆东西头皮就发麻，直接 Ctrl+C 完事儿。但我跟你讲，耐心往下翻翻，能看出不少门道。

默认输出的时间戳是相对于系统启动的秒数，什么 [ 1234.567890] xxx 这种格式。这种时间你让人怎么读？上次一个实习生拿着这个时间戳来找我，说"这个进程怎么跑了快两千万秒了，是不是要挂了"，我一看启动时间，好家伙，机器才刚开三天。dmesg -T 这一步操作，就能把这个时间转成人类能看懂的时间格式，比如 Wed May 15 14:23:01 2024。这玩意儿在排查"某个时间点到底发生了啥"的时候，简直是救命的存在。

权限这块也得提一嘴。CentOS 系列、Ubuntu 这些发行版，默认普通用户能直接跑 dmesg。但如果你用的是 Debian 11 之后的版本，或者一些做了安全加固的镜像，会发现直接敲 dmesg 给你来一句 dmesg: read kernel buffer failed: Operation not permitted。这时候 sudo dmesg 是最简单的解决办法，不过我更建议你去看看 /dev/kmsg 的权限设置，或者把用户加到相应的组里，省得每次都要 sudo。

实时监控，救过我好几次命

dmesg -w 这个组合，我经常用来干一件事——插拔硬件的时候实时看内核反馈。

举个真实场景。之前给一台 Dell 的 R750 做扩容，要新插一块 NVMe 盘。服务器在机柜最顶上，笔记本搬上搬下也不方便，我就直接在带外管理口 SSH 进去，提前敲好 dmesg -w，然后让机房那边的兄弟把盘插上。日志里立马蹦出来 nvme nvme0: pci function 0000:86:00.0，后面跟着一堆初始化信息，最后看到 nvme0n1: p1 p2 说明分区都识别出来了，整个过程一气呵成，没用 iDRAC 也没用 IPMI，纯靠 dmesg 就把硬件层面的状态摸得一清二楚。

还有个场景是排查 USB 设备。U盾、加密狗、4G 模块这些玩意儿经常抽风，以前不知道 -w 的时候，我都是插上设备然后反复 dmesg 去看日志，时间窗口掐不准还容易漏。现在直接 dmesg -w 挂着，设备一插，所有插拔事件全都实时打出来，比日志文件还及时。

grep 过滤，入门级的进阶操作

dmesg | grep xxx 这种用法，应该是每个人都会的。但我想说的是，过滤的关键不在于 grep 本身，而在于你知道要过滤什么关键词。

我一般排查问题的时候，脑子里会有几个固定的关键词清单：

• error、fail、failed——通用的错误信息
• usb、ata、nvme——存储和总线相关
• eth、link、nic——网卡相关
• oom——内存溢出，这个一定要看
• segfault——段错误，应用层挂的时候内核会记录
• hardware——硬件错误

之前一台机器上的应用莫名其妙挂掉，应用日志啥也没写。上了 dmesg | grep -i -E "error|kill|oom" 一看，好家伙，内核里全是 Out of memory: Killed process xxx。原来是被 OOM Killer 干掉了，应用自己都不知道自己怎么没的。后面调了 cgroup 内存限制，加了监控告警，再没出过类似问题。

还有个技巧，grep 的时候记得加上 -i 忽略大小写，加上 --color=auto 高亮关键词。终端里花花绿绿的，一眼就能定位。dmesg | grep -i --color=auto usb，排查起来效率能高不少。

日志级别过滤，被严重低估的利器

这个功能我真的要强烈安利一下。dmesg -l err 这个命令，只会显示错误级别的内核日志。

很多人不知道 dmesg 的日志其实是分了级别的：emerg、alert、crit、err、warn、notice、info、debug。日常排查的时候，info 和 debug 级别的日志能把屏幕塞满，关键的 err 反而被淹没在噪音里。这时候 -l 选项的价值就出来了。

我常用的几个组合：

• dmesg -l err,crit,alert,emerg——只看错误和更严重的
• dmesg -l warn,err——看警告和错误
• dmesg -l info——只看信息级别的

之前有个故障，机器间歇性丢包，业务方反馈说网络有问题。我上去先 dmesg -l err,crit -T 看了一眼，立马就发现是网卡驱动在报错，ixgbe 0000:04:00.0: Error ICR 0x08000000。换了个驱动版本，问题解决。如果当时用 dmesg 啥也不过滤地看，估计得翻半天才能找到这条关键信息。

dmesg 不是万能的，这些坑你得知道

前面说的都是 dmesg 的好，但有些场景下 dmesg 真的无能为力。

第一个，缓冲区会满。内核日志是存在 ring buffer 里的，默认大小有限。如果系统日志输出特别频繁，旧的日志会被覆盖掉。所以排查那种"昨天发生的问题"的时候，dmesg 可能已经查不到了。这时候就得靠 journalctl -k 或者 /var/log/kern.log（有些发行版）来补救了。journalctl -k --since "1 hour ago" 这种用法我经常用来回溯最近一段时间的内核日志。

第二个，重启会丢。这个前面也提到了，dmesg 读的是内存里的 buffer，重启就没了。生产环境上，我会建议把内核日志持久化到日志服务器，或者直接推送到 ELK、Loki 这种日志系统里。临时用的话，systemd 的 journald 默认就会持久化内核日志，journalctl -k 配合 -p err 过滤级别，用起来比 dmesg 还顺手。

第三个，并发量大的时候输出会乱。dmesg 默认是单次输出，如果你在排查某个正在持续报错的问题，输出会刷得很快，根本看不清。这种情况下 dmesg -w 配合 less 也不太行（-w 模式下 less 不会用），我一般是用 dmesg -w | tee /tmp/dmesg.log，一边实时看一边存到文件里，回头慢慢分析。

我自己常用的排查套路

说几个我压箱底的套路，遇到了直接套用。

场景一：服务器启动不起来或者启动慢。 直接进单用户模式或者 rescue 模式，跑 dmesg | grep -i -E "fail|error|timeout|wait"，重点看驱动加载和磁盘挂载那部分。如果是云服务器的话，可以通过 VNC 或者串口控制台看启动日志，那个其实就是 dmesg 的输出。

场景二：应用性能突然下降。 dmesg -T -l err,crit,alert,emerg 先扫一遍有没有硬件层面的报错，重点关注 CPU 相关的 mce（Machine Check Exception）、内存相关的 edac、磁盘相关的 ata 错误。然后 dmesg | grep -i oom 看看有没有被 OOM Killer 干掉。这些是应用层监控经常漏掉的地方。

场景三：新硬件不识别。 dmesg -w 挂着，然后插硬件。日志里会告诉你内核有没有认到这个设备，驱动加载是否成功。如果压根没动静，那大概率是硬件问题或者没插紧。如果有错误信息但设备没起来，那就是驱动或者固件版本不匹配。这种时候 dmesg | grep -i firmware 能看到固件加载失败的信息，挺有用的。

场景四：网络抖动。 dmesg | grep -i -E "eth|link|nic|rx|tx"，重点看有没有 link is down、rx errors、tx errors 这类信息。云环境里虚机的话，多看看 virtio_net、vhost 相关的日志，宿主机层面的网络问题有时候会透到内核日志里。

写在最后

dmesg 这命令，说简单也简单，说复杂也复杂。简单在于输入就能看，复杂在于真正用好需要你对内核、对硬件、对系统调用都得有点了解。我自己的感受是，越往后用越觉得这个命令强大，很多别人用一堆工具才能排查出来的问题，一句 dmesg 就能搞定。

但也别迷信 dmesg。它只是排查链路的起点，不是终点。真正要解决问题，还得结合业务日志、监控指标、链路追踪这些一起看。

行了，今天就啰嗦到这儿。这些经验全是我平时干活儿踩坑踩出来的，你要是觉得有用，转发给身边还在用 dmesg | more 一行行翻的兄弟，让他们也少掉几根头发。下次遇到有意思的案例，再来给你们拆解。

如果觉得内容对你有帮助，记得关注公众号，后续会持续更新各类运维排障的实战经验，咱们一起少踩坑、多睡觉。