2. 日志采集架构：集中式采集的设计与选型
日志采集是整个审计分析的地基。地基没打好，后面再牛的分析引擎也白搭。我见过太多团队，上来就搞复杂规则引擎，结果日志都收不全——那真是空中楼阁。
这一节，咱们把采集架构聊透。从顶层设计到具体协议，再到接入规范，一条线捋清楚。
2.1 集中式日志采集架构设计
先问个问题：为什么非要集中采集？
你想想看，服务器几十台、上百台，每台都本地翻日志，效率低不说，还容易漏。集中采集的核心思路就一句话：日志统一收，分析统一做。
我个人习惯把采集架构分成三层：
- 采集层（Agent）：部署在目标机器上，负责读日志、发日志。
- 传输层（Broker/Queue）：消息队列或缓冲层，扛流量洪峰。
- 存储与分析层：Elasticsearch、ClickHouse 或 Splunk 这类。
下面这张图，是我常用的集中式采集架构，你看一眼就明白了。
我的经验：传输层别省。直接 Agent 到存储，流量一上来就丢日志。Kafka 虽然重一点，但值得。
2.2 Agent vs Agentless：两种采集方式怎么选？
这是每次架构评审都会吵起来的话题。我两边都用过，说说真实感受。
| 对比维度 | Agent 方式 | Agentless 方式 |
|---|---|---|
| 部署方式 | 每台机器装客户端 | 远程读取（SSH/SMB/WMI） |
| 资源占用 | 低（约 10-50MB 内存） | 无（消耗被采集端资源） |
| 采集效率 | 高，实时推送 | 中，轮询拉取 |
| 安全性 | 需管理凭证，但可控 | 需开放远程端口，风险高 |
| 适用场景 | 自有服务器、容器环境 | 老旧设备、网络设备、临时采集 |
我的建议：能装 Agent 就装 Agent。Agentless 看着省事，但坑不少。
避坑指南：我曾经在一个金融项目里，为了省事全用 Agentless 采集网络设备日志。结果某次安全事件，日志延迟了 15 分钟才拉回来——差点背锅。从那以后，核心系统我坚持用 Agent。
2.3 日志传输协议：TCP、UDP 还是 Reliable TCP？
协议选型，说白了就是选「快」还是选「稳」。
- UDP：快，但不保证送达。适合心跳日志、监控指标，丢了也不心疼。
- TCP：稳，有重传机制。适合大部分业务日志。
- Reliable TCP（带确认的 TCP）：在 TCP 基础上加应用层 ACK。适合审计日志、交易日志——丢一条都可能出合规问题。
我一般这么定：
| 日志类型 | 推荐协议 | 原因 |
|---|---|---|
| 系统监控指标 | UDP | 允许少量丢失，追求低延迟 |
| 应用访问日志 | TCP | 需要完整，但可接受短暂延迟 |
| 数据库审计日志 | Reliable TCP | 一条都不能丢，合规要求 |
| 安全事件日志 | Reliable TCP | 丢日志等于丢证据 |
核心原则：审计日志必须用 Reliable TCP。别问为什么，问就是合规审计会查你。
2.4 日志源接入规范
日志源五花八门，不统一规范，后面解析就是灾难。我整理了一份接入 checklist，每次新接入都按这个走。
- 日志格式标准化：统一 JSON 或 CEF 格式。别用自由文本。
- 时间戳规范：必须带时区，推荐 ISO 8601。我见过太多因为时区问题导致时间线错乱的案例。
- 字段最小集：每条日志至少包含：时间、源 IP、事件类型、日志级别、原始内容。
- 日志轮转策略：按大小或时间切分，避免单文件过大。
- 采集频率：实时采集，延迟不超过 30 秒。
下面是一个标准的 JSON 日志示例：
{
"timestamp": "2025-03-21T14:32:10.123+08:00",
"source_ip": "192.168.1.100",
"event_type": "login_failed",
"log_level": "WARN",
"message": "User admin login failed from 10.0.0.5",
"hostname": "web-server-01"
}
小技巧：接入前先做一次「日志源健康检查」。我曾经帮一个团队排查，发现 30% 的日志源时间戳格式不统一——改完以后，分析效率直接翻倍。
嗯，采集架构这块，核心就这些。记住一句话：采集稳了，分析才靠谱。