3、审计数据源调研：日志、数据库、API、文件等数据来源的采集方案
做审计系统，第一步就是搞定数据。
数据过不来，后面再牛的规则引擎也没戏。我见过太多项目，一上来就搭平台、写规则，结果卡在数据采集上整整一个月。嗯，今天咱们就聊聊这个话题。
审计的数据源，说白了就是四类：日志、数据库、API、文件。每一类的脾气都不一样，采集方案也得对症下药。
3.1 日志采集——最朴素的审计依据
日志是审计的老祖宗。系统干了什么，生了个日志，咱们把它捞走就好。但日志这玩意儿，量太大，格式太乱。
3.1.1 常见日志源
- 系统日志：Linux的syslog、Windows的Event Log。记录登录、权限变更。
- 应用日志：Nginx的access.log、Tomcat的catalina.out。记录请求流量、报错。
- 安全日志：防火墙日志、WAF日志、HIDS日志。记录攻击、异常行为。
- 中间件日志：Kafka的server.log、Redis的慢查询日志。记录中间件状态变化。
我习惯先梳理一下，当前环境里有哪些日志文件是必须入审计的。不是所有日志都要，挑关键的，否则你们的存储第一个扛不住。
3.1.2 采集工具选型
| 工具 | 协议/方式 | 适合场景 | 我踩过的坑 |
|---|---|---|---|
| Filebeat | 读文件，推Kafka | 轻量、单机部署 | 曾经一次升级，新的Filebeat解析不了旧日志里的时间戳，丢了一天数据 |
| Logstash | 读文件+Filter | 格式复杂、需要清洗的场景 | Filter写得太重，CPU飙到90%，后来拆到多个Pipeline才稳定 |
| Flume | Agent/Source/Sink | 大数据生态（HDFS） | 配置太绕，Source和Sink的Channel类型选错，直接丢数据丢了三天才发现 |
| Rsyslog | UDP/TCP/RELP | 传统syslog集中 | UDP默认丢包不通知，必须上RELP才可靠 |
3.1.3 采集方案避坑
我曾经在给某金融客户做审计时，用Filebeat默认配的multiline去合并Java异常堆栈。结果一个堆栈跨了200行，直接撑爆了event buffer，Filebeat挂了，日志全丢。
后来我改了方案：堆栈先原样入库，在Logstash里再按行号重组。嗯，稳定多了。
还有一点——日志采集必须记录采集元数据。什么元数据？主机名、采集时间、文件偏移量、原始路径。没有这些，后续审计溯源会很痛苦。你想想看，一条审计日志只有IP没有主机名，换了网段就找不到是哪台机子了。
3.2 数据库采集——最精准的审计弹药
数据库里躺着业务数据的最终状态。这张表谁改了、什么时间改的、改之前是什么、改之后是什么，这是审计最想要的东西。
但数据库的读取，极容易搞崩源库。我见过一个团队，全量扫一张10亿行的订单表，扫了8个小时，业务那边CPU 100%，差点出事。
3.2.1 采集方式对比
| 方式 | 原理 | 对源库影响 | 实时性 | 适用场景 |
|---|---|---|---|---|
| 全量抽取 | SELECT * | 极高 | 一次性 | 初始化、存量数据补录 |
| 增量抽取 | WHERE update_time > ? | 中 | 分钟级 | 小表、业务允许短时延迟 |
| CDC（变更数据捕获） | binlog/redo log实时解析 | 低（异步读取） | 准实时（秒级） | 核心表、全量审计留痕 |
我个人最推荐CDC。为什么？它读的不是数据库表，是binlog——完全不锁表。但CDC有个坑：binlog保留天数。如果保留7天，审计系统中途挂了7天以上，断档的数据就再也补不回来了。
3.2.2 数据一致性保证
不管是全量还是增量，必须做数据对账。怎么做？
- 写一个对账脚本，每天凌晨统计源库和目标库的行数一致。
- 选几个关键字段做哈希校验——不一定全字段，但必须有。我一般选主键+最后修改时间+数据指纹哈希。
- 不一致的，记到报警表里，人工复查。
你想想看，审计系统自己都没有数据一致性，别人凭什么信你的审计结果？
3.3 API采集——自建系统的审计接口
有些系统不方便直接读库或日志文件，比如SaaS、外包系统、老旧系统。这时候就得靠API了。
3.3.1 接口设计要点
我们作为采集方，得和对方约定好接口规范。我建议至少包含这些字段：
- 操作主体：谁干的（user_id、user_name）
- 操作时间：在源系统发生的时间（不是接口调用时间）
- 操作类型：增/删/改/查
- 操作对象：改了哪张表、哪个记录的主键
- 变更前内容：JSON格式的old_value
- 变更后内容：JSON格式的new_value
- 来源IP、UA：关联终端信息
接口还得约定好分页和重试策略。我曾经对接过一个外包ERP，对方API每页只能返回100条，超过就报403。我只好写个循环，一页一页拉，每次间隔200ms，避免限流。
3.3.2 采集策略
- 定时轮询：5分钟拉一次增量，适合非核心系统。
- 主动推送：源系统通过webhook往咱们的采集端POST数据，实时性最好。
- 补偿拉取：推送失败或漏了，靠定时任务补拉一次。
3.4 文件采集——最低成本的审计补充
有些机构还在用CSV、Excel甚至PDF的审计日志。别笑，我接过一个银行项目，他们的核心系统每天凌晨输出一个TXT文件，里面全是当天的操作记录，连分隔符都是自己定义的。
3.4.1 常见文件类型
| 类型 | 解析方式 | 注意事项 |
|---|---|---|
| CSV / TSV | 按分隔符切割 | 编码、转义、换行符处理 |
| Excel (xls/xlsx) | Apache POI / EasyExcel | 大文件内存溢出，用流式读取 |
| XML / JSON | XPath / JsonPath | 必须校验Schema，防止字段缺失 |
| PDF / 扫描件 | OCR（Tesseract/商用） | 准确率不高，只做辅助审计 |
3.4.2 采集流程
- 文件到达：通过SFTP、FTP、共享目录、邮件附件等方式收文件。
- 文件校验：检查MD5、文件大小、文件名日期是否匹配。
- 内容解析：用结构化解析器转成统一日志格式。
- 入审计库：直接写入审计数据明细表。
- 文件归档：处理完成的文件移到archive目录，保留30-90天备查。
我建议文件表里加一列"file_id"，记录这条审计数据来自哪个文件。万一发现某批次数据全错了，可以直接按file_id撤回重采。
3.5 数据源采集方案全景图
最后，我把上面说的内容整理成一张图。你不用记细节，看明白整个流转方向就行。
嗯，这就是我们审计数据源调研的全貌。从四个源头出发，到四种采集策略，再到统一管道和最终存储。我个人觉得，最关键的其实不是技术选型，而是对数据源本身的调研是否到位。你调研得越细，后面踩的坑就越少。