产品需求文档：车载日志限流稽查系统 V1.0
| 文档版本 | 修订日期 | 修订人 | 修订内容 |
|---|---|---|---|
| V1.0 | 2026-04-13 | --- | 初稿 |
1. 概述
1.1 背景与问题
本项目运行于 Android + QNX + VIP 架构的汽车电子系统上。售后问题分析时，常因日志滚动覆盖导致关键时段日志丢失，无法形成完整的分析闭环。
根本原因在于：
- 磁盘日志采用固定大小循环覆盖策略，无统一限流规范。
- 部分进程在特定阶段疯狂刷屏，导致原本可保存4天的日志量在3小时内就被覆盖。
1.2 项目目标
- 建立可落地的日志打印限流规范，约束各进程在量产版本（user）下的日志行为。
- 实现一套轻量级、低侵入的稽查体系，包含实时告警与事后深度分析，自动发现违反规范的进程。
- 提升有效日志保留时长，确保售后问题具备可追溯的日志数据。
1.3 设计原则
| 原则 | 说明 |
|---|---|
| 最小化稽查场景 | 仅关注影响稳态日志保留的核心场景，非稳态场景（如OTA）予以豁免。 |
| 极简实时，精确事后 | 实时稽查只做简单计数与分级告警，复杂场景判定留给事后Python工具。 |
| 零侵入/低侵入 | 不修改Android logd、QNX slog2等现有日志框架，只通过旁路读取日志流。 |
| 配置驱动 | 所有场景锚点、阈值、豁免规则均通过JSON配置文件管理，便于调优和移植。 |
1.4 术语定义
| 术语 | 定义 |
|---|---|
| Case / 场景 | 系统所处的特定运行阶段，如冷启动、STR唤醒、正常工作等。 |
| 锚点日志 | 用于标识场景开始或结束的特定日志（通过TAG和正则匹配）。 |
| 滑动窗口 | 稽查统计的最小时间单位，固定为 1分钟。 |
| SEVERE告警 | 日志条数 ≥ 30条/分钟，需立即上报云端错误码。 |
| WARNING告警 | 日志条数介于 10~29条/分钟，仅记录在本地，供事后分析。 |
| EXEMPT状态 | 免稽核状态，处于该状态的时间段内不进行任何日志限流统计。 |
2. 日志规范
2.1 版本与日志级别策略
| 版本类型 | 默认输出级别 | 适用环境 |
|---|---|---|
| user-debug | DEBUG | 开发调试、预生产测试 |
| user（量产） | INFO | 用户交付版本 |
说明 ：本规范仅约束
user量产版本的日志行为，user-debug版本不受限。
2.2 稽查场景定义
经过筛选，仅定义以下四个核心状态，覆盖系统全部运行时间。
| 状态ID | 名称 | 定义 | 进入条件 | 退出条件 |
|---|---|---|---|---|
BOOT |
启动阶段 | 系统启动或唤醒后的短暂初始化窗口 | 检测到冷启动或STR唤醒锚点 | 持续 2分钟 后自动退出 |
NTP |
时钟同步阶段 | 网络时钟首次同步成功后的窗口 | 检测到NTP同步成功锚点 | 持续 3分钟 后自动退出 |
EXEMPT |
免稽核状态 | 特殊场景（OTA等），不进行限流稽查 | 检测到任一免稽核场景的开始锚点 | 检测到对应结束锚点 或 超时兜底 |
NORMAL |
正常工作阶段 | 上述状态之外的所有运行时间 | BOOT/NTP窗口结束，或EXEMPT结束 |
直到下一个状态锚点触发 |
状态优先级（同时满足多个状态条件时，取最高优先级） ：
EXEMPT > BOOT > NTP > NORMAL
2.3 场景限流阈值表
| 状态 | 适用窗口 | 日志条数限制 | 备注 |
|---|---|---|---|
BOOT |
2分钟窗口内累计 | ≤ 200条 | 启动阶段总计不超过200条（约100条/分钟） |
NTP |
3分钟窗口内累计 | ≤ 300条 | 时钟同步阶段总计不超过300条（约100条/分钟） |
NORMAL |
每1分钟滑动窗口 | 严重阈值 ≥ 30条/分钟 警告阈值 ≥ 10条/分钟 | 核心稽查窗口，按分钟滚动统计 |
EXEMPT |
--- | 不限制 | 免稽核时段，不进行任何统计 |
关于日志长度 ：本期暂不实施单条长度稽查。该功能作为事后工具的可选特性 （通过
--check-length开启），仅输出超长日志样例供人工审查。
2.4 不纳入稽查的场景及处理策略
| 场景 | 处理策略 | 理由 |
|---|---|---|
| 进程崩溃/ANR | 正常稽查，不豁免 | 崩溃前后高频日志是定位问题的重要线索，告警有助于快速发现 |
| OTA升级 | 纳入EXEMPT状态，实时稽查启用豁免 |
偶发但日志量巨大，避免误报干扰运维 |
| Monkey测试 | 纳入EXEMPT状态，仅事后工具豁免 |
仅测试环境触发，量产环境无需实时豁免 |
| EOL/工厂模式 | 纳入EXEMPT状态，仅事后工具豁免 |
产线专用场景，量产车辆不会进入 |
3. 关键日志锚点清单（Checklist配置）
3.1 配置文件格式
稽查工具通过读取JSON配置文件获取所有场景的锚点定义和阈值参数。
配置文件结构：
css
{
"version": "1.0",
"cases": {
"boot": { ... },
"ntp": { ... },
"normal": { ... }
},
"exempt_scenes": [ ... ]
}3.2 稽查场景锚点定义
| 场景ID | 字段 | 说明 | 示例值（待研发补充） |
|---|---|---|---|
boot |
cold_boot_anchor_android |
Android冷启动完成锚点 | {"tag":"ActivityManager","pattern":"boot_completed"} |
boot |
cold_boot_anchor_qnx |
QNX冷启动完成锚点 | {"tag":"boot","pattern":"startup complete"} |
boot |
str_resume_anchor_android |
Android STR唤醒锚点 | {"tag":"PowerManagerService","pattern":"wakeup"} |
boot |
str_resume_anchor_qnx |
QNX STR唤醒锚点 | {"tag":"pm","pattern":"str_resume"} |
boot |
duration_seconds |
启动窗口持续时长 | 120 |
boot |
limit_total |
窗口内总条数上限 | 200 |
ntp |
sync_anchor_android |
Android NTP同步成功锚点 | {"tag":"NtpTrustedTime","pattern":"ntp_sync_success"} |
ntp |
sync_anchor_qnx |
QNX NTP同步成功锚点 | {"tag":"time","pattern":"clock synchronized"} |
ntp |
duration_seconds |
同步窗口持续时长 | 180 |
ntp |
limit_total |
窗口内总条数上限 | 300 |
normal |
severe_threshold_per_min |
严重告警阈值（条/分钟） | 30 |
normal |
warning_threshold_per_min |
警告告警阈值（条/分钟） | 10 |
3.3 免稽核场景锚点定义
| 场景ID | 字段 | 说明 | 示例值（待研发补充） | 实时启用 |
|---|---|---|---|---|
ota |
start_anchor_android |
OTA开始锚点 | {"tag":"update_engine","pattern":"start OTA"} |
✅ 是 |
ota |
end_anchor_android |
OTA结束锚点 | {"tag":"update_engine","pattern":"OTA completed"} |
✅ 是 |
ota |
timeout_minutes |
超时兜底时长 | 60 |
✅ 是 |
monkey |
start_anchor_android |
Monkey开始锚点 | {"tag":"monkey","pattern":"start"} |
❌ 否 |
monkey |
end_anchor_android |
Monkey结束锚点 | {"tag":"monkey","pattern":"finish"} |
❌ 否 |
monkey |
timeout_minutes |
超时兜底时长 | 120 |
❌ 否 |
eol |
start_anchor_android |
工厂模式进入锚点 | {"tag":"FactoryMode","pattern":"enter"} |
❌ 否 |
eol |
end_anchor_android |
工厂模式退出锚点 | {"tag":"FactoryMode","pattern":"exit"} |
❌ 否 |
eol |
start_anchor_qnx |
QNX工厂模式进入锚点 | {"tag":"factory_mode","pattern":"enter"} |
❌ 否 |
eol |
end_anchor_qnx |
QNX工厂模式退出锚点 | {"tag":"factory_mode","pattern":"exit"} |
❌ 否 |
eol |
timeout_minutes |
超时兜底时长 | 30 |
❌ 否 |
待办项 ：请各域（Android、QNX）负责人确认并补充上述锚点的确切TAG和日志内容正则表达式。
4. 稽查体系设计
4.1 统一状态机算法（事后工具核心）
事后稽查Python工具通过解析日志流、识别锚点来维护状态机，并统计各进程的日志条数。
状态转换图：
scss
系统启动 → BOOT(2min) → NORMAL ←─────────────────┐
↑ │
│ │
┌───────────┼───────────┐ │
↓ ↓ ↓ │
检测到NTP 检测到EXEMPT 检测到STR │
↓ 开始锚点 ↓ │
NTP(3min) EXEMPT BOOT(2min) │
↓ ↓ ↓ │
NORMAL 检测到结束锚点 NORMAL │
或超时兜底 │
↓ │
NORMAL ────────────────────┘算法伪代码：
ini
state = "BOOT" # 初始状态
state_expire_time = first_log_time + 120s
exempt_scene = None # 当前是哪个免稽核场景
for log in log_stream:
current_time = log.timestamp
# 1. 检查锚点，触发状态切换
if match_exempt_start(log):
state = "EXEMPT"
exempt_scene = get_scene_name(log)
exempt_expire_time = current_time + scene.timeout
elif state == "EXEMPT" and match_exempt_end(log, exempt_scene):
state = "NORMAL"
elif match_boot_anchor(log) and state_priority("BOOT") > state_priority(state):
state = "BOOT"
state_expire_time = current_time + 120s
elif match_ntp_anchor(log) and state_priority("NTP") > state_priority(state):
state = "NTP"
state_expire_time = current_time + 180s
# 2. 检查超时退出
if state in ("BOOT", "NTP") and current_time > state_expire_time:
state = "NORMAL"
if state == "EXEMPT" and current_time > exempt_expire_time:
state = "NORMAL"
# 3. 统计（EXEMPT状态下跳过统计）
if state != "EXEMPT":
minute_bucket = get_minute_bucket(current_time)
proc_stats[log.pid][minute_bucket] += 1
# 4. 最后按场景阈值判定违规
for proc, buckets in proc_stats:
for bucket, count in buckets:
scene = get_scene_at_time(bucket)
if count > scene.limit:
violations.append(...)4.2 实时稽查守护进程（轻量级）
部署位置：Android系统服务 / QNX后台进程。
输入 ：logcat -v threadtime 或 slog2info 管道流。
核心逻辑（极简版）：
markdown
1. 维护一个按PID分组的1分钟滑动窗口计数器。
2. 实时状态机仅维护 "EXEMPT" 和 "NORMAL" 两种状态（因为量产环境只关心OTA豁免）：
- 检测到OTA开始锚点 → 进入EXEMPT，暂停统计。
- 检测到OTA结束锚点 或 超时60分钟 → 退出EXEMPT，恢复统计。
3. 在NORMAL状态下，每过1分钟检查每个进程的窗口计数：
- count >= 30 → 上报SEVERE告警错误码
- 30 > count >= 10 → 写入本地WARNING日志（不上报）
- count < 10 → 无动作
4. 每分钟窗口结束时，重置计数器。上报错误码定义：
| 错误码 | 含义 | 携带信息 |
|---|---|---|
0xE0010001 |
进程日志严重超标（≥30条/分钟） | 时间戳、进程名、PID、实际条数 |
性能约束：
- 内存占用：< 2MB（仅存储当前分钟内的进程计数器）。
- CPU占用：单核 < 1%（只做简单计数和字符串匹配）。
- 日志管道读取采用非阻塞方式，避免影响系统。
4.3 事后稽查Python工具
输入：
- 日志压缩包（支持.zip/.tar.gz），内含Android logcat文件、QNX slog2文件、VIP日志文件。
- 配置文件
checklist.json。
处理流程：
- 解压与合并：解压所有日志文件，按时间戳将多源日志合并为统一的时间序列。
- 时间校准：识别NTP同步锚点，锚点之前的日志使用相对时间（以第一条日志为0），锚点之后使用绝对时间。
- 状态机分析：遍历合并后的日志流，运行状态机（见4.1节），标记每分钟所属场景及是否豁免。
- 违规统计：对非豁免时段，按分钟/进程聚合日志条数，与对应场景阈值比对，生成违规记录。
- 报告生成：输出CSV明细报告和HTML可视化报告。
命令行接口：
css
python log_checker.py --input <log_dir_or_zip> --config checklist.json [--output report_dir] [--check-length]输出报告示例：
- CSV明细 ：
进程名,违规场景,违规时间,实际条数/分钟,阈值,备注 - HTML报告：包含超标趋势折线图、Top10超标进程柱状图、违规明细表。
好的，我在PRD文档基础上，为您补充架构框图、时序图、状态机和流程图。这些图表能够更直观地呈现系统设计与运行逻辑。
4.4 系统架构框图
系统由数据源层 、实时稽查层 、云端告警层 和事后分析层四部分组成。
scss
┌─────────────────────────────────────────────────────────────────────────────┐
│ 【车端】 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Android │ │ QNX │ │ VIP │ │
│ │ logcat │ │ slog2 │ │ 日志文件 │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ └──────────────────┼──────────────────┘ │
│ │ (管道流 / 文件) │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 实时稽查守护进程 (Android服务 / QNX进程) │ │
│ │ ┌─────────────────┐ ┌─────────────────┐ ┌──────────────┐ │ │
│ │ │ 日志解析与过滤 │─▶│ 状态机(EXEMPT/ │─▶│ 分钟级计数器 │ │ │
│ │ │ (TAG正则匹配) │ │ NORMAL) │ │ (按PID分组) │ │ │
│ │ └─────────────────┘ └─────────────────┘ └──────┬───────┘ │ │
│ │ │ │ │
│ │ 阈值比对 (≥30条/min ?) │ │ │
│ └────────────────────────────────────────────────────┼──────────┘ │
│ │ │
└───────────────────────────────────────────────────────┼───────────────────────┘
│ 上报错误码
▼
┌─────────────────────┐
│ 云端后台 │
│ (告警接收/去重/工单) │
└─────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ 【离线分析】 │
│ ┌─────────────────┐ │
│ │ 日志压缩包 │ (Android/QNX/VIP) │
│ │ (售后拉取) │ │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 事后稽查 Python 工具 │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ │
│ │ │ 解压合并 │─▶│ 时间校准 │─▶│ 状态机 │─▶│ 分钟切片统计 │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ └──────┬───────┘ │ │
│ │ │ │ │
│ │ ┌──────────┐ ┌──────────┐ │ │ │
│ │ │ 违规判定 │◀─│ 阈值比对 │◀─┘ │ │
│ │ └────┬─────┘ └──────────┘ │ │
│ └─────────────────────────────┼─────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────────┐ │
│ │ 分析报告 │ │
│ │ CSV / HTML 可视化 │ │
│ └────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘4.5 实时稽查时序图
以下时序图展示了守护进程在处理日志流时的核心交互逻辑。
scss
┌────────┐ ┌─────────────┐ ┌──────────────┐ ┌────────┐
│ logcat │ │ 守护进程 │ │ 状态机 │ │ 云端 │
│/slog2 │ │ (主循环) │ │ (EXEMPT/NORMAL)│ │ 后台 │
└───┬────┘ └──────┬──────┘ └──────┬───────┘ └───┬────┘
│ │ │ │
│ 日志行(持续流) │ │ │
│────────────────▶│ │ │
│ │ │ │
│ │ 解析TAG/内容 │ │
│ │──────────────────▶│ │
│ │ │ │
│ │ 是否OTA开始锚点? │ │
│ │──────────────────▶│ │
│ │ │ │
│ │ 是 │ │
│ │◀─────────────────│ 进入EXEMPT状态 │
│ │ │ │
│ │ 后续日志行到达 │ │
│ │──────────────────▶│ │
│ │ │ (豁免,不统计) │
│ │ │ │
│ │ 是否OTA结束锚点? │ │
│ │──────────────────▶│ │
│ │ │ │
│ │ 是 │ │
│ │◀─────────────────│ 回到NORMAL状态 │
│ │ │ │
│ │ 1分钟定时器触发 │ │
│ │──────────────────▶│ │
│ │ │ │
│ │ 获取各进程计数 │ │
│ │──────────────────▶│ │
│ │ │ │
│ │ count >= 30 ? │ │
│ │──────────────────▶│ │
│ │ │ │
│ │ │ 是, 生成SEVERE告警 │
│ │ │──────────────────▶│
│ │ │ │
│ │ │ │ 错误码0xE0010001
│ │ │ │────────────▶│
│ │ │ │ │
│ │ 10 <= count < 30?│ │ │
│ │──────────────────▶│ │ │
│ │ │ │ │
│ │ │ 记录本地WARNING │ │
│ │ │ (不上报) │ │
│ │ │ │ │4.6 状态机转换图
按照PRD定义的状态优先级，状态机转换规则如下（箭头上的文字表示转换条件）。
scss
┌─────────────────────────────────────────┐
│ │
▼ │
┌──────────┐ │
│ BOOT │ (系统启动 / STR唤醒) │
│ 持续2分钟 │ │
└────┬─────┘ │
│ │
2分钟超时 ──────┼────────────────────┐ │
│ │ │
▼ │ │
┌──────────┐ │ │
│ NORMAL │◀─────────────┼───────┐ │
│ (默认状态)│ │ │ │
└────┬─────┘ │ │ │
│ │ │ │
│ │ │ │
┌────────────────────┼────────────────────┼───────┼────────────┼───┐
│ │ │ │ │ │
▼ ▼ ▼ │ │ │
┌────────────┐ ┌────────────┐ ┌────────────┐│ │ │
│ 检测到NTP │ │检测到EXEMPT │ │ 检测到STR ││ │ │
│ 同步锚点 │ │ 开始锚点 │ │ 唤醒锚点 ││ │ │
└─────┬──────┘ └─────┬──────┘ └─────┬──────┘│ │ │
│ │ │ │ │ │
▼ ▼ │ │ │ │
┌────────────┐ ┌────────────┐ │ │ │ │
│ NTP │ │ EXEMPT │ │ │ │ │
│ 持续3分钟 │ │ (免稽核状态)│ │ │ │ │
└─────┬──────┘ └─────┬──────┘ │ │ │ │
│ │ │ │ │ │
│ 3分钟超时 │ 检测到结束锚点 │ │ │ │
│ │ 或超时兜底 │ │ │ │
└──────────┬─────────┘ │ │ │ │
│ │ │ │ │
└──────────────┬───────────────┘ │ │ │
│ │ │ │
▼ │ │ │
回到 NORMAL ───────────────────┘ │ │
│ │
│ │
优先级规则: EXEMPT > BOOT > NTP > NORMAL │ │
(若同时满足多个状态进入条件，按优先级取最高者) │ │
│ │
说明: BOOT、NTP、EXEMPT状态期间，若检测到更高优先级状态的进入锚点， │ │
则立即切换到高优先级状态。例如NORMAL下检测到OTA开始锚点， │ │
则进入EXEMPT。EXEMPT期间检测到BOOT锚点，则保持EXEMPT不变。 │ │4.7 事后稽查工具处理流程图
展示Python离线分析工具的内部处理步骤。
scss
┌─────────────────────┐
│ 开始 │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ 1. 加载配置文件 │
│ (checklist.json) │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ 2. 解压日志包 │
│ (支持.zip/.tar.gz) │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ 3. 读取并解析各源日志 │
│ - Android logcat │
│ - QNX slog2 │
│ - VIP 自定义格式 │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ 4. 多源日志合并排序 │
│ (按时间戳统一) │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ 5. 时间校准处理 │
│ (寻找NTP锚点， │
│ 前段用相对时间) │
└──────────┬──────────┘
│
▼
┌─────────────────────────────────────────┐
│ 6. 状态机遍历 (逐行处理) │
│ ┌─────────────────────────────────┐ │
│ │ 6.1 匹配锚点 → 切换状态 │ │
│ │ 6.2 检查超时 → 退出状态 │ │
│ │ 6.3 若状态 != EXEMPT: │ │
│ │ 按分钟/PID累加日志计数 │ │
│ └─────────────────────────────────┘ │
└──────────┬──────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ 7. 违规判定 │
│ ┌─────────────────────────────────┐ │
│ │ 对每一分钟/每个进程: │ │
│ │ - 获取该时刻所处场景的阈值 │ │
│ │ - 比较实际计数与阈值 │ │
│ │ - 记录违规条目 │ │
│ └─────────────────────────────────┘ │
└──────────┬──────────────────────────────┘
│
▼
┌─────────────────────┐
│ 8. 生成报告 │
│ - CSV明细表 │
│ - HTML可视化 │
│ - 统计摘要 │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ 结束 │
└─────────────────────┘4.8 场景识别与违规判定示例（补充说明图）
以下示例说明事后工具如何通过状态机正确判定违规。
less
时间轴 ──────────────────────────────────────────────────────────────────────▶
日志流: [开机日志]...[boot_completed]...[网络流量]...[OTA start]...[OTA end]...[正常日志]
状态: ├─ BOOT(2min) ─┤├─────── NORMAL ───────┤├─ EXEMPT(OTA) ─┤├─ NORMAL ─┤
统计窗口: [窗口1] [窗口2] [窗口3] [窗口4] [窗口5] [窗口6] [窗口7] [窗口8] [窗口9]
(豁免) (豁免) (正常) (正常) (正常) (豁免) (豁免) (正常) (正常)
进程A日志计数:
窗口1: 150条 (在BOOT内, 200条总限额内, 合规)
窗口3: 35条 (在NORMAL内, >30条阈值, 判定违规)
窗口4: 15条 (在NORMAL内, 10-30条区间, 警告)
窗口6: 200条 (在EXEMPT内, 豁免, 不判定)
窗口8: 5条 (在NORMAL内, 合规)
最终违规报告:
- 进程A, 窗口3时段, 35条/分钟, 违规(SEVERE)
- 进程A, 窗口4时段, 15条/分钟, 警告(WARNING)5. 实施与推行计划
5.1 阶段规划
| 阶段 | 任务内容 | 责任方 | 交付物 | 预估周期 |
|---|---|---|---|---|
| Phase 1 | 锚点日志确认 | Android/QNX/VIP研发 | 补充完整的checklist.json配置文件 |
1周 |
| Phase 2 | 实时稽查守护进程开发与集成 | 系统层研发 | Android服务APK / QNX可执行程序 | 3周 |
| Phase 3 | 事后稽查Python工具开发 | 工具开发组 | Python脚本及使用文档 | 2周 |
| Phase 4 | 试运行与阈值调优 | 测试/运维 | 阈值优化建议报告 | 2周（与Phase2/3并行） |
5.2 验收标准
| 验收项 | 验收标准 |
|---|---|
| 实时稽查 | 量产车辆OTA期间无SEVERE误报；正常行驶时，前台高频日志（如导航语音）能正确触发SEVERE告警。 |
| 事后稽查 | 输入已知违规日志包，工具能准确识别违规进程、场景及超标数值，报告数据可复现。 |
| 日志有效时长 | 部署稽查体系后，典型用户场景下磁盘日志保留时长提升至 ≥ 72小时（需基线对比）。 |
6. 附录
6.1 告警错误码定义表
| 错误码 | 级别 | 描述 |
|---|---|---|
0xE0010001 |
SEVERE | 进程在过去1分钟内打印超过30条日志（正常工况） |
| --- | WARNING | 进程在过去1分钟内打印10-29条日志（仅本地日志，不上报） |
6.2 静态白名单扩展规划（V2.0待办）
后续版本可根据实际数据，为特定高频进程（如地图引擎、语音识别）配置更高的告警阈值，避免误报。配置文件增加whitelist字段：
json
"whitelist": [
{"proc_name": "com.xxx.navigation", "severe_threshold": 60}
]6.3 常见问题与排查指南
| 问题现象 | 可能原因 | 排查方法 |
|---|---|---|
| 实时稽查无任何告警 | 守护进程未启动或管道读取失败 | 检查进程存活状态，查看本地WARNING日志 |
| 事后工具解析失败 | 日志格式不兼容 | 检查工具日志错误输出，确认日志格式版本 |
| OTA期间仍收到SEVERE告警 | OTA锚点未匹配成功 | 确认OTA开始/结束日志TAG是否与配置文件一致 |