工作原理
当受保护的操作发生时，服务生成结构化事件并写入持久、只追加的存储。一条合格记录包含稳定的操作者标识、动作、目标、结果、同步时钟时间戳，以及 request id 或 trace id。
{"event_id":"01J9Z6","ts":"2026-10-20T08:15:02Z","actor":"user:4821","action":"role.grant","target":"project:918","outcome":"success"}管道应加入序号或哈希链，使缺口和篡改可被检测；事件经专用队列进入对象锁或账本等一次写入存储，并建立调查所需索引。
使用场景与取舍
登录、权限变更、敏感数据访问、导出、计费、密钥和配置变更都应产生审计事件。与普通应用日志相比，审计日志量更小、模式更严格、访问控制更严、保留更久；与分布式追踪相比，它回答“谁做了什么”，而不是请求耗时花在哪里。
不可变性和长期保留会增加成本并复杂化删除义务；记录更多上下文有利于调查，却也可能存入个人数据。同步写入会增加延迟，应通过持久队列缓冲而不是丢事件，并确保审计存储不随应用账号一起被攻破。
具体示例
管理员在 08:15 授予角色，事件记录操作者、动作、目标和成功结果。审计人员之后按目标过滤，就能重建该项目所有权限变更，包括十分钟前一次被拒绝的尝试。审计日志应与业务变更同样受保护和评审。