数据预处理与字段提取归纳总结

做审计报告最痛苦的是什么？不是写查询，而是数据本身乱七八糟。

我从第一个Splunk项目就领教过——原始日志里时间戳格式不统一，字段名一会儿是src_ip一会儿是sourceip。嗯，要是不做预处理，后期统计全白费。这一章我就讲讲自己的经验：怎么把原始数据收拾得服服帖帖，再稳稳当当地把关键字段提取出来，最后归纳成可供审计的干净数据。

为什么要预处理？

说白了，审计报告追求的是精确和可重复。你想想，如果日志里混着乱码、空行、重复事件，或者时间轴歪了，报告结果能信吗？

• 去重：同一个事件被多个转发器发了两次，必须去掉。
• 时间标准化：Splunk默认用_time字段，但很多系统自己带时间戳，格式五花八门。
• 字段一致性：把user、User、username统一成user。

我习惯在索引时就做一部分预处理，比如用props.conf和transforms.conf，但搜索时的二次预处理同样重要。为什么呢？因为索引器上改不了动态内容，字段提取在搜索时更灵活。

我的预处理流程

拿到原始数据，我会走四步：

1. 清洗——砍掉无关行（比如调试日志、心跳包）。用search的NOT过滤。
2. 时间对齐——用| eval _time=strptime(timestamp, "%Y-%m-%dT%H:%M:%S")强制修正。
3. 字段提取——下文细说。
4. 归纳——把分散的字段统计成审计需要的聚合值，比如登录失败次数、每个用户的资源访问量。

我见过有人把所有预处理都压在搜索语句里，结果查询跑几分钟。建议尽量用索引时预处理（比如字段提取器），搜索时只做轻量级调整。

字段提取方法对比

我个人最常用的是正则+K V组合。举个例子，审计防火墙日志时，里面的源IP和目标端口经常混在一行里。

index=firewall sourcetype=forti_log
| rex "srcip=(?<src_ip>\d+\.\d+\.\d+\.\d+).*dstport=(?<dst_port>\d+)"
| table _time, src_ip, dst_port, action

你看，用rex命令加上命名分组，字段就自动生成了。注意正则要精确，别把无关的也匹配上。我之前就在一个项目里写了个宽泛的.*，结果把日志里所有IP都抓到同一个字段，翻车了。

归纳总结：把字段变成审计指标

字段提取完还不够——我们要归纳总结。审计报告需要按用户、时间、行为类型汇总。比如统计过去一周每个用户的登录失败次数。

index=auth sourcetype=linux_secure
| rex "Failed password for (?<user>\w+) from (?<src_ip>\d+\.\d+\.\d+\.\d+)"
| eval hour=tonumber(strftime(_time, "%H"))
| stats count as fail_count by user, src_ip, hour
| where fail_count > 3

stats是做归纳的利器。还可以结合eventstats保留原始事件的同时附加聚合值。我建议你建立一个“归纳流程清单”，每次做审计报告都按清单走一遍：

• 确定审计对象（如防火墙、Windows事件日志）
• 提取必要字段（IP、用户、操作）
• 计算常用指标（次数、总时长、分布）
• 关联补充数据（用lookup加资产归属）
• 输出为表格或图表

避坑指南

我曾经在一个客户现场，因为没做时间对齐，导致报告里每天的事件量都少一半。后来发现日志里的时间戳是UTC，Splunk默认当成系统本地时间处理。修正后数据才正常。

• 别忽略转义：正则里的反斜杠、括号都要小心，尤其在Splunk的rex里。
• 性能陷阱：在大量事件上执行复杂的rex会非常慢。能用delim或kv就别上正则。
• 字段名冲突：Splunk已有host、source等内建字段，你提取同名新字段会覆盖原有值，务必用新名字或AS重命名。

下面放一张整个数据预处理与字段提取的流程图，帮你快速掌握全貌。

从最顶层的原始日志开始，一路经过清洗、时间对齐、字段提取，最终到归纳总结——每一步都环环相扣。我建议你在实际工作中先用一小段样本日志测试整个流程，跑通了再应用到全量数据。相信我，这样能省下至少一半的调试时间。