3. 产品级日志需求分析
在原型阶段，日志往往只是“能打印就行”；但到了产品级，日志系统必须同时满足可靠性、实时性、可读性、可追溯性，并且要在 MCU 的 RAM、Flash、CPU 与带宽约束下做出取舍。本节的核心不是罗列需求，而是把需求转化为可验证的设计指标，并明确哪些指标必须优先保障、哪些可以降级。
产品级日志需求分析的本质：把“希望日志好用”翻译成“在给定资源下，日志系统必须达到哪些可测量指标，以及冲突时如何取舍”。
一、核心原理：五维需求与资源约束的冲突模型
产品级日志的五个维度并不是孤立存在的，它们之间存在天然的张力。可靠性要求日志不丢、不坏、可恢复；实时性要求日志写入不能阻塞关键任务；可读性要求格式统一、语义清晰；可追溯性要求时间、任务、模块、事件 ID 可关联；资源受限则要求 RAM 占用小、Flash 写入少、CPU 开销低。理解这些冲突，是设计指标的前提。
从图中可以看出，资源受限是中心约束，四个方向的需求都会向它施压。因此，产品级日志设计的第一步不是选组件，而是确定“在什么场景下，哪个维度优先”。
二、方法流程：从需求到可验证设计指标
需求分析不能停留在形容词层面，必须转化为可测量、可验收的指标。建议按以下流程推进：
- 识别日志场景：区分启动日志、运行日志、故障日志、审计日志、性能日志，不同场景的优先级不同。
- 定义关键指标：为每个维度设定量化目标，例如丢包率、写入延迟、单条日志大小、时间戳精度、Flash 擦写寿命。
- 评估资源预算：明确 RAM 缓冲上限、Flash 分区大小、CPU 占用率上限、总线带宽上限。
- 制定降级策略：当资源紧张或故障发生时，明确哪些日志可以丢弃、哪些必须保留、哪些可以压缩。
- 建立验收方法：通过压力测试、掉电测试、长时间老化测试验证指标是否达标。
| 需求维度 | 典型设计指标 | 建议目标值（MCU 场景） | 验证方法 |
|---|---|---|---|
| 可靠性 | 日志丢失率、掉电恢复完整率 | 关键日志丢失率 < 0.01%，掉电恢复率 > 99% | 随机掉电测试、CRC 校验统计 |
| 实时性 | 单条日志写入延迟、任务阻塞时间 | 中断内 < 5 μs，任务上下文 < 50 μs | GPIO 翻转 + 示波器测量 |
| 可读性 | 格式统一率、解析成功率 | 100% 符合预定义格式，解析成功率 > 99.9% | 日志解析工具批量校验 |
| 可追溯性 | 时间戳精度、上下文完整度 | 时间戳误差 < 1 ms，任务/模块字段完整 | 时间同步测试、字段缺失统计 |
| 资源占用 | RAM 缓冲、Flash 占用、CPU 占用 | RAM < 4 KB，CPU < 3%，Flash 分区可配置 | 内存分析、性能剖析、分区统计 |
三、案例/场景：工业网关的日志取舍
某工业网关基于 Cortex-M7，运行 RTOS，需同时处理 Modbus 采集、MQTT 上报和本地存储。初始方案采用同步 printf 输出到串口，结果在 Modbus 高频采集时出现任务超时。复盘后发现：日志写入阻塞了采集任务，且串口带宽不足导致日志堆积。
调整后的方案采用“分级异步 + 关键路径旁路”策略：
日志级别策略：
ERROR → 立即写入，带时间戳、任务 ID、事件码，允许阻塞 < 100 μs
WARN → 进入环形缓冲，由低优先级日志任务异步落盘
INFO → 仅保留最近 200 条，覆盖式写入
DEBUG → 默认关闭，通过诊断命令临时开启
资源预算：
RAM 环形缓冲：2 KB
Flash 日志分区：64 KB，双扇区交替写入
单条日志最大长度：128 字节
时间戳精度：1 ms，基于 RTOS tick + RTC 校准
该案例说明：产品级日志不是“全部记录”，而是“在正确的时间记录正确级别的信息”。关键故障日志必须可靠，普通运行日志可以降级或覆盖。
取舍口诀：故障现场保可靠，控制路径保实时，分析场景保可读，审计场景保可追溯，资源紧张时按级别降级。
四、误区/复盘：常见需求分析陷阱
- 误区一：把“日志详细”等同于“日志好用”。字段过多会增加 RAM 和 Flash 开销，反而降低可靠性。应按场景裁剪字段。
- 误区二：忽视中断上下文限制。在中断中调用阻塞式日志接口，会导致系统实时性崩溃。必须提供中断安全的轻量接口。
- 误区三：时间戳只依赖 RTOS tick。tick 会溢出且掉电丢失，产品级方案应结合 RTC 或外部时间同步。
- 误区四：没有定义日志丢失策略。缓冲区满时是覆盖、丢弃还是阻塞，必须提前明确，否则现场行为不可预测。
- 误区五：忽略 Flash 擦写寿命。高频写入同一扇区会快速耗尽寿命，应采用轮转或双备份策略。
需求分析阶段最危险的信号是“所有日志都重要”。如果无法排序，就无法在资源受限时做出正确取舍，最终导致关键日志丢失或系统实时性受损。
综上，产品级日志需求分析应围绕可靠性、实时性、可读性、可追溯性和资源约束建立量化指标，并通过场景分级、异步缓冲、降级策略和验收测试形成闭环。只有把需求转化为可测量、可验证、可取舍的设计指标，日志系统才能在产品环境中真正发挥作用。