采集软件的日志设计：现场排障为什么离不开日志

■ 一、日志不是给开发看的

很多采集软件的日志，是开发调试时随手打的：打印变量、打印错误码。上线之后，这些日志在现场几乎没用——因为它们不回答现场最关心的问题：什么时候出的错、错了多久、影响哪些数据。

面向现场的日志，要以"事后复盘"为目标来设计。

■ 二、三类日志，各司其职

第一类，运行日志。记录启动、配置加载、通信建立、定时任务执行。回答"系统在正常运行吗"。

第二类，异常日志。记录通信中断、校验失败、存储满、复位原因。回答"什么时候坏了、坏了多久"。

第三类，审计日志。记录参数修改、校准动作、固件升级。回答"谁在什么时候改了什么"。

三类要分开存，混在一起查起来最费时间。

■ 三、必带的字段

· 时间戳（本地时间 + 单调计数，防止时钟被改后无法排序）
· 设备编号与固件版本
· 事件类型与级别
· 关键上下文（通道号、寄存器地址、错误码、持续时间）

少了"持续时间"，就只能知道出过错，不知道影响了多少数据。

■ 四、日志要能"自证"

现场最怕的是"日志说没问题，数据说有问题"。解决办法是让日志包含可核对的数据：比如每次通信成功记录收到的条数与序号范围，这样数据缺口能直接从日志里定位。

■ 五、容量与滚动

现场设备存储有限。建议：按大小滚动、按天归档、保留最近 N 天明细 + 长期统计。统计部分至少保留：每日通信中断次数与总时长、每日复位次数、每日校验失败次数。

这三项统计，比几万行明细更有用。

■ 六、日志级别要克制

全部打 DEBUG 会淹没有效信息，也会拖慢系统。我的做法是：默认 INFO，异常时自动提升到 DEBUG 并持续一段时间，故障过后自动回落。这样既不丢信息，也不长期占资源。

■ 七、导出与上报

现场排查经常需要把日志拿出来。要提供两种方式：本地导出（U 盘/网页下载）与远程上报（只上报统计与关键事件，不上报全量明细）。

■ 八、一个检查清单

· 三类日志分开（运行/异常/审计）
· 每条含时间戳、设备号、固件版本、持续时间
· 通信日志含序号与条数（可核对数据缺口）
· 按大小滚动 + 按天归档
· 保留每日统计三项（中断次数与时长、复位次数、校验失败）
· 异常时自动提升日志级别
· 支持本地导出与远程上报

■ 九、最后一句

日志的价值不在"记了多少"，而在"能不能回答现场那三个问题"。设计日志时先想清楚要回答什么，再决定记什么。