2. Edge AI设备与日志基础

在构建Edge AI设备的日志聚合与检索系统之前，必须首先厘清日志的源头——即设备本身。Edge AI设备并非单一形态，而是涵盖了从低功耗MCU到高性能边缘服务器的广泛谱系。不同设备的硬件架构、操作系统、AI推理框架和网络连接方式，直接决定了日志的产生频率、格式规范、传输路径和存储成本。本章将系统梳理Edge AI设备的类型划分、日志产生机制、主流日志格式以及高频出现的日志问题，为后续的字段设计提供扎实的物理与逻辑基础。

2.1 Edge AI设备的类型与日志特征

Edge AI设备按算力、内存和操作系统可划分为四个层级，每一层的日志产生逻辑和运维关注点截然不同。理解这些差异是设计统一日志字段的前提，因为字段必须兼容最轻量设备的最小集，同时支持最复杂设备的扩展集。

在字段设计时，L1设备往往只能输出简单的字符串，甚至没有实时时钟，需要网关补充时间戳；L2和L3设备通常支持JSON或syslog，但JSON字段命名可能不一致；L4设备则可能产生多行堆栈和链路追踪ID。因此，日志聚合系统必须支持“设备类型”作为第一级过滤字段，并允许不同设备类型拥有不同的必填字段集合。

2.2 日志产生机制与生命周期

Edge AI设备的日志产生并非均匀连续，而是由事件驱动、周期任务和异常触发三类机制混合构成。理解产生机制有助于设计合理的采样频率和缓冲策略，避免日志丢失或网络拥塞。

• 事件驱动日志：如AI推理完成、传感器越限、模型加载失败。这类日志通常突发性强，需要在设备端设置环形缓冲区，防止瞬时大量日志覆盖旧数据。
• 周期状态日志：如每5分钟上报一次CPU温度、内存占用、网络信号强度。这类日志适合在网关上做预聚合，减少上行带宽消耗。
• 异常/崩溃日志：包括内核panic、应用core dump、看门狗复位记录。这类日志最关键且最易丢失，必须使用独立的持久化存储分区，并优先传输。

日志在设备内的生命周期通常经历四个阶段：产生（Application/Driver）→ 格式化（Logger库）→ 本地存储（文件/Flash）→ 传输（MQTT/HTTP/Syslog）。在传输阶段，设备可能因网络不稳定而缓存日志，此时需要记录“本地缓存时间”和“实际发送时间”两个字段，以便后续计算传输延迟。

// 设备端日志产生示例（ESP32伪代码）
void on_inference_done(float confidence, int class_id) {
    log_event("ai_inference", 
        "conf", confidence, 
        "class", class_id, 
        "model_ver", "v2.3.1");
    // 内部自动附加：device_id, timestamp, seq_num
}

2.3 日志格式：从自由文本到结构化演进

当前Edge AI设备的日志格式呈现三种形态并存的状态。老旧的MCU设备可能只输出printf风格的纯文本，而现代边缘网关则普遍采用JSON或Key-Value格式。日志聚合系统必须能够同时解析这三种格式，并在检索时统一转换为标准字段。

在字段设计层面，建议将log_format作为保留字段，记录原始日志的格式类型。同时，对于JSON日志，应提取event_type作为二级索引；对于自由文本，则通过正则模板在网关侧进行预解析，将提取出的关键值（如温度、电压）填充到标准字段中。

2.4 常见日志问题与排查路径

在实际运营中，Edge AI设备的日志问题远比想象中复杂。以下是三类高频问题及其典型表现，这些问题直接影响日志聚合的完整性和检索的准确性。

• 时间戳漂移与乱序：设备没有RTC电池或NTP不可达，导致日志时间比实际时间慢数小时。多设备日志汇聚后，按时间排序会出现倒挂。解决方法是增加ingest_time（网关接收时间）字段，并允许按该字段排序。
• 日志截断与丢失：设备在弱网环境下缓存日志，但缓存区过小，导致早期日志被覆盖。典型特征是日志序列号（seq_num）不连续。应在设备端记录drop_count字段，并在聚合端计算丢包率。
• 敏感信息泄露：AI推理日志中可能包含人脸框坐标、车牌号等隐私数据。若直接明文传输，存在合规风险。建议在设备端对敏感字段进行脱敏（如将坐标模糊化），或在传输层使用TLS加密。