Linux内核日志级别与dmesg用法实战指南

在 Linux 内核的日常运维和调试中，日志管理是最基础也最关键的技能之一。内核日志不仅记录了系统运行的状态，更是排查硬件故障、驱动异常、内存问题的第一手资料。这里把几个核心机制和实用工具梳理清楚，希望能帮你在工作中少走弯路。

1. 内核日志级别（Log Level）

Linux 内核定义了 8 个日志级别，定义在 include/linux/kern_levels.h 中：

核心规律很简单：数字越小，优先级越高。像 KERN_EMERG（级别0）已经是系统即将崩溃的级别，而 KERN_DEBUG（级别7）只在调试时才会大量出现。

2. 控制台日志级别

那么问题来了：哪些消息会输出到控制台？内核把决定权交给了 /proc/sys/kernel/printk 这个文件。每次查看它，你会得到4个数字：

cat /proc/sys/kernel/printk
# 输出示例: 4    4    1    7
#           |    |    |    |
#           |    |    |    +-- default_console_loglevel（新打开控制台的默认级别）
#           |    |    +------- minimum_console_loglevel（控制台最小允许级别）
#           |    +------------ default_message_loglevel（printk 默认消息级别）
#           +----------------- console_loglevel（当前控制台日志级别阈值）

这里的关键是第一个值——console_loglevel。只有消息级别严格小于这个值的消息，才会被输出到控制台终端。举个例子，如果这个值是4，那么级别0到3（EMERG、ALERT、CRIT、ERR）的消息都会显示，而级别4的 WARNING 及以上的消息就不会在屏幕上刷出来。

3. dmesg -n 命令

dmesg（display message）是查看内核 ring buffer 的标准工具。它的 -n 选项可以在运行中动态修改刚才说的 console_loglevel，不需要重启系统，也不用改配置文件，非常实用。

3.1 语法

sudo dmesg -n 

设置控制台日志级别阈值。只有严格小于 level 的消息才会打印到控制台。

3.2 常用场景

# 只显示 KERN_EMERG (级别0) 的消息，几乎屏蔽所有输出
sudo dmesg -n 1
# 显示 ERR 及以上 (级别 0-2)
sudo dmesg -n 3
# 显示 WARNING 及以上 (级别 0-3)
sudo dmesg -n 4
# 显示所有消息（包括 DEBUG）
sudo dmesg -n 8
# 恢复系统默认（通常是 4 或 7）
sudo dmesg -n 7

这里需要注意：当你设置成 dmesg -n 1 时，控制台几乎清静了，但内核日志本身仍在正常记录到 ring buffer 中，只是不显示而已。

3.3 等效方法

# 方法1: 通过 /proc 接口
echo 1 | sudo tee /proc/sys/kernel/printk
# 方法2: 通过 sysctl
sudo sysctl -w kernel.printk="1 4 1 7"

4. 实际应用场景

场景1：内核死循环打印

先说个最让人头疼的场景——某个内核驱动（比如 amdgpu）因为 bug 开始疯狂刷屏，控制台完全被日志淹没。这时候怎么处理？

# 1. 立即止住控制台输出
sudo dmesg -n 1
# 2. 将日志重定向到文件分析
sudo dmesg > /tmp/kern_dump.log
# 3. 尝试恢复驱动状态
sudo modprobe -r amdgpu && sudo modprobe amdgpu
# 4. 如果模块卸载失败
sudo fuser -k /dev/kfd
sudo fuser -k /dev/dri/*
sudo modprobe -r amdgpu
# 5. 恢复日志级别
sudo dmesg -n 7

场景2：调试时开启详细日志

# 开启 amdgpu 驱动动态调试
echo 'module amdgpu +p' | sudo tee /sys/kernel/debug/dynamic_debug/control
# 同时确保控制台能看到 DEBUG 消息
sudo dmesg -n 8

场景3：只关注错误信息

# 只看 ERR 及以上级别
sudo dmesg -n 4
# 过滤 dmesg 中的错误
dmesg --level=err,crit,alert,emerg

dmesg 其他常用选项

# 持续监听内核消息（类似 tail -f）
sudo dmesg -w
# 带时间戳显示
dmesg -T
# 带级别标记显示
dmesg --decode
# 清空 ring buffer
sudo dmesg -C
# 只显示特定级别
dmesg --level=err
dmesg --level=warn,err
# 显示最后 N 行
dmesg | tail -50

5. Ring Buffer 机制与溢出处理

5.1 Ring Buffer 基本概念

内核日志存储在一个固定大小的环形缓冲区（ring buffer）中。说白了就是一个固定大小的“循环日记本”，写满之后新消息会自动覆盖最旧的消息。这是内核设计的正常行为，不用大惊小怪，也不需要手动干预。

5.2 查看 Ring Buffer 大小

# 查看当前 ring buffer 大小
dmesg | grep "log_buf_len"
# 或通过 sysfs（如果可用）
cat /sys/kernel/debug/tracing/buffer_size_kb

5.3 增大 Ring Buffer（防止日志丢失）

# 启动时通过 grub 参数设置（永久生效）
# 编辑 /etc/default/grub，在 GRUB_CMDLINE_LINUX 中添加：
log_buf_len=4M
# 然后更新 grub
sudo update-grub

5.4 日志持久化方案

Ring buffer 有一个致命缺点：重启后日志丢失，而且高速打印时很快会被覆盖。如果需要保留日志，有几种方案：

# 方法1: 通过 journald 持久化（systemd 系统）
# 确认配置: /etc/systemd/journald.conf
#   Storage=persistent
# 查看历史内核日志（包括之前的启动）
journalctl -k
journalctl -k -b -1    # 上一次启动的内核日志
# 方法2: 持续写入文件（实时捕获，不受 ring buffer 覆盖影响）
sudo cat /dev/kmsg > /tmp/kmsg_full.log &
# 方法3: 使用 dmesg -w 持续监听并保存
sudo dmesg -wT > /tmp/kern_continuous.log &

5.5 dmesg 与 /dev/kmsg 的区别

5.6 关键结论

• Ring buffer 溢出是正常行为，不需要也无法阻止
• 关键调试日志应通过 /dev/kmsg 或 dmesg -w 实时持久化捕获
• 不要依赖 ring buffer 保留完整历史，大量日志输出（如死循环打印）会快速覆盖有用信息

6. 注意事项

1. dmesg -n 只影响控制台输出，不影响内核 ring buffer 中的日志记录
2. 消息始终可通过 dmesg 命令或 /dev/kmsg 读取
3. systemd 系统中，journalctl -k 也可查看内核日志
4. 重启后日志级别恢复默认，如需持久化可修改 /etc/sysctl.conf：

   kernel.printk = 4 4 1 7

5. Ring buffer 满时自动覆盖旧消息，调试时应提前用 /dev/kmsg 或 dmesg -w 持久化捕获