审计日志基础：日志的定义、类型与级别
说到审计日志，很多同学第一反应就是“记流水账”。其实没那么简单。我做IM审计系统的时候，每天跟几千万条日志打交道，如果基础概念没吃透，后面排查问题简直要命。
所以我觉得，花一章时间把日志的定义、类型和级别彻底说清楚，是非常值得的。嗯，咱们开始。
日志到底是什么？
日志，说白了就是系统运行过程中的事件记录。每一条日志，都是一个不可修改的客观凭证。你想想看，当用户发送了一条消息，系统收到这条消息，转发给服务器，服务器再推送给接收方——整个过程，每一步都应留下痕迹。
IM外发审计日志呢，就专指即时通讯系统里，对外发送消息时产生的审计轨迹。我见过不少团队只记录“发送成功/失败”两个字段，一旦出了问题根本查不到原因。
日志的三大类型
我刚开始接触审计系统时，以为日志只有一种。后来踩了个大坑——我把安全日志误当成系统日志去排查权限问题，查了两天才发现方向错了。从那以后，我只要做审计设计，第一步就是先把日志类型分清楚。
通常我们把审计日志分成三类：
| 类型 | 关注点 | 典型内容 | 主要来源 |
|---|---|---|---|
| 操作日志 | 用户/管理员的行为轨迹 | 发送消息、删除文件、修改权限、导出数据 | 应用层（IM客户端、管理后台） |
| 系统日志 | 系统运行状态与内部事件 | 服务启动/停止、数据库连接超时、磁盘空间告警 | 操作系统、中间件、服务框架 |
| 安全日志 | 安全相关事件与异常活动 | 登录失败、越权访问、恶意消息检测、加密异常 | 安关、身份认证模块、审计引擎 |
三类日志各司其职。操作日志回答“人做了什么”，系统日志回答“机器状态怎样”，安全日志回答“有没有被搞”。
日志级别：不是越多越好
日志级别这东西，看起来挺简单——就是分成DEBUG、INFO、WARN、ERROR、FATAL嘛。但实际项目中，我见过因为级别乱用导致硬盘爆掉的案例。
一次线上事故：某个IM服务异常重启后，开发同学为了调试，把日志级别从INFO改成了DEBUG，然后忘了改回来。结果一天的日志量翻了30倍，三天后磁盘满了，整个审计系统都瘫痪了。
所以，级别不是随便设的。我一般按这个规则来：
| 级别 | 数值 | 含义 | 使用场景 |
|---|---|---|---|
| DEBUG | 10 | 调试信息，开发阶段用 | 开发/测试环境，生产环境除非临时排障否则禁用 |
| INFO | 20 | 正常业务行为，可审计的事件 | 操作日志、关键流程的进程标记 |
| WARN | 30 | 潜在问题，不影响当前但需关注 | 重试超过阈值、响应时间变慢、磁盘接近满 |
| ERROR | 40 | 错误事件，功能受影响但系统未崩溃 | 消息投递失败、数据库查询超时、配置文件缺失 |
| FATAL | 50 | 致命错误，系统可能无法继续 | 核心服务崩溃、内存溢出、数据损坏 |
所以切记：生产环境操作日志至少要用INFO级别，DEBUG只适合临时开关。
把类型和级别放到一起看
类型描述的是“哪类事件”，级别描述的是“这件事的严重程度”。两者交叉，才能定义出一条日志到底长什么样。
举个例子：
- 一条操作日志，级别可能是INFO（正常发消息）或ERROR（发消息失败）。
- 一条安全日志，级别可能是WARN（多次登录失败）或FATAL（发现境外IP批量篡改消息）。
- 一条系统日志，级别可能是WARN（CPU负载过高）或ERROR（MySQL主从延迟超过30秒）。
你看，同一种类型可以跨不同级别，同一个级别也可以出现在不同类型里。这个思路，在之后设计日志过滤规则和告警策略时非常关键。
这张图左边展示了审计日志的三大类型，右边是日志级别的金字塔。你们可以注意到，INFO级别做了高亮——因为IM外发审计日志的主体，90%以上都是INFO级别的操作日志。但这不代表其他级别不重要。举个例子，如果某条消息投递被WARN级别标记了，那它很可能就是需要人工关注的风险事件。
好了，这章基础概念就聊到这里。记住：分清类型，定好级别，是搭建审计日志系统之前必须想清楚的两件事。不做这一步，后边管你用什么工具，都白搭。