3、日志体系入门：日志的作用、分类（系统日志、应用日志、模型日志）、日志级别与格式规范
在旭日设备的日常运维中，日志是唯一能够完整记录设备“行为轨迹”的数据载体。无论是系统崩溃、模型推理异常，还是现场偶发的通信中断，日志都是第一手排查依据。然而，许多现场工程师面对海量日志时，往往陷入“不知道看哪个文件、不知道哪条记录重要、不知道如何从一堆报错中还原现场”的困境。本章将系统梳理日志体系的核心作用、三大分类（系统日志、应用日志、模型日志）、日志级别定义以及格式规范，帮助运维人员建立一套“会看、能查、可追溯”的日志分析能力。
上图展示了旭日设备日志体系的整体框架。三类日志分别对应设备的不同运行层面：系统日志反映硬件与操作系统的健康度，应用日志记录业务逻辑的执行过程，模型日志则聚焦于AI推理链路的状态与性能。三者相互补充，共同构成完整的可观测性基础。下面我们将逐一深入。
3.1 日志的核心作用：从“黑盒”到“白盒”
日志的本质是设备运行状态的“黑匣子”。在旭日设备的现场运维中，日志承担着四个不可替代的职责：故障定位、性能分析、安全审计与版本追溯。故障定位是最直接的需求——当设备出现“识别不准”“通信中断”或“系统重启”时，日志能帮助工程师判断是硬件故障、软件缺陷还是外部环境干扰。性能分析则依赖于日志中的时间戳与耗时记录，例如一次模型推理从输入到输出花费了120ms，而正常范围是80-100ms，这20ms的偏差可能来自CPU降频或内存带宽不足。安全审计用于追踪异常登录、非法配置修改等行为，这在工业现场尤为重要。版本追溯则确保每次模型更新或固件升级都有据可查，日志中记录的版本哈希值可以与发布清单进行比对。
3.2 日志分类详解：三类日志的职责边界
旭日设备的日志体系按照数据来源和用途，严格划分为系统日志、应用日志和模型日志。三者之间既有明确分工，又存在交叉引用关系。理解分类是高效检索的前提。
3.2.1 系统日志：硬件与操作系统的“体检报告”
系统日志由Linux内核、systemd服务和底层驱动生成，主要记录硬件状态、内核事件、驱动加载、电源管理、温度阈值等信息。在旭日设备中，系统日志的典型内容包括：
- 内核日志（dmesg）：记录硬件探测、驱动初始化、内存映射、DMA错误等。例如，当NPU（神经网络处理单元）驱动加载失败时，dmesg中会出现“npu: probe of npu0 failed with error -22”之类的信息。
- 系统服务日志（journalctl）：记录systemd管理的服务启停、崩溃、看门狗触发等。旭日设备中的看门狗服务如果连续三次未收到心跳，会强制重启系统，这一事件必然记录在journalctl中。
- 硬件监控日志：包括温度传感器（/sys/class/thermal）、电压监控、风扇转速等。当设备在高温环境下运行，系统日志会周期性记录温度值，帮助判断是否触发降频保护。
系统日志的存储位置通常为/var/log/messages、/var/log/syslog以及journalctl管理的二进制日志。排查硬件类故障时，系统日志是首选入口。
3.2.2 应用日志：业务逻辑的“执行流水账”
应用日志由旭日设备上的业务进程（如视觉识别服务、通信网关、任务调度模块）产生，记录每一次业务操作的输入、输出、异常分支和耗时。应用日志的特点是语义丰富，直接反映业务状态。例如：
2025-06-18 10:23:45.678 INFO [TaskScheduler] [thread-12] [EVT_0231] 接收识别任务 task_id=8A3F2C, 输入图像尺寸=1920x1080, 通道=RGB
2025-06-18 10:23:45.682 WARN [TaskScheduler] [thread-12] [EVT_0234] 图像预处理耗时偏长, 耗时=45ms, 阈值=30ms
2025-06-18 10:23:45.690 ERROR [TaskScheduler] [thread-12] [EVT_0240] 模型推理超时, 预期=80ms, 实际=150ms, 任务ID=8A3F2C应用日志通常按天滚动写入/opt/旭日/app/log/目录，文件名包含日期后缀（如app-20250618.log）。在排查业务逻辑错误时，应用日志是主要依据。
3.2.3 模型日志：AI推理链路的“专用仪表”
模型日志是旭日设备区别于普通嵌入式设备的重要特征。它专门记录模型版本信息、推理输入输出、置信度分数、推理延迟、内存占用以及模型切换事件。模型日志的价值在于：
- 版本追溯：每次加载模型时，记录模型文件的MD5哈希值、模型名称、训练日期和部署时间。当现场出现识别效果下降时，可以快速确认当前运行的模型版本是否与预期一致。
- 性能监控：记录每次推理的耗时分布（预处理、NPU计算、后处理），帮助定位性能瓶颈。
- 异常检测：当模型输出的置信度持续低于阈值（如0.6），模型日志会记录告警，提示可能存在输入数据分布偏移或模型退化。
模型日志的存储路径为/var/log/旭日/model/，其中infer.log记录推理明细，version.json记录当前部署的模型版本清单。
| 日志类别 | 生成方 | 典型路径 | 主要关注点 | 排查场景 |
|---|---|---|---|---|
| 系统日志 | 内核/驱动/systemd | /var/log/messages, journalctl | OOM、I/O错误、硬件告警、驱动加载 | 设备重启、死机、外设无响应 |
| 应用日志 | 业务进程 | /opt/旭日/app/log/ | 超时、重试、协议错误、任务状态 | 业务中断、通信失败、任务异常 |
| 模型日志 | 推理引擎/模型服务 | /var/log/旭日/model/ | 推理延迟、置信度、版本哈希、内存占用 | 识别不准、性能下降、模型加载失败 |
3.3 日志级别：从DEBUG到FATAL的决策依据
日志级别定义了日志信息的重要性和紧急程度。旭日设备遵循标准的五级划分：DEBUG、INFO、WARN、ERROR、FATAL。正确理解级别含义，能帮助运维人员在海量日志中快速筛选关键信息。
- DEBUG（调试）：最详细的运行信息，包括变量值、函数入口出口、中间计算结果。生产环境默认关闭，仅在问题复现时临时开启。
- INFO（信息）：记录关键业务节点，如任务启动、任务完成、配置加载、模型切换。INFO日志用于还原正常业务流程。
- WARN（警告）：表示存在潜在风险，但当前功能仍可继续运行。例如，通信重试次数超过阈值、温度接近上限、推理耗时接近超时边界。
- ERROR（错误）：表示某个功能或模块执行失败，需要人工介入。例如，模型文件损坏、网络连接断开、图像采集失败。
- FATAL（致命）：表示系统级故障，通常伴随进程退出或系统重启。例如，内核panic、关键服务连续崩溃、看门狗触发。
3.4 日志格式规范：统一结构才能高效解析
旭日设备对日志格式有严格约定，所有日志必须遵循以下结构，以便于人工阅读和自动化采集：
时间戳 | 级别 | 模块名 | 线程ID | 事件ID | 描述信息各字段说明如下：
- 时间戳：格式为
yyyy-MM-dd HH:mm:ss.SSS，精确到毫秒。对于性能分析，毫秒级精度是必需的。 - 级别：五级枚举值，大写字母表示。
- 模块名：标识日志来源模块，如
CAM（相机）、NPU（神经网络处理器）、NET（网络通信）、SYS（系统管理）。 - 线程ID：十六进制或十进制线程标识，用于追踪并发场景下的执行顺序。
- 事件ID：预定义的事件编号，如
EVT_0012表示图像采集超时。事件ID便于建立日志与故障类型的映射关系。 - 描述信息：人类可读的详细说明，包含关键参数和上下文。
例如，一条标准的ERROR日志：
2025-06-18 10:23:45.678 | ERROR | CAM | 0x3F2A | EVT_0012 | 图像采集超时, 相机ID=0, 超时时间=200ms, 实际等待=350ms这种结构化格式不仅便于人工阅读，也方便使用grep、awk或日志采集工具（如Loki、ELK）进行自动化解析。
3.5 实战案例：一次“设备间歇性重启”的日志定位过程
某现场反馈，一台旭日设备在运行约2小时后会随机重启，重启后短时间内恢复正常，但故障会再次出现。工程师初步怀疑是电源问题或温度过高，但更换电源后故障依旧。以下是利用日志体系进行排查的完整过程。
第一步：收集三类日志。在设备重启前，通过远程连接导出journalctl -k（内核日志）、/opt/旭日/app/log/下的应用日志以及/var/log/旭日/model/infer.log。由于设备会重启，建议使用journalctl --since "2 hours ago"导出到U盘。
第二步：分析系统日志。在journalctl中发现重启前约30秒，有一条关键记录：
Jun 18 09:45:12 旭日-device kernel: [12345.678901] thermal thermal_zone0: critical temperature reached (85 C), shutting down这条日志表明系统因温度达到85°C的临界值而触发强制关机。但现场环境温度仅为28°C，为何设备内部温度会如此之高？继续查看温度监控历史，发现NPU区域温度在重启前10分钟内从60°C快速攀升至85°C。
第三步：交叉验证应用日志与模型日志。在应用日志中，发现重启前有大量EVT_0234（图像预处理耗时偏长）和EVT_0240（模型推理超时）记录。模型日志显示，推理延迟从正常的90ms逐步上升至180ms，且NPU利用率持续100%。结合系统日志的温度数据，可以判断：模型推理负载异常升高，导致NPU过热，触发系统保护性关机。
第四步：定位根因。进一步检查模型日志中的版本信息，发现当前运行的模型版本为v2.3.1，而前一天刚部署了v2.3.1。对比version.json中的MD5哈希，确认现场运行的模型文件与发布包一致。但查看推理输入图像尺寸，发现输入分辨率从默认的1280x720变成了1920x1080，导致NPU计算量增加约2.25倍。原来，现场人员在调试时修改了相机配置，将分辨率调高，但未同步评估模型推理性能。
第五步：解决方案与复盘。将相机分辨率恢复为1280x720后，设备运行稳定，温度回落至65°C以下。复盘经验：
- 模型日志中的性能指标（延迟、利用率）必须与系统日志中的温度数据联动分析，单一日志无法完整还原故障链路。
- 任何配置变更（如分辨率、帧率）都应先在小范围验证，并观察模型日志中的推理延迟变化。
- 建议在应用日志中增加“配置变更记录”事件，方便追溯现场人员的操作。
3.6 常见误区与总结复盘
在日志体系的实际应用中，运维人员常犯以下错误，需要特别注意规避：
- 误区一：只看ERROR和FATAL日志。很多故障在发生前会有大量WARN级别的预兆，例如重试次数增加、耗时逐渐变长。忽略WARN日志会错过最佳干预时机。
- 误区二：日志文件被覆盖后才发现未备份。旭日设备默认日志滚动策略为保留7天或50MB，对于需要长期追溯的场景，应配置日志持久化到外部存储。
- 误区三：时间戳不同步。如果设备未配置NTP时间同步，系统日志、应用日志和模型日志的时间戳可能出现偏差，导致交叉分析时无法对齐。建议在设备部署时强制启用NTP。
- 误区四：日志级别设置不当。将日志级别长期设置为DEBUG会导致日志量激增，影响设备性能；而设置为ERROR则可能丢失关键上下文。
总结而言，日志体系是旭日设备运维的基石。运维人员应建立“系统日志看硬件健康、应用日志看业务逻辑、模型日志看AI状态”的分类意识，并熟练掌握日志级别筛选和格式解析技巧。在实际排障中，务必坚持“先导日志、再分析、后操作”的原则，让日志成为现场问题定位的最可靠助手。