Zephyr 日志与追踪实战：3 行 Kconfig 搭出全链路调试通道

Zephyr 日志与追踪实战：3 行 Kconfig 搭出全链路调试通道

【免费下载链接】zephyrPrimary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.项目地址: https://gitcode.com/GitHub_Trending/ze/zephyr

设备在野外出故障又够不着串口时，你靠的就是固件留下的日志与追踪记录。Zephyr 的 logging 子系统只做三件事：非阻塞地采集日志、按模块过滤级别、可替换输出后端，且都支持运行时重配。本文从 Kconfig 到 log_filter_set 接口把这条链路搭完整，日志不够用时再上 tracing。

先看懂管道：为什么 LOG 宏不会卡住你的业务线程

printk 和 logging 子系统最大的区别在于"谁等 UART"。printk 是同步发送，调用者当场完成格式化与输出，控制台若为轮询模式，调用者会实打实地等在那里，中断上下文里要格外小心。而 Zephyr 的日志宏在 deferred 模式（默认）下只做一件事：把带时间戳和模块 ID 的紧凑结构体塞进内部环形缓冲区就返回，真正的格式化和后端发送交给一条专门的日志处理线程完成。

代码侧你只需要在文件顶部写一行LOG_MODULE_REGISTER(模块名)，之后LOG_INF/LOG_WRN/LOG_ERR/LOG_DBG这套宏就能用，模块名就是后续过滤的句柄。

先把最小闭环的配置写出来：

CONFIG_LOG=y CONFIG_LOG_DEFAULT_LEVEL=3 # 0=OFF 1=ERR 2=WRN 3=INF 4=DBG CONFIG_LOG_BUFFER_SIZE=2048 # 内部环形缓冲区大小 CONFIG_LOG_PROCESS_THREAD=y # 专门线程负责格式化与发送 CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD=10 # 攒够 10 条唤醒处理线程

这份配置完成了"采集进缓冲区 → 处理线程 → 后端"的完整管道。缓冲区写满时默认丢弃最旧的消息（LOG_MODE_OVERFLOW），线程上下文下也可配置为等待固定时间（LOG_BLOCK_IN_THREAD），保证日志链路不会反过来死锁业务。这套调度的核心逻辑在日志核心实现里。

📡 按场景选输出去处：4 类后端

后端决定日志"落到哪里"。Zephyr 把每个后端做成独立的 Kconfig 选项，可自由组合，完整清单见后端选项列表。实战中用得最多的是四个：

• UART：台架调试首选，串口号（常见 115200）直接看流；
• RTT：复用 J-Link 的 RTT 通道，不占额外串口，也不干扰控制台；
• FS：日志写进文件系统的文件，掉电后依然可以事后取证；
• BLE：没有调试接口的现场设备唯一出路，走蓝牙 GATT 通道把日志发回来。

CONFIG_LOG=y CONFIG_LOG_BACKEND_UART=y # 台架：串口 # CONFIG_LOG_BACKEND_RTT=y # 用 J-Link 的选这个 # CONFIG_LOG_BACKEND_FS=y # 落盘归档 # CONFIG_LOG_BACKEND_BLE=y # 现场设备

这几个选项彼此独立，完全可以同时打开 UART + FS，实现"随手可看 + 落盘归档"双通道。像 Meerkat 96 这类部署到现场、串口彻底够不着的开发板，切到 BLE 后端只需一行。

把噪音关小：日志级别的两层过滤

编译期：3 个数值 + 按模块自动生成的选项

级别是 0~4 的刻度：OFF / ERROR / WARNING / INFO / DEBUG。控制全局形状的是三个选项：

CONFIG_LOG_DEFAULT_LEVEL=2 # 未单独声明的模块用这个级别 CONFIG_LOG_MAX_LEVEL=4 # 天花板，发布版可设为 2 编译期砍掉 INF/DBG CONFIG_LOG_MAIN_LEVEL=4 # 每个 LOG_MODULE_REGISTER 都会生成对应模块选项

这里有个坑：模块自己的级别和LOG_MAX_LEVEL取更严格的那个。发布版瘦身先降LOG_MAX_LEVEL，二进制体积才是实打实地变小，而不是只少了输出。

运行时：log_filter_set 随时切换模块级别

打开CONFIG_LOG_RUNTIME_FILTERING之后，调级别不用重新编译。logger 示例里的写法可以直接抄：

/* 关掉 temp_sensor 模块的日志 */ log_filter_set(NULL, 0, log_source_id_get("temp_sensor"), LOG_LEVEL_NONE);

四个参数依次是上下文、域、模块 ID、目标级别。传LOG_LEVEL_NONE是彻底闭嘴，传LOG_LEVEL_WRN就只留警告。排查时把嫌疑模块单独提到 DEBUG，其他模块保持静音，日志流立刻干净。

⏱ 日志不够用时：用 tracing 抓对象时间线

日志回答"发生了什么"，tracing 回答"哪个线程、哪个对象、等了多久"。打开CONFIG_TRACING后，内核对象操作点（线程切换、信号量、工作队列、定时器……）默认全部打点。格式二选一：CTF 是开放格式，可丢给 Trace Compass 解析；Segger SystemView 给可视化时间线。

CONFIG_TRACING=y CONFIG_TRACING_CTF=y # 开放格式 CONFIG_TRACING_ASYNC=y # 先入环形缓冲再外发，开销小 CONFIG_TRACING_BUFFER_SIZE=4096 CONFIG_TRACING_BACKEND_UART=y CONFIG_TRACING_SHELL=y # 提供 tracing shell 命令

异步模式下事件先打包进环形缓冲区，由专门的 tracing 线程慢慢外发，业务代码只付几个周期的开销。配上TRACING_SHELL，运行时进 shell 就能控制开停和查看丢包统计——问题复现当天打开、抓 10 秒、关掉，就是最省事的现场取证节奏。更多实现细节看追踪核心实现。

典型验证对象是 nRF52840 这类 Cortex-M 开发板：SystemView 的时间线把线程切换、中断嵌套直接铺在眼前，锁等待这种日志里只能靠文字描述的问题，变成了看得见的一段间隔。

崩溃取证：死机前先把缓冲区倒干净

deferred 模式的代价是：系统死掉那一刻，缓冲区里可能还压着没发出去的消息。两个动作：

关键动作前把缓冲区排空，示例里就有现成模式：

static void wait_on_log_flushed(void) { while (log_buffered_cnt()) { k_sleep(K_MSEC(5)); } }

在sys_reboot或预期崩溃点前调用它；或者直接用LOG_PANIC，它会先把所有缓冲日志一次性刷出，再触发 panic。

第二个动作是让 trace 留在内存里：tracing 的 RAM 后端（TRACING_BACKEND_RAM配RAM_TRACING_BUFFER_SIZE）把数据停驻在 RAM 中，设备重启后照样能用 GDB 把这段记录倒出来。日志是文字，trace 是时间线，两条一起上，"突然死机"基本都能翻案。

非阻塞采集、分层过滤、可换后端——日志与追踪把死机从悬案变成可回放的档案。你的项目里，现场救过命的是哪个后端？

【免费下载链接】zephyrPrimary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.项目地址: https://gitcode.com/GitHub_Trending/ze/zephyr