第2章 日志基础概念：日志类型、格式、级别
聊日志之前，我先问个问题：你觉得日志到底是什么？
说白了，日志就是系统运行过程的“黑匣子”。每一条记录都告诉我们系统在某个时间点干了什么、谁干的、结果如何。我刚开始搞安全那会儿，觉得日志就是调试用的，出问题了才翻一翻。后来被攻击者教做人，才知道——嗯，不打好日志基础，安全运维就是闭眼开车。
这一章，我们把日志的底层概念掰开揉碎。你理解了类型、格式、级别这三个维度，后面讲采集、解析、审计才能顺起来。
2.1 日志的三大来源
从SaaS安全视角看，日志主要来自三个层面。我习惯把它们画成一个三角形：
你可能会问，知道这些有什么用？我给你举个例子——
假设你公司用了云CRM和内部OA。CRM产生Syslog格式的操作日志，OA自己写JSON格式。如果你不了解格式差异，直接拿同一条规则去解析，一半数据会变成乱码。我最早踩过的坑就是这个。
2.2 日志类型
日志类型按来源分，主要有以下几种。我把它们列了个对照表，配合我实际见过的场景：
| 类型 | 典型协议/格式 | 特征 | 我遇到的场景 |
|---|---|---|---|
| 系统日志 (Syslog) | RFC 5424 / RFC 3164 | UDP传输、结构化、级别标签 | 早期防火墙、Linux服务器默认输出 |
| Web服务器日志 | W3C Extended / NCSA | 时间戳、请求方法、状态码、URL | Nginx/Apache，分析攻击路径常用 |
| 应用日志 | JSON / Log4j / Logback | 层级化、可自定义字段 | Java微服务最爱，字段自由但解析麻烦 |
| 数据库日志 | Audit Trail / Binary Log | 事务记录、模式变更、用户查询 | MySQL的general_log慢查询审计 |
| 云平台日志 | CloudTrail / Azure Monitor | API调用、资源变更、IAM操作 | SaaS厂商的标准安全数据源 |
我的做法：在搭建日志平台前，先把所有数据源按上表分类画一遍。分类清楚了，采集配置就不会遗漏。我习惯用颜色标签区别：红标为安全必需，黄标为可选审计，绿标为辅助诊断。
2.3 日志格式
格式直接决定了你能不能解析。我见过最离谱的情况：某SaaS平台说支持日志导出，结果导出来是……自己定义的二进制格式，连官方文档都只有半页描述。嗯，这就是典型的不遵循标准。
2.3.1 标准格式 CEF 与 LEEF
CEF（Common Event Format）和LEEF（Log Event Extended Format）是安全圈比较通用的。两者结构类似，都是 Header + Extension 的模式：
// CEF 格式示例
CEF:0|Security|threatmanager|1.0|100|detected a threat|10|src=10.0.0.1 dst=10.0.0.2 msg=malware.exe
// LEEF 格式示例
LEEF:1.0|Security|threatmanager|1.0|100|devTime=2024-03-15T10:00:00Z src=10.0.0.1 dst=10.0.0.2 msg=malware.exe我个人更倾向于CEF，生态更成熟，大部分SIEM原生支持。LEEF在IBM QRadar场景中更常见。
2.3.2 JSON 与 XML
JSON现在几乎是事实标准。它天然支持嵌套结构，对于现代SaaS应用来说非常友好。但要注意：有的厂商把JSON当普通文本发送，连换行都不加。我遇到过一条日志有25层嵌套，解析器直接爆栈。
重要提醒：JSON日志中的时间戳字段名和时区格式不统一（有UTC、+8、Unix时间戳），必须做归一化处理，否则排序关联会乱。
// 良好结构的JSON日志
{
"timestamp": "2024-03-15T10:00:00.000Z",
"event_id": "AUTH-001",
"user": "zhangsan@company.com",
"action": "login",
"source_ip": "10.0.0.1",
"result": "success"
}
// 不规范的JSON日志（我碰到过的真实情况）
{
"time": "2024/03/15 18:00:00",
"user": "zhangsan",
"op": "login success from 10.0.0.1"
}XML格式现在用得少了，但在某些金融SaaS中还在用。我刚开始处理Windows Azure日志时也被这个结构折腾过。它虽然结构化严谨，但解析开销比JSON大几个数量级。生产环境中，我不推荐过度使用XML。
2.3.3 自定义格式
这是最让人头大的类型。有些SaaS厂商为了“轻量化”，自己定义一行文本的日志。比如：
2024-03-15 10:00:00|LOGIN|zhangsan|10.0.0.1|Y
2024-03-15 10:01:23|LOGOUT|zhangsan|10.0.0.1|Y看起来简单，但解析规则全靠猜。我踩过最深的一个坑是：某厂商用“|”分隔字段，但字段内容里也包含“|”，没有转义。那段时间我熬了三个通宵手写正则替换……现在想起来还头皮发麻。
建议：如果你在选型SaaS产品，优先看它是否支持导出CEF、JSON格式的日志。不支持的话，尽量要求二次加工流程。不要轻信“我们日志格式很简单”这种话。
2.4 日志级别
日志级别的重要性，我有个血泪史：有一次排查线上故障，发现所有日志都是INFO级别，根本找不到错误线索。后来发现：部分老系统没有正确对接日志级别接口，全部写死为INFO。
目前绝大多数系统遵循 RFC 5424 的标准，把级别分为8个等级：
| 级别编号 | 级别名称 | 典型含义 | 在安全场景中的用法 |
|---|---|---|---|
| 0 | EMERGENCY | 系统不可用 | 审计链路完全中断，需立即响应 |
| 1 | ALERT | 需要立即处理 | 检测到暴力破解峰值、泄露 |
| 2 | CRITICAL | 严重错误 | 数据库被删表、IAM配置被恶意修改 |
| 3 | ERROR | 错误事件 | 请求鉴权失败、敏感数据泄露尝试 |
| 4 | WARNING | 警告事件 | 异常用户行为、非正常时间段登录 |
| 5 | NOTICE | 重要信息 | 配置变更、权限提升、新建管理员 |
| 6 | INFO | 普通信息 | 用户登录、API调用、数据导出 |
| 7 | DEBUG | 调试信息 | 开发环境才开启，生产环境原则上关闭 |
你可能会问：真的有人从0到7都配置一遍吗？
我的经验是：大部分生产环境只开放 WARNING、ERROR、CRITICAL、ALERT、EMERGENCY 这几个。NOTICE 可开可不开，INFO 作为审计补充。DEBUG 绝不能在生产打开——I/O开销大且泄露太多内部细节。
实战建议：开日志之前，先跟开发和运维对齐级别映射表。我自己维护了一份标准映射模板，每次引入新系统都用它核一遍，避免后期重新爬日志。
2.5 小结一下
日志类型告诉你去哪里找数据，日志格式告诉你数据长什么样，日志级别告诉你要多重视这个数据。三者环环相扣，缺一个环节都会导致安全事件漏报或误报。
我写了个简单的检查清单，每接到一个新SaaS系统，先跑一遍：
- 类型检查：是Syslog、JSON还是自定义？是否需要协议转换？
- 格式检查：时间戳是否带时区？嵌套层级多深？分隔符有无转义？
- 级别检查：系统是否真实输出多个级别？级别值与RFC 5424是否对齐？
- 兼容性检查：能否被现有SIEM或日志平台直接采集？解析模板是否存在？
把这些搞清楚，后面的章节你跟着走就会很顺利。千万别像我当初一样，日志拉了一堆，才发现格式和级别对不上，一堆白干。