2. 接口日志分类：请求日志、响应日志、错误日志、性能日志的区别与用途
做接口日志这么多年，我见过不少团队把各种日志混在一起存。结果排查问题的时候，就像在垃圾堆里翻硬币，又慢又累。其实，把日志按用途拆开，比你想的管用得多。
今天我就把这四种日志掰开揉碎，讲清楚它们各自管什么、长什么样、怎么配合SIEM审计。
2.1 请求日志：记录谁来了、干了什么
请求日志是接口日志的“门卫”。它记录每一次外部请求的基本信息，说白了就是：谁，什么时候，从哪来，要什么。
拿我手里的一个金融项目举例，请求日志里必须包含这些字段：
| 字段 | 示例值 | 说明 |
|---|---|---|
| timestamp | 2025-03-15T10:30:00.123Z | 请求到达时间 |
| client_ip | 192.168.1.100 | 客户端IP |
| method | POST | HTTP方法 |
| path | /api/order/create | 接口路径 |
| headers | {"User-Agent":"..."} | 关键请求头 |
| body | {"amount":1000} | 请求体（脱敏后） |
注意：body 字段必须做脱敏处理，尤其是密码、身份证、银行卡号。我见过有人直接把明文密码记日志里，结果审计被打了回来。
在SIEM里，请求日志的主要用途是：
- 攻击溯源：看看恶意IP都访问了哪些接口。
- 频率分析：发现短时间内同一IP疯狂请求，可能是在暴力破解。
- 合规审计：证明谁在什么时间操作了什么。
举个例子，我曾经接到过一个告警：某个接口的请求量在凌晨突然暴涨。我翻了请求日志，发现所有请求的User-Agent都一模一样，明显是脚本在刷。直接封IP，搞定。
2.2 响应日志：记录返回了什么、状态好不好
响应日志和请求日志是“一对”。它记的是服务端返回的内容——状态码、耗时、返回体。为什么需要单独的响应日志？因为光看请求你猜不到结果。我遇到过好多次，请求日志显示成功了，但用户投诉说页面报错。一查响应日志，发现状态码是200，但body里有个"code":50001的内部错误码。所以，响应日志必须包含业务状态码。
// 一个典型的响应日志 JSON 行
{
"timestamp": "2025-03-15T10:30:00.456Z",
"request_id": "req_abc123",
"status": 200,
"business_code": 50001,
"response_body": "{\"code\":50001,\"msg\":\"余额不足\"}",
"response_size": 256
}警告：响应体同样需要脱敏。比如返回了用户手机号、身份证，必须用星号替换。我见过一个团队因为响应日志泄露客户信息，被罚了50万。
响应日志在SIEM里的价值：
- 故障定位：如果某接口突然大量返回500或业务错误码，立刻能发现。
- 异常检测：比如某接口正常返回200，但大小突然从1KB变成了10KB，可能被注入了额外数据。
- 用户行为分析：结合请求日志，还原一次完整的操作链。
2.3 错误日志：记录出了什么岔子、严重程度
错误日志和前面两种不一样。它不是为了记录“正常流程”，而是专门记录异常情况和系统内部错误。比如数据库连接失败、空指针、超时、认证失败。千万不要把业务上的“余额不足”这种预期内的异常也扔进错误日志，否则你永远分不清哪些是真正的故障。
| 错误类型 | 日志示例 | 处理建议 |
|---|---|---|
| 数据库连接失败 | Error: connect ECONNREFUSED 127.0.0.1:3306 | 立即告警，重启或扩容 |
| 空指针异常 | TypeError: Cannot read property 'xxx' of undefined | 记bug，修复代码 |
| 认证失败过多 | Authentication failed for user 'admin' from 10.0.0.1 | 可能为暴力破解，触发SIEM规则 |
我个人习惯在错误日志里加上severity字段：FATAL、ERROR、WARN。FATAL会导致系统不可用，必须马上处理；ERROR需要人工介入；WARN只是提示。SIEM里可以按severity做不同级别的告警。
避坑指南：我曾经把一个循环里的异常用print(e)打印到标准输出，结果线上出现大量重复错误日志，把磁盘撑爆了。正确做法是在异常捕获里只记录第一条，并设一个错误频率上限。
2.4 性能日志：记录系统跑得快不快
性能日志是我最喜欢的，因为它能帮你提前发现隐患。它记录的是接口的响应时间、数据库查询耗时、外部调用耗时、内存使用等指标。性能日志不是为了排查“这次请求对不对”，而是为了宏观观察系统健康度。
// 性能日志通常与请求日志合并，但单独采集
{
"request_id": "req_abc123",
"total_time_ms": 350,
"db_time_ms": 120,
"cache_time_ms": 30,
"external_call1_ms": 180,
"memory_mb": 256
}在SIEM里，我会建这样几个规则：
- 慢查询检测：总时间超过1秒的接口，自动生成告警。
- 趋势分析：最近5分钟的平均响应时间比过去1小时上涨了30%，发预警。
- 资源泄漏：内存占用持续增长不下降，可能内存泄漏。
记住，性能日志的采集频率不能太高，否则反而影响性能。我一般按每请求一条采集，不单独开采样。
2.5 四种日志对比：一张表看清楚
| 维度 | 请求日志 | 响应日志 | 错误日志 | 性能日志 |
|---|---|---|---|---|
| 主要目的 | 记录请求输入 | 记录请求输出 | 记录异常和错误 | 记录性能指标 |
| 是否必存 | 是（审计要求） | 是（排查需要） | 是（故障定位） | 建议开启 |
| 数据量 | 大（每条请求一条） | 大 | 中小（只记录异常） | 中（每条请求一条） |
| 脱敏要求 | 高（body脱敏） | 高（响应体） | 中（避免泄露堆栈敏感信息） | 低（通常无敏感数据） |
| SIEM典型规则 | 频率分析、IP黑名单 | 状态码异常、响应大小突变 | 错误率超阈值 | 慢接口检测、趋势预测 |
2.6 一张图理清四种日志的关系
下面这张图展示了在一次接口调用过程中，四种日志分别在哪个环节产生。你可以想象成流水线：请求来了先写请求日志，处理完写响应日志，如果过程出错了写错误日志，最后性能指标汇总成性能日志。
你看，请求日志和响应日志是一对“前后门”，错误日志是“警报器”，性能日志是“体温计”。把它们分开存储、分别建立SIEM规则，才能在出现问题时快速定位。嗯，这里要注意：一定要用同一个 request_id 把这四种日志串起来，否则你看到性能日志变慢了，却找不到对应的请求和响应，等于白费。
以上就是四种日志的完整解析。找个时间把你现在的日志结构捋一捋，看看是不是混在一起？如果是，赶紧拆开，你会感谢自己的。