自动化审计核心在于结构化采集与关联分析，需聚焦采什么、如何结构化、怎样关联行为，通过json日志解析、k8s元信息打标、轻量规则引擎及合规生命周期管理实现可查询、可标记、可回溯的审计线索。
直接用日志收集插件做自动化审计，关键不是“能不能”，而是“采什么、怎么结构化、怎么关联行为”。核心在于把容器 stdout/stderr 和关键日志文件变成可查询、可标记、可回溯的审计线索，而不是堆日志。
明确审计目标，反向定义采集字段
审计不是记录所有输出，而是聚焦可验证的操作痕迹。比如：
- 用户操作类：API 请求路径、请求 ID、响应状态码、客户端 IP、认证主体（如 JWT 中的 sub 字段）
- 系统变更类：配置热更新事件、服务注册/下线、数据库连接池重置
- 异常信号类：未捕获异常堆栈前 3 行、超时告警标记（如 “timeout=3000ms”）、重试次数 ≥3 的日志行
采集时需提前约定日志格式（推荐 JSON），并在插件中启用解析器提取上述字段。例如 Fluent Bit 配置中启用 Parser docker 或自定义正则，避免后期靠关键词模糊匹配。
用标签体系打通容器上下文与业务语义
单条日志脱离 Pod、Namespace、Deployment 等元信息就失去审计价值。插件必须自动注入 Kubernetes 标签：
- 通过 DaemonSet 模式部署的采集器，天然可读取宿主机上
/var/log/pods/下的路径，从中提取namespace、pod_name、container_name - 在采集配置中显式添加
Tag或Labels字段，例如：Label namespace ${kubernetes['namespace_name']} - 对关键业务容器，在 Deployment YAML 中加注解，如
audit.k8s.io/category: "payment"，插件按注解动态打标
这样一条日志入库后，就自带“谁（Pod）、在哪（Namespace）、干了啥（结构化字段）、属于哪类业务（Label）”四维信息，审计时可直接组合过滤。
设置轻量级规则引擎，实现日志即策略
真正自动化审计不依赖人工看板，而是靠规则触发动作。主流插件（如 Fluent Bit + Lua 过滤、或阿里云 SLS 的加工规则）支持在采集链路中嵌入逻辑：
- 识别高危操作：日志含
"DELETE /api/v1/users/"且status_code == 200→ 自动打标audit_risk: high - 发现异常模式：1 分钟内同一
request_id出现 ≥5 次"500 Internal Server Error"→ 触发告警并归档上下文日志 - 补全缺失字段：若日志无
user_id，但含trace_id，可调用轻量 API 关联调用链查出归属用户
这些规则写在采集端，不增加存储负担，也避免把原始日志全量送入分析平台后再计算，响应更快、更可控。
对接审计留存要求，控制生命周期
合规审计不是“存得越多越好”，而是“该留的留得住、该删的删得净”：
- 对标注为
audit_critical的日志，设置独立索引或 Logstore，保留期 ≥180 天（满足多数行业基线） - 普通运行日志使用滚动策略：单个文件 ≤10MB，最多保留 7 个副本，防止磁盘耗尽影响容器运行
- 敏感字段（如手机号、token）必须在采集插件层脱敏，例如用正则替换
""phone":"1[3-9]\d{9}"→""phone":"1****5678"，而非依赖下游处理
不建议靠事后脚本清理，而应在插件配置中声明 retention 和 filter，让审计数据从源头就符合治理要求。
