dmesg 看的是什么
Linux 服务器出问题时，很多人第一反应是看应用日志、Nginx 日志或 systemctl 状态，这些当然重要，但它们通常只能说明“服务层”发生了什么。如果问题来自内核、驱动、磁盘、网卡、内存、文件系统，应用日志里往往只会留下一个结果：请求变慢、进程退出、磁盘只读、网络断开。真正的线索，常常藏在 dmesg 里。
dmesg 读取的是内核环形缓冲区中的消息。系统启动、硬件识别、驱动加载、磁盘 I/O、网卡链路、内存分配、文件系统错误、OOM 处理等事件，都可能在这里留下记录。它不像普通日志文件那样专门服务某个应用，而是更接近操作系统底层的“现场记录”。当你怀疑问题不是单个程序写错了，而是服务器底层环境正在异常，dmesg 就值得优先看一眼。
需要注意的是，dmesg 不是万能答案。它告诉你内核层面观察到的现象，但不一定直接告诉你业务为什么失败。排查时更合理的做法，是把 dmesg 与应用日志、系统日志、资源监控一起对照：先看时间点是否吻合，再看错误类型是否能解释业务现象，最后决定是继续查硬件、内核参数、文件系统，还是回到应用层。
先用这些命令打开现场
最基础的命令就是直接执行 dmesg。不过生产服务器运行时间稍长后，输出可能非常多，直接刷屏并不利于定位。更常用的方式是分页查看：dmesg | less，然后用斜杠搜索关键字，比如 error、fail、timeout、reset、oom、ext4、nvme、eth 等。
如果只想看最近的内核消息，可以使用 dmesg -T | tail -n 100。其中 -T 会把内核时间戳转换成人类可读的时间，方便和故障发生时间对齐。某些发行版上 -T 的时间换算可能受系统时间调整影响，因此遇到时间要求特别严谨的事故复盘，最好再对照 journalctl -k 或系统日志。
按严重程度过滤也很实用，例如 dmesg --level=err,warn 可以快速看到错误和警告。新版本 util-linux 还支持 dmesg -w 实时跟踪内核消息，适合一边复现故障一边观察底层输出。如果你正在插拔磁盘、调整网卡、重启服务或压测业务，实时观察比事后翻日志更容易抓到第一现场。
磁盘与文件系统异常
服务器突然写入失败、数据库报 I/O 错误、网站上传图片失败、系统提示文件系统只读时，dmesg 是必须检查的入口之一。常见关键词包括 I/O error、blk_update_request、Buffer I/O error、EXT4-fs error、remounting filesystem read-only、nvme timeout、reset controller 等。这些信息往往说明问题已经不是简单的“目录权限不对”。
例如看到文件系统被重新挂载为只读，通常意味着内核为了保护数据一致性，主动停止继续写入。这时继续重启应用意义不大，应该先确认磁盘健康、云盘状态、挂载参数和文件系统错误。可以配合 df -h、df -i、lsblk、mount、smartctl、云厂商磁盘监控一起判断。
如果是云服务器，dmesg 中的磁盘超时不一定代表物理硬盘坏了，也可能和云盘抖动、宿主机迁移、突发 I/O 打满、文件系统压力过大有关。排查时不要只盯着“磁盘空间还剩多少”，还要看 IOPS、吞吐、等待时间和业务写入模式。数据库、日志、缓存、上传目录放在同一块小盘上时，问题尤其容易互相放大。
OOM 与内存压力
服务器内存不够时，应用不一定会优雅地报错。Linux 可能触发 OOM Killer，直接杀掉某个进程。dmesg 里常见的线索包括 Out of memory、Killed process、oom-killer、invoked oom-killer 等。看到这些内容，就要把“应用自己崩了”和“系统把它杀了”区分开。
排查 OOM 时，不要只看当前 free -h。因为故障发生后，进程已经被杀掉，内存可能看起来又正常了。更关键的是看 dmesg 记录的时间点、被杀进程名称、当时的内存占用、是否有 swap、是否有容器或 cgroup 限制。对于 PHP、Java、Node.js、数据库这类服务，内存峰值比平均值更容易触发问题。
如果 OOM 频繁出现，处理方式通常不是简单加内存这么粗暴。要先判断是哪类进程增长异常：是访问量上来后 PHP-FPM 子进程太多，是 MySQL 缓冲设置过大，是日志分析脚本一次性吃掉内存，还是容器内存限制过紧。确认原因后，再决定调并发、调缓存、加 swap、优化 SQL，或者升级服务器配置。
网卡、驱动和网络抖动
网站偶发断连、SSH 卡顿、内网调用超时、接口请求偶尔失败时，很多人会先查带宽和防火墙，但 dmesg 也可能给出底层线索。常见关键词包括 link is down、link is up、NETDEV WATCHDOG、tx timeout、reset adapter、renamed from、virtio_net 等。
如果 dmesg 里频繁出现网卡 link up/down，说明连接状态确实在抖动。物理机上可能是网线、交换机端口、驱动或网卡问题；云服务器上可能与虚拟网卡、宿主机网络、热迁移或安全策略变化有关。此时单纯修改 Nginx 超时时间，只是在遮盖现象，不能解决根因。
网络问题排查要把几层信息分开：应用层看错误码和超时位置，系统层看连接数、队列和端口状态，内核层看网卡与协议栈是否报错，外部链路看丢包和路由。对于面向国内用户的网站，如果业务对链路稳定性要求较高，选择服务器时也要关注地域和线路质量；例如速维云的香港云服务器适合需要低延迟访问香港及周边地区的建站场景，而不是只看 CPU 和内存参数。
启动阶段的问题怎么判断
有些问题从系统启动阶段就埋下了。比如磁盘挂载失败、驱动没有加载、内核参数异常、文件系统修复、设备名变化等。执行 dmesg | less 后从前往后看，可以看到内核启动、设备识别和服务依赖的早期信息。对于“重启后服务起不来”“换盘后挂载丢了”“升级内核后网卡异常”这类问题，启动阶段日志尤其重要。
启动阶段常见的坑是设备名变化。以前写在 /etc/fstab 里的 /dev/vdb1，在某些环境下重启后可能变成别的设备名，导致挂载失败。更稳妥的方式是使用 UUID 或 LABEL。dmesg 可以帮助你确认系统识别到了哪些块设备、分区和文件系统，再配合 blkid、lsblk -f 检查挂载配置。
如果升级内核后出现驱动异常，也可以对比升级前后的 dmesg 记录。比如某些网卡驱动、存储控制器、文件系统模块在新内核下表现不同，应用层看到的只是“网站打不开”或“数据库慢”，但根因可能是底层驱动行为变化。生产环境升级内核前，最好先有快照、回滚方案和维护窗口。
别把每条警告都当事故
dmesg 里出现 warn、fail、error 字样，并不代表一定发生了严重故障。很多消息只是驱动探测失败、某个可选功能不可用、设备初始化时的普通提示。排查时要避免两个极端：一种是看到红字就恐慌，另一种是因为业务暂时还能跑就完全忽略。
判断一条 dmesg 是否重要，可以看三个维度。第一，它出现的时间是否与故障时间吻合；第二，它涉及的组件是否与业务现象有关；第三，它是否持续重复出现。比如偶发一次的 USB 设备提示，对云服务器网站故障通常没有意义；但同一时间段不断出现磁盘 I/O timeout，就不能轻轻放过。
还要注意日志会被覆盖。内核环形缓冲区容量有限，服务器运行时间越长、消息越多，早期记录越可能被挤掉。重要故障发生后，应该及时保存现场：dmesg -T > /root/dmesg-$(date +%F-%H%M).log，同时导出相关应用日志和监控截图，方便后续复盘。
一个实用排查顺序
遇到疑似系统底层问题时，可以按一个相对固定的顺序来做。第一步，记录故障时间和现象：是访问慢、写入失败、进程退出、网络断开，还是系统重启。第二步，用 dmesg -T | tail -n 200 查看最近内核消息，再用关键词搜索错误。第三步，对照 journalctl -k、journalctl -u 服务名、Nginx/PHP/MySQL 等应用日志。
第四步，根据错误类型展开。如果是 OOM，就查内存峰值和进程；如果是 I/O error，就查磁盘、文件系统和云盘监控；如果是 link down 或网卡 reset，就查网络链路和虚拟网卡；如果是启动阶段异常，就查挂载、驱动和内核版本。第五步，先止血再根治：必要时扩容、迁移、降载、重启服务，但事后一定要回到日志里确认根因。
对于没有专职运维的小团队，dmesg 的价值在于把排查从“凭感觉重启”拉回“按证据定位”。它不需要复杂平台，也不需要额外安装，只要你能 SSH 登录服务器，就能看到很多底层线索。真正提高效率的不是记住所有报错，而是知道什么时候该看它、看见以后该和哪些信息放在一起判断。
