dmesg:Linux系统的＂黑匣子＂,运维必懂的诊断神器
- 2026-03-07 04:20:43
你有没有遇到过这样的情况：
服务器突然重启，不知道原因 插入U盘，系统没有反应 网卡时不时断线，找不到原因 磁盘读写变慢，怀疑硬件有问题
遇到这些问题，很多人第一反应是重启、换硬件、找售后……
但其实，Linux系统早就把所有答案藏在了一个地方——dmesg。
今天这篇文章，带你彻底搞懂这个运维必备的诊断神器。
dmesg 是什么？
dmesg，全称 diagnostic messages，直译为"诊断消息"。
它是Linux内核的**"飞行记录仪"，从系统开机的第一秒起，内核发生的所有事件——硬件检测、驱动加载、设备插拔、错误报告——全部会被记录在一个叫做环形缓冲区（Ring Buffer）**的内存区域中。
dmesg 命令，就是读取这个缓冲区内容的工具。
📌 一句话理解：dmesg 是 Linux 系统的"黑匣子"，记录了系统从启动到现在所有的底层事件日志。
Ring Buffer 是什么？
环形缓冲区是一段固定大小的内存空间（默认约16KB），采用"先进先出"的循环写入方式：
┌─────────────────────────────────────┐│ 新消息 → [msg5][msg4][msg3][msg2] │ ← 旧消息被覆盖└─────────────────────────────────────┘ 环形缓冲区（固定大小）当缓冲区写满后，新消息会自动覆盖最旧的消息。因此，对于运行时间很长的系统，早期的启动日志可能已经被覆盖。
dmesg 能告诉我们什么？
一份完整的 dmesg 输出，包含了系统从上电开机到当前时刻的完整底层事件流，主要涵盖以下几类信息：
基础用法
最基本的使用
dmesg直接输出所有内核消息，通常有几千行，建议配合管道工具使用。
实用组合命令
# 分页查看（推荐新手）dmesg | less# 人类可读的时间格式（强烈推荐）dmesg -T# 带颜色高亮显示dmesg -L# 人性化综合显示（时间+颜色+对齐）dmesg -H# 只看最后20行（查看最新事件）dmesg | tail -20# 实时监控（类似 tail -f，监控设备插拔神器）dmesg -w# 查看错误和警告dmesg --level=err,warn消息格式解读
每条 dmesg 消息的格式非常固定：
[ 1.234567] usb 1-1: new high-speed USB device number 2└────────────┘ └──────────────────────────────────────────┘ 启动后秒数 消息内容时间戳代表系统启动后经过的秒数，使用 -T 参数可以转换为人类可读的绝对时间：
[Mon Mar 2 10:23:45 2026] usb 1-1: new high-speed USB device日志级别：学会看"轻重缓急"
Linux内核消息分为 8个严重等级，从0（最严重）到7（最详细）：
# 日常运维建议：只看 err 和 warndmesg --level=err,warn# 导出错误日志备查dmesg --level=err,warn -T > /tmp/kernel_errors.log核心场景实战
🔌 场景一：诊断USB设备问题
USB设备无法识别？先看 dmesg：
# 实时监控USB事件dmesg -w | grep -i usb正常识别的日志：
[+0.000000] usb 1-1: new high-speed USB device number 3 using xhci_hcd[+0.105813] usb 1-1: New USB device found, idVendor=0781, idProduct=5581[+0.105817] usb 1-1: Product: Ultra[+0.105819] usb 1-1: Manufacturer: SanDisk[+0.234521] sd 6:0:0:0: [sdb] 60062500 512-byte logical blocks: (30.8 GB)[+0.234678] sd 6:0:0:0: [sdb] Attached SCSI disk异常日志（设备供电不足）：
usb 1-1: device descriptor read/64, error -71usb 1-1: unable to enumerate USB device异常日志（驱动加载失败）：
usb 1-1: can't set config #1, error -110💡 处理建议：
error -71通常是供电问题，换有源USB Hub；error -110通常是驱动问题，检查内核模块是否加载。
💾 场景二：磁盘健康诊断
磁盘读写变慢或报错，dmesg 会第一时间记录：
# 查看磁盘相关日志dmesg | grep -iE "sda|sdb|nvme|ata"# 专门查找I/O错误（磁盘故障最关键的信号）dmesg | grep -i "I/O error"正常磁盘识别日志：
[2.198432] ata1.00: ATA-11: Samsung SSD 870 EVO 1TB[2.212543] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks (1.00 TB)[2.345123] sda: sda1 sda2 sda3[2.345678] sd 0:0:0:0: [sda] Attached SCSI disk⚠️ 磁盘故障警告信号：
# 磁盘I/O错误（出现这个要高度重视！）end_request: I/O error, dev sda, sector 1234567Buffer I/O error on device sda1, logical block 1234# 磁盘链路重置（硬件连接问题）ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6ata1.00: hard resetting link# 磁盘超时（可能是磁盘快要挂了）ata1.00: qc timeout (cmd 0x60)🚨 重要提醒：发现
I/O error日志，请立即备份数据，并用smartctl -a /dev/sda进一步检查磁盘健康状态！
🌐 场景三：网络问题排查
网卡掉线、网络不稳定，先看 dmesg：
# 查看网卡相关日志dmesg | grep -iE "eth|eno|wlan|network"# 查看网卡链路状态变化dmesg | grep -i "link"正常网卡日志：
[3.234521] e1000e: Intel(R) PRO/1000 Network Driver[3.312543] e1000e 0000:00:19.0 eno1: NIC Link is Up 1000 Mbps Full Duplex网卡掉线日志：
e1000e 0000:00:19.0 eno1: NIC Link is Downe1000e 0000:00:19.0 eno1: NIC Link is Up 100 Mbps ← 重新连上但降速固件缺失（无线网卡常见问题）：
iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-7265D-29.ucode failediwlwifi 0000:03:00.0: request for firmware file failed💡 处理建议：固件缺失执行
apt install firmware-iwlwifi或对应固件包。
💥 场景四：OOM（内存耗尽）排查
服务器进程神秘消失？很可能是被内核OOM Killer干掉了：
# 查找OOM事件dmesg | grep -i "oom\|out of memory\|killed process"典型OOM日志：
[12345.678901] Out of memory: Kill process 12345 (java) score 900 or sacrifice child[12345.678902] Killed process 12345 (java) total-vm:8192000kB, anon-rss:7654321kB[12345.678903] oom_reaper: reaped process 12345 (java), now anon-rss:0kB日志解读：
Kill process 12345 (java) | |
score 900 | |
total-vm: 8192000kB | |
anon-rss: 7654321kB |
💡 处理建议：增加内存、优化应用内存使用、设置合理的JVM堆大小，或调整
/proc/sys/vm/swappiness。
🖥️ 场景五：CPU硬件错误
服务器出现随机崩溃，可能是CPU硬件错误（MCE）：
# 查看CPU机器检查错误dmesg | grep -iE "mce|machine check|hardware error"MCE错误日志：
[1234.567890] mce: [Hardware Error]: Machine check events logged[1234.567891] mce: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 4: ...[1234.567892] mce: [Hardware Error]: TSC 0 ADDR fe00000000 MISC 144 PROCESSOR 0:206a7🚨 这类错误非常严重，通常意味着CPU、内存或主板硬件故障，需要立即联系硬件维保！
🔋 场景六：系统温度与电源
# 查看温度相关日志dmesg | grep -iE "thermal|temperature|overheat"# 查看电源相关dmesg | grep -i acpi温度告警日志：
thermal thermal_zone0: critical temperature reached (110 C), shutting down🚨 出现温度临界告警，系统会自动关机保护硬件，需检查散热系统。
进阶技巧
技巧一：按时间段筛选日志
# 只看启动前5秒的日志（硬件初始化阶段）dmesg | awk -F'[\[\]]''$2 < 5 {print}'# 只看启动10秒之后的日志（运行时事件）dmesg | awk -F'[\[\]]''$2 > 10 {print}'技巧二：生成诊断报告
# 导出完整错误报告dmesg -T --level=err,warn > /tmp/system_diagnosis_$(date +%Y%m%d).log# 查看报告cat /tmp/system_diagnosis_$(date +%Y%m%d).log
