📚 课程目录第2章日志基础概念

日志基础概念

做异常访问检测，首先得搞懂日志本身。你想想看，SDK 吐出来的日志长什么样？包含哪些信息？如果连日志的基本结构都不清楚，后面的检测无从下手。我个人习惯把这部分叫做“地基”，地基不稳，上层建筑迟早塌。

日志说白了就是系统或应用在运行过程中留下的“脚印”。每条脚印都记录了某个时刻发生了什么事。但不同系统留下的脚印格式千差万别，我们需要把它们统一理解，才能进行下一步分析。

字段类型：日志里都有什么

一条日志就像一张表格的一行，里面有很多列。常见的字段类型包括：

时间戳 — 事件发生的时刻，格式五花八门
日志级别 — 表示事件的严重程度，比如 INFO、ERROR
来源标识 — 谁产生的这条日志？模块名、服务名、线程ID等
消息体 — 描述具体事件的文本
上下文 — 关联的请求ID、用户ID、IP地址等

我在项目中遇到过一种情况：某次 SDK 升级后，日志里突然多了一个字段叫 origin_node，但文档没更新。后来排查发现是内部添加了分布式节点标识。所以不要只看文档，实际日志样本才是第一手资料。

建议你对接新 SDK 时，先拉一两小时的原生日志，把所有字段列出来，搞清每个字段的含义和可能的取值。这步花 30 分钟，后面能省三天排查时间。

时间戳：精度的关键

时间戳是日志的灵魂。没有准确的时间，异常检测就像一场没有时钟的考试。但现实中的时间戳格式多得让人头疼。

格式	示例	适用场景
Unix 时间戳（秒）	1743999999	嵌入式、性能敏感
Unix 时间戳（毫秒）	1743999999123	高精度日志
ISO 8601 带时区	2025-07-07T10:30:00.123+08:00	跨时区系统
自定义格式	2025/07/07 10:30:00.123	老旧系统

嗯，这里要注意：你拿到的 SDK 日志，时间戳是什么单位？我踩过坑：有一次收到的日志用秒级 Unix 时间戳，但我们的检测脚本默认当成毫秒处理，导致所有时间偏移了 1000 倍，异常事件全对不上。从那以后我写解析代码都会先打印几条样本，人工确认时间戳精度。

日志级别：从 VERBOSE 到 FATAL

每条日志都带着一个级别，告诉你这事多重要。常见的级别体系（按严重度递增）：

VERBOSE / DEBUG — 调试用，生产环境通常关掉
INFO — 正常运行信息，比如“服务启动成功”
WARN — 可能有隐患，但系统还在跑
ERROR — 功能出错，需要人为介入
FATAL / CRITICAL — 系统要崩了

做异常访问检测时，我一般把重心放在 WARN 及以上的日志上。不是说 INFO 不重要，而是攻击者往往会在 WARN/ERROR 之前先触一堆低级别痕迹，但我们要先抓住显眼的目标。**级别过滤是最快的降噪手段**。

注意：不同 SDK 可能自定义级别名称。比如有的用 SEVERE 替代 FATAL，有的用 NOTICE 介于 INFO 和 WARN 之间。必须查看 SDK 文档确认实际级别定义，否则过滤条件会漏掉关键日志。

常见格式：JSON 与 Syslog

现在主流 SDK 日志一般有两种格式：JSON 和 Syslog。JSON 灵活、可嵌套，适合结构化存储；Syslog 是经典网络日志协议，文本一行一条，携带少量元数据。我偏好 JSON，解析起来省心，但 Syslog 在老旧设备和网络设备上依然常见。

举个例子，一条 JSON 格式的日志可能长这样：

{
  "timestamp": "2025-07-07T10:30:00.123Z",
  "level": "ERROR",
  "service": "auth-svc",
  "message": "Invalid access ",
  "user_id": "u_12345",
  "ip": "10.0.1.100"
}

同样的内容如果走 Syslog 格式：

<11>Jul  7 10:30:00 auth-svc sdk-auth[12345]: Invalid access

你看，Syslog 把时间戳、主机名、进程信息都揉在了一行头里，消息体则在后面。解析时需要理解 Syslog 的头部规范（RFC 5424 或更老的 RFC 3164）。

维度	JSON	Syslog
可读性	高，结构化	低，需要正则提取
嵌套支持	支持对象和数组	只能文本扩展
解析复杂度	低（json.loads）	中（按协议拆字段）
传输开销	较大	较小
常见场所	云原生、微服务	网络设备、Linux 系统

如果你接手一个混合日志源的项目，我建议统一转成 JSON 再存储。写个轻量的数据管道，把 Syslog 转成 JSON，后续检测逻辑只用一套解析器。我曾经用 Python 写了个 30 行的转换脚本，把上百台网络设备的 Syslog 格式统一了，检测效率直接翻倍。

本章知识体系

为了让这些概念更直观，我画了一张结构图。它展示了日志从产生到被我们理解的过程，以及字段、时间戳、级别、格式之间的关系。

看到这个图就清晰了。我们拿到一条日志，首先要提取出字段（特别是时间戳和级别），然后根据格式（JSON 或 Syslog）选择正确的解析方法。剩下的工作就是把解析后的结构化数据喂给后面的检测模型。说白了，基础概念都没搞清，检测就是空中楼阁。

小结一下：你该做什么

导出 SDK 样本日志，人工浏览一遍，找出你看到的所有字段
确认时间戳的格式和精度（秒还是毫秒？带不带时区？）
明确日志级别的实际枚举值（不要想当然）
判断日志是 JSON 还是 Syslog，或者混合形式
写一个简单的解析脚本，把样本日志全部转成统一结构体，打印出来看看准不准

做完了这五步，你就可以放心地进入下一环节：日志解析与清洗。不过那不是本章内容，先把地基打牢。