4、重启日志基础：日志类型、日志级别、日志格式与常见存储位置
端侧推理设备（如AI摄像头、边缘计算盒子、智能座舱域控制器）的watchdog触发重启后，第一手证据往往不是硬件信号，而是散落在系统各处的日志文件。日志是系统运行状态的“黑匣子”，但只有理解其类型、级别、格式与存储位置，才能从海量信息中快速定位“谁触发了重启”。本章将系统梳理端侧Linux/Android系统中的日志体系，为后续的watchdog日志分析打下基础。
4.1 日志类型：三类日志的分工与协作
端侧推理设备的日志体系可以划分为三个层次：内核日志、系统日志和应用日志。三者记录的内容不同、产生的主体不同、在watchdog重启分析中的价值也不同。
| 日志类型 | 产生主体 | 典型内容 | watchdog分析价值 |
|---|---|---|---|
| 内核日志 | Linux内核、设备驱动 | 驱动超时、硬件错误、内存不足、watchdog喂狗失败 | 最高——直接记录硬件级异常和内核panic |
| 系统日志 | init进程、系统服务、logd | 服务启动/停止、权限错误、系统属性变更 | 中高——还原重启前后的系统状态变化 |
| 应用日志 | 推理应用、业务进程 | 推理耗时、内存占用、业务异常、ANR | 中——定位应用层卡死或资源泄漏 |
在watchdog场景中，内核日志是“第一现场”，因为watchdog驱动本身运行在内核态。当用户态进程未能及时喂狗时，内核会记录一条类似 watchdog: watchdog0: watchdog did not stop! 的日志。而系统日志和应用日志则帮助我们理解“为什么没有喂狗”——是应用卡死、死锁，还是系统服务异常。
4.2 日志级别：从VERBOSE到FATAL的过滤逻辑
日志级别决定了信息的详细程度和筛选策略。在端侧设备中，常见的日志级别定义遵循Android logcat的优先级体系，同时也兼容Linux syslog的级别划分。
- VERBOSE (2)：最详细的调试信息，生产环境通常关闭，否则会严重影响性能。
- DEBUG (3)：调试信息，用于开发阶段，生产环境默认不输出。
- INFO (4)：常规运行信息，如“模型加载成功”“推理耗时12ms”。
- WARN (5)：警告，表示可能出现问题但不影响当前运行，如“内存使用率超过80%”。
- ERROR (6)：错误，功能不可用或数据异常，如“无法加载模型文件”。
- FATAL (7)：致命错误，进程即将退出，如“segmentation fault”。
- SILENT (8)：关闭所有日志。
在watchdog重启分析中，我们通常重点关注WARN及以上级别的日志。但需要注意：某些关键信息（如喂狗线程的启动）可能只记录在DEBUG级别，因此当怀疑喂狗逻辑本身有问题时，需要临时开启DEBUG级别日志进行复现。
INFO 作为默认级别，同时保留 WARN/ERROR/FATAL 的独立日志文件。这样既能保证性能，又能在故障时快速定位问题。对于watchdog相关日志，建议单独开启 DEBUG 级别并输出到独立文件。
4.3 日志格式：时间戳、进程号与线程号的关键作用
无论是Android的logcat还是Linux的syslog，日志格式都包含几个关键字段。理解这些字段是进行时间线分析的基础。
// Android logcat 典型格式
04-03 14:23:45.678 1234 5678 I Watchdog: Feeding watchdog, interval=5000ms
│ │ │ │ │ │ │
│ │ │ │ │ │ └── 日志内容
│ │ │ │ │ └── 日志标签(Tag)
│ │ │ │ └── 日志级别(Info)
│ │ │ └── 线程号(TID)
│ │ └── 进程号(PID)
│ └── 时间戳(月-日 时:分:秒.毫秒)
└── 日期
// Linux syslog 典型格式
Apr 3 14:23:45 edgebox kernel: [12345.678901] watchdog: watchdog0: timeout, resetting
│ │ │ │ │ │
│ │ │ │ │ └── 内核消息
│ │ │ │ └── 内核时间戳(系统启动后秒数)
│ │ │ └── 日志来源(kernel)
│ │ └── 主机名
│ └── 时间戳
└── 日期在watchdog分析中，时间戳是最重要的字段。特别是内核日志中的 [12345.678901] 格式，表示系统启动后的相对时间，这对于跨日志源对齐事件非常关键。例如，如果内核日志显示在 12345.678 秒时watchdog超时，而应用日志显示某个进程在 12345.500 秒时发生ANR，那么基本可以确定是ANR导致喂狗失败。
4.4 常见日志存储位置与获取方法
端侧设备的日志存储位置因操作系统和厂商定制而异，但存在一些通用路径。掌握这些路径，可以在设备重启后快速收集证据。
| 存储位置 | 内容 | 持久性 | 获取方式 |
|---|---|---|---|
/var/log/ |
系统服务日志、syslog | 重启后保留（若写入flash） | adb pull 或直接读取 |
/data/log/ |
Android系统日志、事件日志 | 重启后保留 | 需要root权限 |
/data/tombstones/ |
Native崩溃的调用栈 | 重启后保留 | 需要root权限 |
/sys/fs/pstore/ |
内核panic、watchdog复位前的最后日志 | 重启后保留（特殊文件系统） | 重启后立即读取 |
/proc/last_kmsg |
上次内核日志（部分内核支持） | 重启后保留 | 需要root权限 |
logcat -b all |
Android环形缓冲区日志 | 重启后丢失 | 重启前抓取 |
对于watchdog重启分析，/sys/fs/pstore/ 是最关键的路径。pstore（Persistent Store）是内核专门为崩溃场景设计的持久化存储，它使用NVRAM或保留内存区域，即使系统发生panic或硬件复位，其中的数据也不会丢失。在设备重启后，第一时间检查 /sys/fs/pstore/ 目录，通常能找到 console-ramoops 和 dmesg-ramoops 文件，其中记录了复位前最后的内核日志。
4.5 案例拆解：一次典型的watchdog重启日志分析
下面通过一个实际案例，演示如何综合运用三类日志定位watchdog重启的根因。
背景与约束：某智能摄像头设备（RK3588平台，Android 12系统）在连续运行约72小时后发生自动重启。设备部署在户外，无法现场调试，只能通过远程日志系统收集数据。已知设备运行着基于TensorFlow Lite的人脸检测模型，帧率要求15 FPS。
初始现象：设备在凌晨3:15左右重启，重启后业务恢复正常。远程日志系统只收集了系统日志和应用日志，未配置内核日志收集。
分析过程：
- 查看系统日志：在
/data/log/中找到重启前的系统日志，发现3:14:50时系统内存压力增大，多个后台服务被杀死（lowmemorykiller触发）。 - 查看应用日志：在应用日志中发现3:14:45时人脸检测进程发生ANR，日志显示“Input dispatching timed out”，主线程无响应。
- 查看pstore：由于设备已重启，立即通过远程命令读取
/sys/fs/pstore/，在console-ramoops中找到内核日志，显示3:14:52时watchdog驱动记录“watchdog0: timeout, resetting”。 - 时间线对齐：将三类日志按时间排列，发现ANR发生在watchdog超时前7秒，内存压力发生在ANR前5秒。
根因判断：内存压力导致系统频繁进行内存回收，人脸检测进程的主线程在等待内存分配时被阻塞超过5秒，触发ANR。ANR导致主线程无法执行喂狗操作，watchdog在超时后触发硬件复位。
解决方案：优化推理进程的内存占用（将输入图像分辨率从1080P降至720P），同时调整lowmemorykiller的白名单，避免关键进程被误杀。修改后设备连续运行14天未再重启。
4.6 常见误区与总结
在日志基础分析中，工程师常犯以下错误：
- 只关注应用日志：忽略内核日志，导致无法确认是否真的发生了watchdog复位。
- 混淆时间戳：使用系统时间而非内核相对时间进行事件对齐，在NTP跳变时产生错误结论。
- 忽略日志级别：默认级别设置过高，导致关键DEBUG信息缺失，无法定位喂狗线程的具体行为。
- 未配置pstore：设备重启后无法获取内核最后日志，只能靠推测。
- 日志存储空间不足：日志文件写满后覆盖早期关键信息，建议配置日志轮转和远程上传。
总结：日志是watchdog重启分析的基础，但只有理解三类日志的分工、掌握级别过滤逻辑、熟悉格式字段、知道存储位置，才能在故障发生时快速、准确地提取证据。建议在设备部署阶段就完成日志体系的规划，包括级别设置、存储路径、轮转策略和远程收集机制，为后续的故障排查打下坚实基础。