📚 课程目录第3章日志字段提取

3. 日志字段提取：从原始日志到结构化数据

刚开始接触 HTTP 外发日志的时候，我拿到的基本都是这种乱七八糟的文本：

192.168.1.10 - - [10/Feb/2025:13:45:12 +0800] "POST /api/upload HTTP/1.1" 200 5321 "https://example.com" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"

看着挺整齐，真要编程提取——嗯，坑一点都不少。我做过好几个日志分析项目，每个项目都在字段提取上栽过跟头。下面我把常用技巧和踩过的坑掰开讲清楚。

IP 地址提取——不只是拿第一个字段

按照标准 NCSA 格式，IP 地址就是开头第一段。但现实情况呢？

IPv4：最简单的 \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} 基本够用，但注意要排除 256 以上的非法值。
IPv6：现在越来越多的请求走了 IPv6，格式像 2001:db8::1。我用过一个正则：[0-9a-fA-F:]+，再配合长度校验。
X-Forwarded-For：如果日志里记录了代理链，比如 192.168.1.10, 10.0.0.1，一般取第一个（客户端真实 IP）。

一个小细节：我建议提取完 IP 后做一次 ipaddress 库（Python）验证，否则你可能把 999.999.999.999 这种非法地址也存进去了。我曾经因为没校验，害得后续地理定位模块全崩了。

时间戳——花样最多的字段

时间戳的格式真是多得让人头疼。常见的有这几种：

格式	示例	解析方法
Common Log Format	`10/Feb/2025:13:45:12 +0800`	用 `strptime` 指定格式：`%d/%b/%Y:%H:%M:%S %z`
ISO 8601	`2025-02-10T13:45:12+08:00`	Python 3.7+ 直接 `datetime.fromisoformat()`
Unix 时间戳	`1739185512`	`datetime.fromtimestamp(int)`
自定义分隔格式	`2025/02/10 13:45:12`	先用正则替换斜杠，再解析

我踩过最大的坑是时区。Common Log Format 里时区是 +0800，Python 的 %z 在 Windows 下老版本不支持。后来我统一先替换成 +08:00 再解析，或者用 dateutil.parser。

注意：解析时间戳时务必指定时区。如果直接转成 naive datetime，不同时区的日志混在一起，排序和统计全乱。我一般统一转成 UTC 再存。

请求方法、URI、状态码——相对稳的三个

这三个字段在标准格式里位置固定，用正则 "([A-Z]+) (/[^ ]*) HTTP/\d\.\d" 就能拿到方法、URI，以及后面的状态码（空格后的三数字）。

但 URI 有一个坑——百分号编码。比如 %20 是空格，%E4%B8%AD 是汉字。我建议拿到原始 URI 后做一次 urllib.parse.unquote 解码，再按需分割 path 和 query 参数。

状态码提取简单，但记得验证是三位数字，200、404、500 等。曾经有人把 2000 这种自定义码写进了日志，被我过滤时漏掉了——嗯，做规则时还是得留个口子。

User-Agent——信息量最大的“垃圾箱”

UA 字符串可以很长，最多 512 甚至 1024 字符。提取时一定要用引号包起来的整体。正则："([^"]*)" 取最后一个引号段？不，UA 本身在日志末尾，位置靠后。NCSA 格式里 UA 是倒数第二个或最后一个字段，要看 Referer 是否存在。

我个人的习惯：先用空格分割，再根据引号对重新粘合，这样无论 Referer 在不在都不容易出错。

另外注意：UA 里可能包含括号、分号、括号嵌套，搞得正则很难写。别想着一次性完美解析，就用状态机或者分词器逐个拼回去。我有一版代码写了 80 行做这个，后来发现用 apache-log-parser 库能省一半工……但那又是另一个故事了。

Referer——可能缺失，也可能很长

Referer（虽然 HTTP 标准拼写错了，但大家都这么用）同样在引号里。提取方法与 UA 类似。注意：Referer 是可以没有的，比如直接输入地址访问。日志里的表现就是 "-"。提取时如果碰到短横线，我建议转换成 None 或者空字符串，而不是存个短横线——会污染后续的统计分析。

  实战建议：如果你用的是 Python，可以直接用 apachelog 库，几行解析搞定。但为了性能（海量日志场景），手写正则并用 re.compile 预编译。我试过，用库每秒处理 2 万行，手写优化后能到 6 万行以上。

代码示例：完整提取函数

import re

LOG_PATTERN = r'^(?P<ip>\S+) \S+ \S+ \[(?P<time>[^\]]+)\] "(?P<method>[A-Z]+) (?P<uri>[^ ]*) [^"]*" (?P<status>\d{3}) \d+ "(?P<referer>[^"]*)" "(?P<user_agent>[^"]*)"'

def parse_line(line):
    m = re.match(LOG_PATTERN, line)
    if not m:
        return None
    return {
        'ip': m.group('ip'),
        'timestamp': m.group('time'),   # 后续再解析成 datetime
        'method': m.group('method'),
        'uri': urllib.parse.unquote(m.group('uri')),
        'status': int(m.group('status')),
        'referer': m.group('referer') if m.group('referer') != '-' else None,
        'user_agent': m.group('user_agent')
    }

这个正则覆盖了 NCSA 组合格式。如果你遇到代理或多层请求，记得调整 IP 部分。还有，如果 URI 里带了查询字符串，你还可以再拆一步到 path 和 query_params 字典。

测试数据很重要：我每次写完提取代码，会准备一份“破坏性测试”数据——包含空 UA、超长 URI、带换行符的字段、拼写错误的 HTTP 版本。拿这份数据跑一遍，能发现很多隐蔽 bug。曾经有个日志里编码了 \n 字符在里面，把我整段解析搞乱了。

好了，字段提取这关过了，后面用结构化数据做过滤、统计分析就顺手多了。记住：正则是工具，不是信仰——遇到极其混乱的日志，该上分词器时就上分词器。