在Debian系统运维中，dmesg是排查内核问题的核心工具，而它的日志级别和环缓冲区大小直接决定了你能看到多少、看到什么。简单说，dmesg的日志级别由内核参数kernel.printk控制，默认是"4 4 1 7"（console_loglevel、default_message_loglevel、minimum_console_loglevel、default_console_loglevel），环缓冲区默认大小是16392字节（约16KB），在Debian 12 Bookworm上可以通过/proc/kmsg_bytes查看实际值。想要调整，要么用sysctl临时改，要么写进/etc/sysctl.conf永久生效，要么在启动时通过内核参数kernel.printk和kernel.ring_buffer_size直接指定。
dmesg日志级别到底是什么意思
很多运维人员只知道用dmesg看日志，但不清楚日志级别的四个数字分别代表什么。内核通过printk函数输出信息时，每条消息都带一个优先级数字，从0到7，数字越小优先级越高。0是紧急（emerg），1是告警（alert），2是严重错误（crit），3是一般错误（err），4是警告（warning），5是通知（notice），6是信息（info），7是调试（debug）。默认情况下，console_loglevel设为4，意味着只有优先级≤4的消息才会打印到控制台。如果你在排查一个硬件驱动问题，发现dmesg里什么都没有，很可能就是因为消息级别是5或6，被过滤掉了。
四个参数的具体含义与调整方法
kernel.printk这个sysctl参数接受四个值，格式是"a b c d"。a是console_loglevel，控制当前控制台显示的最高级别；b是default_message_loglevel，控制未指定级别的printk调用默认用什么级别；c是minimum_console_loglevel，控制台级别的下限，不能降低；d是default_console_loglevel，控制台的默认级别。举个例子，如果你想让所有级别的内核消息都显示出来，可以这样设置：
sysctl -w kernel.printk="7 7 1 7"
这条命令把console_loglevel和default_message_loglevel都设成7，意味着debug级别的消息也会出现在dmesg里。但要注意，设成7之后日志量会暴增，生产环境慎用。如果只是想临时调试，用完记得改回来：
sysctl -w kernel.printk="4 4 1 7"
永久修改的话，编辑/etc/sysctl.conf或/etc/sysctl.d/目录下的配置文件，加入一行：
kernel.printk = 7 7 1 7
然后执行sysctl -p生效。在Debian上，/etc/sysctl.d/目录是推荐的做法，比如创建/etc/sysctl.d/99-dmesg.conf，把配置写进去，方便管理。
环缓冲区大小的核心问题
dmesg的数据来自内核环形缓冲区（kernel ring buffer），它是一块固定大小的内存区域，新消息会覆盖旧消息。默认大小在不同内核版本里不一样，Debian 12默认是16392字节，Debian 11可能是262144字节（256KB），具体取决于内核编译时的CONFIG_LOG_BUF_SHIFT配置。你可以用下面的命令查看当前值：
cat /proc/kmsg_bytes
如果你发现系统启动时有大量硬件初始化信息，但dmesg只能看到最后一部分，那就是缓冲区太小，早期的消息被覆盖了。这时候需要增大缓冲区。
如何调整环缓冲区大小
调整缓冲区大小有两种方式。第一种是运行时通过/proc/sys/kernel/printk_ratelimit和/proc/sys/kernel/printk_delay间接影响，但真正控制缓冲区大小的是内核启动参数。第二种是在GRUB引导时添加参数。编辑/etc/default/grub，找到GRUB_CMDLINE_LINUX_DEFAULT这一行，添加log_buf_len参数，单位是字节。比如想设成1MB：
GRUB_CMDLINE_LINUX_DEFAULT="quiet log_buf_len=1048576"
然后更新GRUB配置：
update-grub
重启后用cat /proc/kmsg_bytes验证。注意，log_buf_len的值必须是2的幂次方，内核会自动对齐。常见的值有65536（64KB）、131072（128KB）、262144（256KB）、524288（512KB）、1048576（1MB）。设太大会浪费内存，设太小会丢日志，根据实际需求平衡。
dmesg与journalctl的配合使用
在Debian的systemd环境下，内核日志同时会被journalctl捕获。dmesg看到的是环形缓冲区里的内容，而journalctl -k看到的是持久化存储的内核日志。如果你把缓冲区设得很大，但没有配置持久化，重启后早期日志还是会丢。所以建议同时配置rsyslog或确保journald的持久化存储开启。检查journald是否持久化：
journalctl --disk-usage
如果显示有占用，说明日志在持久化。如果没有，编辑/etc/systemd/journald.conf，确保Storage=persistent，然后重启journald服务。
实际运维场景中的常见问题
场景一：服务器开机后出现内核panic，但重启后dmesg里找不到panic信息。这几乎肯定是缓冲区太小，panic发生在早期启动阶段，消息被后面的日志覆盖了。解决办法：增大log_buf_len到至少1MB，同时确保kdump或netconsole能把panic信息发出去。
场景二：USB设备插拔没有任何日志输出。先检查日志级别，用dmesg -l err,warn看看是否有过滤。然后用下面的命令实时监控：
dmesg -w
这个命令会实时显示新的内核消息，类似tail -f。如果还是没有，可能是驱动本身没有用printk输出，或者级别设成了debug但default_message_loglevel是4。
场景三：日志级别调成7之后系统变慢。这是因为大量debug信息涌向控制台和日志系统，消耗CPU和I/O。生产环境建议保持4或5，只在排查问题时临时调高。可以用printk_ratelimit和printk_delay来限流：
sysctl -w kernel.printk_ratelimit=5
sysctl -w kernel.printk_delay=3
这表示每5秒最多打印一条相同消息，每条消息之间延迟3秒，有效降低日志风暴。
内核参数kernel.printk的另一种写法
有些老文档会提到用echo直接写/proc/sys/kernel/printk，这其实和sysctl -w是等价的。但要注意，/proc/sys/kernel/printk这个文件在某些精简内核里可能不存在，用sysctl命令更通用。另外，如果你用的是Debian的实时内核（linux-image-rt），日志级别和缓冲区的调整方式完全一样，没有区别。
总结与最佳实践建议
在Debian运维中，dmesg日志级别和环缓冲区大小的调整是基本功。我的建议是：生产环境默认保持kernel.printk为"4 4 1 7"，log_buf_len设为262144（256KB）够用；排查问题时临时调高到7 7 1 7并配合dmesg -w实时观察；如果涉及启动阶段的故障排查，把log_buf_len拉到1MB以上，同时开启journald持久化。不要在生产环境长期开debug级别，性能损耗是实实在在的。把调整参数写进/etc/sysctl.d/和GRUB配置里，做到重启不丢失，这才是规范的运维做法。
最后提醒一点，Debian 13 Trixie即将发布，内核版本会升级到6.x系列，ring buffer的默认大小和管理方式可能有微调，但核心原理不变。养成查看/proc/kmsg_bytes和/proc/sys/kernel/printk的习惯，遇到问题先看这两个值，能省掉大量排查时间。
