Linux dmesg 缺日志怎么办：内核日志级别、journald 转发与现场保留

值班时最容易误判的一种现象，是执行 dmesg 只看到几行，甚至直接得到 dmesg: read kernel buffer failed: Operation not permitted。这通常不等于内核没有记录日志：可能是当前用户没有读取权限，也可能是日志已经被 journald 接管、环形缓冲区发生过覆盖，或者消息级别把低优先级内容过滤掉了。

先确认“能不能读”和“读到的范围”，再判断“内核有没有产生日志”。

先把 dmesg 的三种缺失现象分开

不要一上来就改 sysctl 或重启日志服务。先用当前权限做一组低风险检查：

id
dmesg --level=err,warn
journalctl -k -b --no-pager -n 80

如果第一条 dmesg 返回权限错误，而 journalctl -k 能看到同一启动周期的内核消息，问题在读取边界；如果两边都有输出但缺少某类信息，继续看级别过滤；如果只保留最近几条且启动时间很久，才需要怀疑环形缓冲区覆盖。

权限边界：Operation not permitted 不代表没有日志

Linux 可以通过 kernel.dmesg_restrict 限制普通用户读取内核环形缓冲区。先记录值，再决定是否用具备权限的值班账号复核：

sysctl kernel.dmesg_restrict
sudo dmesg --level=err,warn --time-format=iso

这里的验收点很具体：如果带权限的命令能返回带时间的 err 或 warn 行，而普通用户失败，说明日志存在，缺的是读取资格。不要为了临时查看就把限制永久改成宽松值；生产机更适合使用受控的 sudo 规则，或者直接从 journald 取内核日志。

日志级别：先看严重事件，再决定是否导出全部

dmesg --level=err,warn 只保留错误和警告，排查磁盘、网卡或驱动异常时很省时间，但它会主动排除 info、notice 等级。可以用级别过滤定位，再用完整导出保存现场：

dmesg --level=err,warn --time-format=iso
dmesg --time-format=iso --color=never > /var/tmp/dmesg.log

如果故障线索来自“设备刚刚出现”或“驱动初始化顺序”，不要只看第一条命令。把导出文件的生成时间、主机名和内核版本一起记录，之后才能把日志行和部署时间线对上。

systemd 主机：用 journalctl -k 对照内核日志

启用 systemd-journald 的主机通常会把内核消息纳入 journal。journalctl -k 读取的是内核日志集合，-b 限定当前启动周期；这两个边界比“盯着 dmesg 最后几十行”更容易复核：

journalctl -k -b --no-pager -n 120
journalctl -k -b --since "10 min ago" --no-pager
systemctl status systemd-journald --no-pager

若 journal 中有 kernel: 前缀的记录，而 dmesg 看不到，优先沿 journald 路径继续。若两边都没有目标事件，再回到事件发生时间、消息级别和缓冲区覆盖检查；不要把 journald 服务的 active (running) 误当成“所有历史日志都已永久保存”。

持久化与转发：Storage 决定重启后还能不能查

查看 journald 的生效配置：

journalctl --disk-usage
journalctl --verify
systemd-analyze cat-config systemd/journald.conf

关注 Storage=auto、Storage=persistent 或 Storage=volatile 的实际结果。持久化存储还要看 /var/log/journal 是否存在、磁盘是否可写，以及日志轮转后是否仍在保留期内。配置文件写完不等于已经生效，修改后应重载 journald 并用新的启动周期或一条可识别的内核事件做复核。

几种方案怎么选：看故障现场而不是命令偏好

现场保留与复查顺序

一次完整留证至少包括：主机名、内核版本、当前启动 ID、dmesg 过滤结果、journalctl 内核日志、journald 磁盘占用和配置生效结果。可以按下面顺序执行，输出文件名不要覆盖上一轮：

hostnamectl
uname -r
cat /proc/sys/kernel/random/boot_id
journalctl -k -b --no-pager > /var/tmp/kernel-journal-current.log
dmesg --time-format=iso --color=never > /var/tmp/kernel-buffer-current.log

修复配置后先复查 journalctl -k -b，再比较两份文件的时间范围。若事件只在内核环形缓冲区出现、journal 没有对应行，不要声称“日志已持久化”；应把差异写进交接记录。

常见问题

dmesg 和 journalctl -k 哪个更可靠？

两者读取路径不同。dmesg 更接近当前内核环形缓冲区，journalctl -k 更适合按启动周期和时间范围检索；生产排查通常把两者对照，而不是只选一个。

把 kernel.dmesg_restrict 改成 0 能解决问题吗？

它只能改变部分读取权限，不能恢复已经被覆盖或轮转删除的日志。先确认权限是否是根因，再按主机安全边界选择受控读取方式。

journalctl --verify 通过就代表日志完整吗？

不代表。它主要检查 journal 文件结构和一致性；日志是否覆盖、是否持久化、是否超出保留期，还要结合启动周期、Storage 和时间范围判断。

收尾检查

排查 dmesg 缺日志的关键不是寻找一条万能命令，而是把读取权限、消息级别、缓冲区生命周期和 journald 持久化拆开验证。现场先留原始输出，配置调整后再以新的启动周期和明确时间范围复查，日志链路才算闭合。