1、日志系统概述：为什么嵌入式系统需要可观测性？日志的三大支柱（指标、追踪、日志）及核心价值。
大家好，我是你们的老朋友。今天咱们聊聊嵌入式系统的可观测性。说实话，我入行那会儿，压根没听过这个词。那时候调试靠什么？靠串口打印，靠示波器，靠运气。现在想想，真是硬着头皮上。
可观测性，说白了就是让系统内部的状态能被外部感知。你想想看，一个跑在深山老林里的传感器节点，或者一个飞在天上的无人机飞控，出了问题你总不能拿螺丝刀去拆吧？
嵌入式系统为什么特别需要可观测性？我总结了三个核心原因：
- 资源受限：MCU的RAM可能只有几KB，CPU主频几十MHz。你没法像服务器那样装个Prometheus+Grafana全家桶。
- 实时性要求：很多嵌入式系统对时间敏感。一个中断响应慢了，可能就丢包了，甚至炸机了。
- 环境恶劣：电磁干扰、温度变化、震动……这些都会导致偶发故障。你复现不了，就只能靠日志去猜。
我记得有一次，一个客户说他们的设备在东北冬天就死机，夏天就没事。我们远程调试了两个月，最后发现是低温导致晶振起振不稳定。如果没有完善的日志系统，这种问题根本没法定位。
日志的三大支柱：指标、追踪、日志
很多人以为可观测性就是打日志。其实不对。完整的可观测性体系有三个支柱：指标（Metrics）、追踪（Tracing）、日志（Logs）。这三者缺一不可。
核心观点：指标告诉你系统「出了什么问题」，追踪告诉你「问题出在哪条路径上」，日志告诉你「问题具体是什么」。
我画了一张图，帮你理解这三者的关系：
指标（Metrics）——系统的体温计
指标是数值化的、可聚合的数据。比如CPU占用率、堆栈使用量、任务切换次数。它的特点是：轻量、可聚合、适合做告警。
我个人习惯在项目中维护一个「关键指标清单」。举个例子：
| 指标名称 | 采集方式 | 告警阈值 | 说明 |
|---|---|---|---|
| CPU负载率 | 空闲任务统计 | > 85% | 过高可能导致任务饿死 |
| 堆栈余量 | MPU/软件检查 | < 20% | 堆栈溢出是嵌入式头号杀手 |
| 看门狗复位次数 | RTC备份寄存器 | > 3次/小时 | 系统可能陷入死循环 |
我的经验：指标采集本身也会消耗资源。我建议把指标采集放在空闲任务里，优先级设最低。别让「监控」本身成为系统的负担。
追踪（Tracing）——问题的导航仪
追踪解决的是「谁调用了谁」的问题。在嵌入式系统里，一个按键按下，可能触发中断、唤醒任务、调用驱动、操作外设……这一串调用链，就是追踪要记录的东西。
我曾经在一个多任务系统中遇到一个bug：两个任务同时操作同一个UART，导致数据错乱。光看日志根本看不出问题，因为日志本身也是通过UART打印的。后来我加了追踪功能，记录每个任务访问UART的时间戳，才抓到真凶。
嵌入式追踪的常用手段：
- DWT/ETM：ARM内核自带的硬件追踪单元，精度高但需要调试器支持
- 软件插桩：在关键函数入口/出口插入标记点
- RTOS Trace：FreeRTOS等系统自带的追踪功能
日志（Logs）——最后的救命稻草
日志是最传统、最直接的手段。但嵌入式日志有个痛点：存储空间有限。你不能像服务器那样把GB级别的日志写到磁盘上。
我常用的日志分级策略：
// 日志等级定义
#define LOG_LEVEL_ERROR 0 // 致命错误，必须记录
#define LOG_LEVEL_WARN 1 // 警告，可能有问题
#define LOG_LEVEL_INFO 2 // 重要信息，如状态切换
#define LOG_LEVEL_DEBUG 3 // 调试信息，开发阶段用
#define LOG_LEVEL_VERBOSE 4 // 啰嗦模式，基本不用
// 运行时动态调整日志等级
void set_log_level(uint8_t level) {
g_log_level = level;
}
// 日志输出宏
#define LOG_ERROR(fmt, ...) \
do { if (g_log_level >= LOG_LEVEL_ERROR) \
log_output("[ERR] " fmt, ##__VA_ARGS__); \
} while(0)
避坑指南：我曾经在正式版固件里忘了关DEBUG日志，结果日志缓冲区把关键数据覆盖了。现在我的习惯是：发布前强制把日志等级设为WARN以上，并且用编译宏把DEBUG代码彻底去掉。
三大支柱的核心价值
说了这么多，这三者到底能带来什么价值？我总结为四点：
- 快速定位故障：指标告诉你「CPU飙高了」，追踪告诉你「是CAN中断占用了太多时间」，日志告诉你「CAN控制器报总线关闭错误」。十分钟解决问题，而不是三天。
- 预防性维护：通过指标趋势分析，你可以在系统崩溃前就发现异常。比如堆栈余量持续下降，说明有内存泄漏。
- 性能优化依据：没有数据，你只能凭感觉优化。有了指标和追踪，你可以精确知道哪个函数耗时最多，哪个中断触发最频繁。
- 远程诊断能力：设备部署在现场，你坐在办公室。通过日志回传，你可以像在现场一样分析问题。
嗯，这里要注意一点：不要试图一次性把三大支柱都做完美。我建议从日志开始，逐步加入指标，最后再上追踪。一口吃不成胖子，嵌入式系统尤其如此。
好了，这一章就聊到这里。记住：可观测性不是锦上添花，而是嵌入式系统的刚需。下一章我们深入聊聊日志系统的具体设计——怎么在有限的资源下，写出高效、可靠、易用的日志模块。
公众号:蓝海资料掘金营，微信deep3321