审计日志的五要素：谁、何时、何地、何事、结果
做审计日志这么多年，我经常被问到同一个问题——"日志到底该记什么？"
其实答案很简单，就五个词：谁、何时、何地、何事、结果。圈内管这叫5W框架，也有人叫它审计轨迹五要素。你想想看，不管多复杂的系统，不管日志格式多花哨，最后拆到根上，核心就是这五样。
今天我就把这五样东西掰开揉碎讲清楚。每个要素我会结合实际案例，让你不光知道"要记什么"，还知道"为什么要记这个"。来吧，咱们一个一个看。
核心理念：审计日志不是垃圾堆，不是把所有能捞的数据全扔进去就行。五要素就像一个人的"数字身份证"——少了任何一样，溯源就会断掉。
1. 谁（Who）—— 主体标识
说白了，就是"谁干了这事"。听起来简单吧？但我在项目中遇到过不少翻车现场——有的系统只记了用户名，没记用户类型；有的只记了IP，没记具体账号。
一个完整的"谁"，起码要包含这几样：
- 用户ID或账号名：系统内的唯一标识。我见过只用中文名的，后面用户改名或重名，查都查不清。
- 用户类型：是普通用户、管理员还是系统服务账号？这个不区分，后面权限审计就没法做。
- 认证方式：是密码登录、SSO单点登录还是？嗯，这个在安全事件溯源时特别有用。
Tips：我个人习惯在日志里额外加一个 session_id，同一个会话的所有操作串起来，查问题能省一半时间。
2. 何时（When）—— 时间戳
时间戳这个事，看着简单，坑其实最多。
之前帮一家金融客户做合规审计，发现他们的日志时间前后差了8个小时——因为有的服务用UTC，有的用东八区，还有的压根没配时区。你想想看，一个攻击事件发生了，你按时间轴去串日志，结果时间对不上，那还查什么？
关于"何时"，我建议你记住三个要点：
- 统一使用UTC存储：展示时再转本地时间。这是行业铁律，别打破它。
- 精度要够：大部分场景用毫秒级就够了。高频交易场景可能需要微秒甚至纳秒，但普通业务系统别瞎跟风——精度越高，存储成本越大。
- 带上时区偏移：比如
2025-06-15T14:30:00.000+08:00，这比单纯一个时间戳可靠得多。
踩坑提醒：我曾经碰到过一个系统，时间戳用的是服务器本地时间，结果服务器时钟漂移了整整15分钟。那两周的日志时序全乱了，后来花了三天才手工对齐。从那以后，我经手的项目全部强制用NTP同步 + UTC存储。
3. 何地（Where）—— 来源定位
"何地"不是指物理地址，而是指操作的来源位置。说白了，你得知道这个操作是从哪里发起的。
这里有三个层级，看你需要哪一层：
| 层级 | 记录内容 | 适用场景 |
|---|---|---|
| 网络层 | 源IP、端口、协议 | 网络攻击溯源、访问控制审计 |
| 设备层 | 主机名、MAC地址、设备ID | 内部运维审计、设备合规 |
| 地理层 | 地理位置、国家/城市 | 跨境数据访问、异常登录检测 |
我个人的习惯是：网络层必记，设备层尽量记，地理层看业务需求。别为了"好看"去记一堆用不上的字段——每多一个字段，存储和解析的成本都往上翻。
4. 何事（What）—— 操作描述
这是五要素里最"肥"的一块，也是最容易写"烂"的一块。
"何事"要回答两个问题：做了什么 + 对什么做的。
看两个例子，你就明白了：
- ❌ 差的日志：
用户修改了配置——改了哪个配置？改前改后是什么？完全不知道。 - ✅ 好的日志：
用户 admin 将订单超时时间从 30min 修改为 60min（配置ID: cfg_order_timeout）——清楚、准确、可回退。
写"何事"的时候，我给自己定了一条铁规矩：读日志的人，不需要看代码就能还原现场。
实操建议：操作对象用 资源类型:资源ID 的格式来记。比如 order:ORD20250615001，既知道是订单，又知道具体是哪一笔。
5. 结果（Result）—— 执行状态
最后这个要素，很多人觉得不就是"成功"或"失败"吗？其实没那么简单。
我见过最离谱的日志，操作失败了还记了个"success"。后来一查，是开发在catch块里直接复制粘贴了成功日志的代码。这种错误在审计时会产生严重的误导。
结果字段我建议至少包含：
- 状态码：0表示成功，非0表示具体错误码。别用"success"/"fail"这种字符串，后面脚本解析的时候你会哭的。
- 状态描述：错误码对应的可读说明。比如
ERR_AUTH_EXPIRED - 用户凭证已过期。 - 耗时：操作的执行时长（毫秒），这个在性能审计和异常检测里特别有用。
特别注意：结果字段千万不能为空。我曾经遇到过一个系统，正常操作记"success"，异常操作直接不写结果字段。结果合规检查时，审计员问我："空值到底是成功了还是没记录？"这个问题我当时答不上来——因为我也分不清。
实战：组装一个完整的审计日志
好了，五个要素都讲完了。咱们把它们拼起来，看看一个标准的审计日志长什么样。
{
"who": {
"user_id": "U20230615001",
"user_name": "张三",
"user_type": "admin",
"auth_method": "password"
},
"when": {
"timestamp": "2025-06-15T14:30:00.000Z",
"timezone_offset": "+08:00"
},
"where": {
"source_ip": "192.168.1.100",
"hostname": "jump-server-01",
"geo": "CN/Beijing"
},
"what": {
"action": "update",
"resource_type": "config",
"resource_id": "cfg_order_timeout",
"detail": "订单超时时间 30min → 60min"
},
"result": {
"code": 0,
"message": "success",
"duration_ms": 156
}
}你看，整个日志事件清晰得像一份报告。任何一个字段拿出来，都能回答一个明确的溯源问题。
为了帮你快速对照，我整理了一个检查表：
| 要素 | 必须包含 | 建议包含 | 常见错误 |
|---|---|---|---|
| 谁 | 用户ID、用户类型 | 会话ID、认证方式 | 只记用户名，不区分用户类型 |
| 何时 | UTC时间戳、时区 | 毫秒精度 | 使用本地时间、时区不一致 |
| 何地 | 源IP | 主机名、地理位置 | 只记内网IP，丢失外部来源 |
| 何事 | 操作类型、操作对象 | 变更前后值对比 | 操作描述模糊，无法还原现场 |
| 结果 | 状态码、状态描述 | 执行耗时 | 结果为空或状态码与描述不符 |
一个实用小技巧：刚开始做审计日志的时候，你拿这个表去逐条对日志，缺什么补什么。我团队里新来的运维，我都会让他们用这个表做一次日志健康度检查，效果比看十遍文档都好。
五要素讲完了。说白了，审计日志没那么玄乎——把"谁在什么时间从哪里做了什么、结果怎样"记清楚，你的日志就已经及格了。剩下的，就是在这个基础上根据业务场景做扩展。