Linux dmesg 工业边缘实战：内核日志过滤、持久化与故障定位

工业边缘设备出问题时，最先暴露问题的往往不是业务日志，而是内核日志。Linux dmesg 能直接看到硬件、驱动、OOM、panic、网络链路和设备热插拔等底层信息，是现场定位故障时优先要查的入口。

本文按“基础回顾、过滤、排障、持久化、实时监测、sysctl、生产实践”展开，给出可直接落到工业网关和边缘节点上的用法。

一、为什么工业边缘要关注内核日志

工业网关、边缘控制器和一体机通常长周期在线运行，硬件环境比机房服务器更复杂：温度、供电、振动、串口、USB 外设、多网卡都会影响稳定性。应用层日志可能持续报错，但真正的原因往往要回到内核日志验证：

• 驱动加载失败或设备掉线，会在内核日志里留下明确记录。
• 内存压力导致的 OOM killer，会给出进程和内存占用上下文。
• 网卡链路抖动、协商失败，会直接影响工业协议通信。
• USB 或串口设备反复断开，往往不是应用代码问题。
• panic、oops、watchdog 等严重故障，必须从内核侧拿现场。

所以不要把 dmesg 当成“高级工具”，它是边缘设备第一道排障入口。

二、基础用法回顾

dmesg                  # 查看当前内核环形缓冲
dmesg -T               # 输出人类可读时间
dmesg -l err           # 只看错误级别
dmesg -k               # 只看内核消息
sudo dmesg -C          # 清空缓冲，生产环境慎用
sudo dmesg -n 3        # 控制台只保留严重级别

-T 在排查时间线时几乎必须加，否则看到的是内核时间戳，很难和业务日志对齐。清空缓冲前应先保存现场：

sudo dmesg -T > /var/log/kernel-before-clear.log

三、过滤：时间、级别、子系统

按时间

dmesg -T --since "1 hour ago"
dmesg -T --until "yesterday"
dmesg -T --since "yesterday 18:00" --until "yesterday 23:00"

时间过滤能让 grep 结果更可靠。不加 since 就 grep，很容易把历史告警当成本次故障。

按级别

dmesg -l emerg,alert,crit,err
dmesg -l err,warn
dmesg -T -l err,warn --since today

级别过滤适合快速缩小范围。先看 err 和 warn，再决定是否进入 info 和 debug 追踪。

按子系统

dmesg -f kern          # 内核子系统
dmesg -f user          # 用户空间消息

大部分工业边缘故障发生在内核子系统，使用 -f kern 可减少无关消息干扰。

四、常见故障排查

硬件错误

sudo dmesg -T | grep -Ei 'hardware error|mce|i/o error'

OOM

sudo dmesg -T | grep -Ei 'out of memory|oom|killed process'

加上 -A 20 可以看到被杀进程附近的完整上下文：

sudo dmesg -T | grep -A 20 -Ei 'killed process'

网络链路

sudo dmesg -T | grep -Ei 'eth|enp|link is up|carrier|duplex'

如果网关与 PLC 之间偶发断连，先确认网卡是否反复 down/up、链路速率是否协商异常。

USB 与串口外设

sudo dmesg -T | grep -Ei 'usb|new .* device|disconnect'

外接传感器、加密狗、调试线反复掉线时，这条命令能快速区分“设备硬件问题”和“系统驱动问题”。

panic 与 oops

sudo dmesg -T | grep -Ei 'panic|oops|bug|watchdog'

一旦出现 oops 或 panic，应保留完整内核日志并记录时间点，不要只截取一行。

五、持久化：journald 与 syslog

dmesg 默认读取的是内存环形缓冲，重启可能丢失。生产节点应启用持久化。

journald

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

查看历史启动和今天的内核日志：

journalctl -k
journalctl -k --since today
journalctl -k -b -1

需要控制磁盘占用时，可修改 /etc/systemd/journald.conf：

Storage=persistent
SystemMaxUse=4G
MaxRetentionSec=30day

修改后执行 sudo systemctl restart systemd-journald 或 sudo systemctl kill -s USR1 systemd-journald 重新加载。

syslog

如果现场仍使用 rsyslog，可单独把内核日志写文件。

# /etc/rsyslog.d/99-kern.conf
kern.*    /var/log/kern.log

修改后验证配置并重启：

sudo rsyslogd -N1
sudo systemctl restart rsyslog

六、实时监测

调试设备热插拔、网络瞬断或驱动加载问题时，实时跟踪很有用：

sudo dmesg -wT
sudo dmesg -wT | tee /var/log/kernel-realtime.log
sudo dmesg -wT | grep -Ei 'error|fail' >> /var/log/kernel-alert.log

长期运行的现场环境不建议一直把全部内核消息刷进普通文件，更稳妥的是由 journald 统一持久化，再让监控端按时间窗拉取。

七、与 sysctl 配合

panic 自动重启可以避免边缘节点长时间失联；应在测试环境验证后再上线。

sudo sysctl -w kernel.panic=10

写入持久配置：

echo 'kernel.panic = 10' | sudo tee /etc/sysctl.d/99-edge.conf
sudo sysctl --system

需要减少控制台刷屏时，可临时降低 console 打印级别，例如：

sudo dmesg -n 3

调试驱动时可临时回到更详细级别：

sudo dmesg -n 7

生产配置不要随意切成最高级别，否则大量内核消息会拖慢串口 console。

八、生产实践清单

• 部署时即启用 journald persistent，并设置 SystemMaxUse。
• 记录标准时间窗：每次排障先确认设备时间与 NTP 同步状态。
• 把常用排查命令写成只读脚本，避免现场重复手敲。
• 告警不直接依赖 grep mail，优先用 journald 字段过滤和 systemd timer。
• 定期演练乱码、无输出、权限受限等场景，确认救援账号和日志位置都可用。

九、几个常见的坑

坑 1：生产环境直接清空缓冲

sudo dmesg -C 会丢掉当前现场。应对：先保存到文件，确认已经持久化后再清。

坑 2：只看 dmesg 不查历史启动

某些问题发生在上一轮启动。应对：同时使用 journalctl -k -b -1 和 dmesg -T。

坑 3：grep 不限制时间范围

没有 --since 时会把旧告警混进来。应对：先定义故障时间窗，再过滤级别和关键字。

坑 4：journald 日志无限增长

边缘设备存储小，不配 SystemMaxUse 很容易耗尽磁盘。应对：设置容量上限和保留天数，并加入磁盘监控。

坑 5：以为内核日志等于全部日志

dmesg 只覆盖内核消息，应用、服务、网络管理进程的日志要分别查。应对：统一日志入口，按来源打标签。

十、TL;DR

Linux dmesg 工业边缘实战：

• 基础：-T、-l、-k，先看时间窗。
• 过滤：时间、级别、子系统三层组合。
• 排障：硬件、OOM、网络、USB、panic 各有一套 grep 起点。
• 持久化：journald persistent 优先，rsyslog 作为补充。
• 实时：dmesg -wT 适合热插拔、链路瞬断等现场调试。
• sysctl：panic 自动重启要测试后配置，console 级别不要随意调满。

内核对不上应用日志时，先怀疑时间、缓冲清理和持久化策略，再继续深挖底层调用链。