4. 日志预处理：从原始日志到结构化数据

日志解析，说白了，就是把那些机器写的、人看着费劲的文本，转成我们能理解、能分析的数据结构。

我刚开始做安全分析的时候，面对海量的原始日志，头都大了。每一条日志格式都不一样，有的用空格分隔，有的是 JSON，有的还带特殊符号。那时候我就在想，要是能有个工具，一键把这些乱七八糟的文本变成整齐的表格，该多好啊。

后来我明白了，这就是日志预处理的核心工作。它就像个翻译官，把各种方言的“机器语”，翻译成统一的“普通话”。

4.1 日志解析的三把刀：正则、JSON、Grok

解析日志，我有三种最常用的手段。它们各有千秋，用对了地方，事半功倍。

• 正则表达式（Regex）：最灵活，也最难写。适合处理那些格式不规范、有固定模式的文本。
• JSON 解析：最简单，结构清晰。现代应用和 API 日志基本都是这个格式。
• Grok 模式：运维领域的神器。它其实就是一组预定义的正则，让你能复用常见的日志模式（比如 syslog、Apache 日志）。

我在项目中遇到过这样的事：一个老系统产生的日志，格式非常诡异，既有空格又有 tab，还混着特殊字符。正则写了半天，改来改去总有漏网之鱼。后来我干脆写了个状态机，一行一行地处理，才算是彻底解决了。这说明什么？没有万能的工具，只有最合适的方案。

4.2 字段提取：从杂乱文本中挑出“主角”

解析完日志，下一步就是提取关键字段。这些字段就是我们后续做异常检测的基础。

你想想看，审计日志里，哪些信息最重要？

1. 时间戳：事件发生的准确时间。这是所有分析的起点。
2. 源 IP 和目的 IP：谁访问了谁。
3. 用户名：哪个账号在执行操作。
4. 操作类型：登录、读文件、写文件、删除、创建……
5. 资源对象：操作了什么文件、数据库、API。
6. 结果状态：成功还是失败。失败的背后，往往藏着故事。

我会把这些字段用一个统一的命名规范整理好，比如都用小写+下划线。这样后面的分析和存储就方便多了。

下面是我常用的一个字段映射表：

原始日志字段	标准化字段名	数据类型	示例
timestamp / date	timestamp	datetime	2024-10-27 10:00:00
src_ip / client_ip	src_ip	string	192.168.1.10
user / username	user	string	jdoe
action / operation	action	string	login, file_read
resource / object	resource	string	/var/log/auth.log
status / result	status	string	success, denied

你可能会问：字段多了怎么办？我的习惯是：先全部提取，再按需保留。暂时用不上的字段，可以先放着，不丢数据。但分析核心问题的时候，只关注那几个关键字段就行。

4.3 数据清洗：把“脏”数据洗白

日志里的数据，可不总是那么干净的。我见过各种“脏”数据：时间戳格式不统一、IP 地址写错了、字段值里带着奇怪的不可见字符……

数据清洗，就是把这些问题处理掉。这一步做不好，后面的分析全是白费。

常见的清洗工作包括：

• 去除无效行：比如全是注释的、调试信息、空行。
• 统一时间戳格式：把所有时间都转成统一的格式，比如 YYYY-MM-DD HH:mm:ss。我建议你用 UTC 时间，避免时区转换的麻烦。
• 去除重复行：有些日志源会重复发送同一条日志，需要去重。
• 修正数据格式：比如把 1.0 这样的字符串转成整数 1。

4.4 异常值处理：识别和处理“异常”中的正常

这里说的异常值，不是安全事件中的“异常行为”，而是数据本身的问题。比如：

• 响应码是 9999（明显不合法的状态码）
• 请求时长是 -1 秒（负数，不合逻辑）
• 用户名字段里有个 null 字符串

这些异常值，可能是采集时出错，也可能是程序 bug。不管怎样，我们得先处理它们，才能让后续的模型不被“假数据”干扰。

4.5 本章知识体系总览

为了让你更直观地理解整个过程，我画了一张流程图。

这张图概括了本章的四个核心步骤。你按照这个流程走，就能把一堆原始的、乱糟糟的日志，变成井然有序的结构化数据。