4、日志采集与上报：本地日志采集方法、远程日志上报机制、日志压缩与加密传输
大家好，我是你们的嵌入式老兵。今天咱们聊聊OTA升级里一个特别容易被忽视、但又特别关键的环节——日志采集与上报。
说实话，我见过太多工程师，升级方案做得漂漂亮亮，结果一出问题，两眼一抹黑。为啥？因为日志没采上来，或者采上来了但被压缩加密搞坏了。嗯，今天咱们就把这块彻底讲透。
4.1 本地日志采集方法
先说说本地日志怎么采。你想想看，设备在升级过程中，网络可能断、存储可能满、甚至系统都可能重启。所以本地日志采集，第一原则就是：不能依赖任何外部资源。
4.1.1 环形缓冲区（Ring Buffer）
我个人最推荐的方式，就是用环形缓冲区。说白了，就是一块固定大小的内存，写满了就从头覆盖。这样即使存储满了，最新的日志也不会丢。
// 环形缓冲区示例
#define LOG_BUF_SIZE 4096
static char log_buf[LOG_BUF_SIZE];
static uint32_t write_idx = 0;
void log_write(const char *msg) {
int len = strlen(msg);
for (int i = 0; i < len; i++) {
log_buf[(write_idx + i) % LOG_BUF_SIZE] = msg[i];
}
write_idx = (write_idx + len) % LOG_BUF_SIZE;
}
4.1.2 分级日志
日志不能什么都记，否则很快就把缓冲区撑爆了。我习惯把日志分成几个等级：
| 等级 | 说明 | 示例 |
|---|---|---|
| ERROR | 致命错误，必须记录 | 校验失败、写入超时 |
| WARN | 异常但不致命 | 重试次数超限、电量低 |
| INFO | 关键流程信息 | 开始下载、校验通过 |
| DEBUG | 调试用，默认关闭 | 具体变量值、函数调用栈 |
为什么要分级？因为升级过程中，大部分时间跑的都是正常流程。如果每个包都记一条INFO日志，几万个包下来，缓冲区早满了。我一般只在ERROR和WARN级别下才保证100%记录，INFO级别看情况，DEBUG级别默认关掉。
4.1.3 时间戳与序列号
日志里一定要带时间戳。没有时间戳的日志，就像没有日期的日记——你根本不知道事情发生的先后顺序。
但这里有个坑：设备刚上电时，RTC可能不准。我建议用系统滴答时钟（SysTick）或者一个递增的序列号来代替。这样即使时间不对，至少能看出先后顺序。
// 带序列号的日志
void log_printf(const char *fmt, ...) {
static uint32_t seq = 0;
char buf[128];
snprintf(buf, sizeof(buf), "[%06u] ", seq++);
// 拼接实际日志内容...
}
4.2 远程日志上报机制
本地日志采好了，怎么传到服务器？这里有几个关键点。
4.2.1 上报时机
不是所有日志都要立刻上报。我见过有些方案，每写一条日志就发一个HTTP请求，结果升级还没完成，网络先被日志请求打爆了。
我建议的做法是：
- 升级过程中：只在关键节点（如开始、校验通过、失败）上报少量日志
- 升级完成后：一次性上报完整的日志缓冲区
- 升级失败时：立即上报当前缓冲区内容，然后尝试重启
4.2.2 断点续传
日志上报也可能失败。尤其是升级失败时，网络可能已经不稳定了。这时候需要断点续传机制。
我常用的方案是：把日志分成多个小块，每块大小不超过1KB。服务器记录已接收的块序号，设备下次上报时从断点继续。
// 日志分块上报
typedef struct {
uint32_t total_blocks;
uint32_t current_block;
uint8_t data[1024];
} LogBlock;
4.3 日志压缩与加密传输
日志里可能包含敏感信息，比如设备ID、用户数据、甚至密钥。所以压缩和加密是必须的。
4.3.1 压缩算法选择
嵌入式设备资源有限，不能随便上gzip。我常用的压缩算法有：
| 算法 | 压缩率 | 内存占用 | 适用场景 |
|---|---|---|---|
| LZSS | 中等 | 低（~2KB） | MCU资源紧张 |
| LZ4 | 较低 | 低（~4KB） | 需要快速压缩 |
| zlib | 高 | 高（~32KB） | 资源充足的设备 |
我个人在资源受限的MCU上，最常用LZSS。压缩率虽然不如zlib，但内存占用只有2KB左右，而且解压速度极快。
4.3.2 加密传输
加密这块，我建议用对称加密，比如AES-128。非对称加密（如RSA）在MCU上太慢了，一个签名验证可能要好几秒。
但密钥怎么存？这是个老大难问题。我见过有人把密钥硬编码在代码里，结果被反编译出来。我的做法是：
- 密钥由服务器下发，设备每次上报前向服务器请求临时密钥
- 临时密钥用设备的唯一ID（如MAC地址）加密传输
- 设备收到后，用本地存储的私钥解密，得到临时密钥
// 加密上报示例
void upload_log_encrypted(uint8_t *log_data, uint32_t len) {
// 1. 请求临时密钥
uint8_t temp_key[16];
request_temp_key(device_id, temp_key);
// 2. 压缩日志
uint8_t compressed[LOG_BUF_SIZE];
uint32_t compressed_len = lzss_compress(log_data, len, compressed);
// 3. 加密
uint8_t encrypted[LOG_BUF_SIZE];
aes_encrypt(compressed, compressed_len, temp_key, encrypted);
// 4. 上报
http_post("/log/upload", encrypted, compressed_len);
}
4.4 实战中的坑与经验
最后，分享几个我踩过的坑：
- 日志缓冲区溢出：有一次，设备在升级失败后反复重启，每次重启都往缓冲区写日志，结果把环形缓冲区写穿了，覆盖了前面的关键信息。后来我加了一个"重启次数"计数器，超过3次就只记录不覆盖。
- 时间戳不同步：设备上报日志时，用的是本地RTC时间。但RTC没校准，比服务器时间慢了2小时。排查问题时，服务器端看到的时间线和设备端完全对不上。后来我强制要求设备在上报时附带一个"本地时间戳"，服务器端再换算成统一时间。
- 压缩后反而更大：日志内容太短时，压缩算法加上头部信息，反而比原始数据还大。我加了一个判断：如果压缩后的数据比原始数据还大，就直接发送原始数据。
好了，关于日志采集与上报，今天就聊这么多。记住一句话：日志是OTA升级的"黑匣子"，采得好、报得稳，问题才能查得清。下一章，咱们聊聊升级失败后的回滚机制，那才是真正的"保命"技能。