第2章：审计数据源识别与接入归纳总结
咱们正式进入实操环节之前，先把“数据源”这事儿捋清楚。说实话，我见过不少人在 Splunk 里折腾半天，最后发现数据根本不对——不是字段丢了，就是时间戳错乱。追究起来，根源往往都在数据源识别这一步就没走对。
这一章，我会把常见的审计数据源分门别类讲清楚，再告诉你每类数据该怎么接进 Splunk。我自己踩过的坑、后来总结出的经验，都会放进来说。
2.1 审计数据源都有哪些？
审计数据源，说白了就是你想要监控的对象产生的“痕迹”。我个人习惯先把它分成四大类：
- 系统日志：Windows Event Log、Linux /var/log/messages、syslog 等。
- 应用日志：Web 服务器（Nginx、Apache）、数据库（MySQL、MSSQL）、中间件（Tomcat、WebLogic）的日志。
- 安全设备日志：防火墙、IDS/IPS、VPN、WAF 的日志，通常是 syslog 格式。
- 网络设备日志：交换机、路由器的 syslog，还有 NetFlow、sFlow 等流量数据。
为什么这样分？因为不同的数据源，接入方式、字段解析、时间处理都不太一样。曾经有个项目，客户把防火墙 syslog 当普通文本文件去喂 Splunk，结果所有事件的时间戳都变成了文件修改时间——那叫一个惨。所以，先识别清楚“这东西属于哪一类”，后面才能对症下药。
| 数据源类型 | 常见来源 | 典型格式 | 接入推荐方式 |
|---|---|---|---|
| 系统日志 | Windows Event Log, /var/log | EVTX, 文本 | Splunk Universal Forwarder (UF) |
| 应用日志 | Nginx access/error, MySQL slow | 单行/多行文本, JSON | UF 或 HTTP Event Collector (HEC) |
| 安全设备日志 | Palo Alto, Fortinet, Snort | Syslog 格式 | Syslog 监听 (TCP/UDP 514) 或 UF |
| 网络设备日志 | Cisco, Juniper, NetFlow | Syslog, IPFIX | Syslog 监听 + 插件 |
2.2 数据源识别——别光看文件名
你可能会说：“不就是看日志文件叫什么名字吗？”嗯，没那么简单。我曾经接手过一个项目，客户把所有日志都放在 /app/logs/ 下，文件名全是 output.log，里面却混着应用日志、数据库日志、甚至 cron 脚本的输出。这种情况下，你光看文件名根本区分不开。
我的做法是：
- 看内容特征：每个数据源的数据格式都有“指纹”。比如 Windows Event Log 有 EventID、Security 日志有 Account Name；Nginx access log 开头必定是 IP 地址；防火墙日志往往自带
src=dst=这样的键值对。 - 问人/看文档：找开发或运维确认日志生成规则。有一次我发现一个日志里居然有
BEGIN TRANSACTION，一问才知道是数据库审计日志——之前完全没人告诉我。 - 用 sourcetype 做标签：Splunk 里 sourcetype 是你的分类锚点。我习惯在 UF 的 inputs.conf 里就指定好，比如
sourcetype=linux:secure、sourcetype=cisco:asa。这样后面做字段提取和搜索都省心。
head -100 日志文件名 | tee sample.txt，然后把 sample.txt 拖到 Splunk 手动索引，看看字段是否被正确解析。我每接入一个新数据源都会做这一步。
2.3 数据接入的几种主流方式
接入方式没你想的那么复杂，但选错了会多走弯路。我按使用频率排个序：
- Universal Forwarder (UF)：最推荐。轻量、安全、支持断点续传。适用于文件和 Windows Event Log。
- HTTP Event Collector (HEC)：适合应用通过 API 直接推送 JSON 数据。配置简单，不需要在目标机器上装 agent。
- Syslog 监听：网络设备、安全设备的首选。Splunk 内置 syslog 端口 514 或 6514（TLS），但记得要提前规划好哪个端口对应哪个 sourcetype——不然所有东西都挤在一个端口里，后面很难分。
- 数据库直连（DB Connect）：如果审计数据存在关系型数据库里（比如 Oracle、MySQL），可以用 Splunk DB Connect 拉取。需要注意的是，这种方式对数据库性能有影响，建议只拉增量数据。
我个人的黄金法则是：能用 UF 就用 UF，不能再用其他。因为 UF 提供端到端的加密、压缩和持久化队列，数据几乎不会丢。
2.4 接入时的常见坑与避让
解决办法很简单：明确每个数据源的唯一接入路径。如果一个日志已经通过 UF 采集，就不要再开 syslog 监听同一个来源。另外，要检查 inputs.conf 里有没有 followTail = false ——如果你不小心设置成了从头读取，每次重启 UF 都会重新索引所有历史数据，后果很严重。
还有一个容易被忽略的点：时区。网络设备很多默认用 UTC，而应用服务器可能用本地时间。不统一时区的话，搜索出来的事件时间线全是乱的。我的做法是在 props.conf 里显式指定 TIME_ZONE，或者干脆在数据源端强制统一为 UTC。
2.5 归纳总结——画出你的数据流图
识别完所有数据源、确定好接入方式之后，我建议你画一张全貌图。不一定非要用什么高级工具，手绘都行。下面这张 SVG 图就是我当时给团队培训时用的版本，把审计数据源的识别与接入流程总结得很清楚：
这张图帮你把从“识别数据源类型”到“配置接入再到持续验证”的路径串起来了。你每次做审计数据源接入，都可以拿它当 checklist 来用。
2.6 实战小贴士——数据源清单
最后，我建议你维护一份数据源清单表格。我自己的习惯是用 Markdown 或 Excel 维护，内容至少包括：
| 数据源名称 | 主机 | 日志路径/端口 | 接入方式 | sourcetype | 备注 |
|---|---|---|---|---|---|
| Windows DC 安全日志 | DC-01 | Windows EventLog | UF | WinEventLog:Security | 已配置，每天约 2GB |
| Nginx 访问日志 | web-01 | /var/log/nginx/access.log | UF | nginx:access | 需多行合并？不需要 |
| Fortigate 防火墙 | 10.0.0.1 | UDP 514 | Syslog | fortigate:syslog | 时区设 UTC |
这份清单就是你后期的“数据字典”。每次做审计报告前，打开它核对一遍，看看有没有新增数据源、有没有数据断流。按照这套流程走下来，审计数据源的识别与接入基本不会出大问题。接下来你就可以放心地进入数据预处理和指标计算了。