审计日志概述

审计日志，说白了就是记录系统里发生了什么事的流水账。每条日志回答三个问题：谁在什么时间，对什么资源，做了什么操作。你可能觉得这玩意儿就是个记录，没啥大不了。但我告诉你，一旦出了安全事故或者合规审计，审计日志就是你的第一道防线。

我在项目中遇到过好几次，线上出了故障，查了半天找不到根因。最后翻出审计日志，才发现是某个定时任务在错误的时间改了配置。从那以后，我对审计日志的重视程度直接拉满。

审计日志的作用

审计日志不只是简单的记录，它有四个核心作用：

• 责任追溯 —— 出了问题能定位到具体的人、时间、操作。
• 合规证明 —— 像金融、医疗行业，法规要求保留操作记录。
• 安全检测 —— 异常行为模式可以通过日志分析提前发现。
• 系统调试 —— 复杂故障排查时，日志比任何监控指标都更细粒度。

举个例子，我见过的银行核心系统，每天产生上亿条审计日志。如果没有审计日志，别说溯源，连谁在查询客户隐私数据都说不清。

常见应用场景

审计日志遍布所有关键系统，我把最常见的场景列出来：

你看，每个场景对日志的字段要求都不太一样。但有一点是共通的：日志量巨大，必须高效存储和查询。这就是这门课要解决的核心问题。

核心挑战

说到挑战，我踩过的坑还真不少。审计日志的存储和索引主要面临四个麻烦：

1. 写放大 —— 审计日志写入频繁，索引越多写入性能越差。我曾见过一个系统，给日志表建了六个索引，结果写入延迟从5ms飙升到500ms。
2. 存储成本 —— 日志保留周期长（通常半年甚至三年），数据量呈线性增长。按单机磁盘价格算，上亿条日志可能需要TB级存储。
3. 查询慢 —— 审计查询往往是范围扫描（某用户某时间段的所有操作）。如果不做分区和索引优化，一次查询可能扫全表，几分钟出不来结果。
4. 一致性保证 —— 审计日志不能丢，也不能乱序。但高性能写入往往需要牺牲部分事务能力，得在性能和安全之间找平衡。

那么，怎么解决这些挑战？关键在于索引策略。但索引不是越多越好，也不是越少越好。得根据查询特征、写入压力和硬件限制来设计。这门课后面会一步步带你拆解。

审计日志系统的整体视图

为了让你更直观地理解审计日志的完整链路，我画了一张结构图。它展示了从日志产生到最后查询的全流程，以及每个环节的存储和索引要点。