文章归档

设备部署到现场后，研发很少能直接接触实物。远程诊断能力决定了问题能不能快速闭环。最基本的远程诊断不是远程 shell，而是能安全地导出状态、日志和配置快照。

现场问题最怕“设备有问题，但没有日志”。嵌入式设备的观测能力不需要一开始就复杂，但至少要能回答：设备是什么版本、发生过什么、当前状态如何、配置是什么、网络是否正常。

一、问题背景

本地使用 Codex CLI 时，如果日志级别过细，~/.codex/logs_2.sqlite 可能会持续写入大量 TRACE / DEBUG 日志。

这类问题不一定会立刻表现为程序异常，但会带来几个隐患：

• SQLite 主库文件持续变大。
• WAL 文件频繁增长。
• 磁盘出现持续小块写入。
• 日志价值不高，但占用大量 IO。
• 长时间运行后影响终端工具响应。

这次排查的目标很明确：

1. 确认 logs 表是否被 TRACE 日志高频写入。
2. 如果中招，先备份数据库。
3. 使用 SQLite trigger 拦截 logs 表 insert。
4. 对 WAL 执行 checkpoint / truncate。
5. 采样确认 MAX(id) 和 WAL 不再增长。

一、日志为什么需要治理

日志是排查线上问题最直接的证据，但不加治理的日志也会带来风险：

• 文件无限增长，磁盘被写满。
• 多进程写同一个文件，内容交错。
• 日志级别混乱，关键错误被淹没。
• 服务重启后旧日志无法关联。
• 没有采集和告警，问题只能靠人工发现。

日志治理要解决三个问题：写到哪里、保留多久、怎么发现异常。