日志源与采集策略：云平台日志类型与采集架构设计
好，咱们接着聊。上一章我们把合规审计的全局框架搭起来了，这一章要落地了——日志从哪来？怎么采？
说白了，没有日志，审计就是空谈。但云上的日志类型五花八门，采集方式也各有千秋。我见过不少团队，一开始图省事，全用Agentless一把梭，结果发现数据库审计日志根本拿不全；也有人反过来，所有日志都装Agent，把业务服务器搞得性能下降。嗯，这里面的门道，咱们得掰扯清楚。
一、云平台日志的三大主力类型
我个人习惯把云平台日志分成三类：操作审计日志、访问日志、数据库审计日志。这三类日志，覆盖了“谁在管、谁在用、数据怎么动”三个核心维度。
1. 操作审计日志（CloudTrail / ActionTrail）
这类日志记录的是对云资源的管控操作。比如谁创建了一台ECS、谁修改了安全组规则、谁删除了一个OSS Bucket。
- 典型场景：合规审计要求“所有对云资源的变更必须可追溯”。
- 关键字段：操作时间、操作者（IAM用户/角色）、源IP、操作名称、请求参数、返回结果。
- 采集方式：云平台通常提供默认的日志记录服务（如AWS CloudTrail、阿里云ActionTrail），支持自动投递到对象存储或日志服务。
2. 访问日志（ALB/Nginx/S3访问日志）
这类日志记录的是用户或客户端对服务的访问行为。比如谁访问了你的网站、谁下载了OSS里的文件。
- 典型场景：Web应用安全监控、异常流量检测、API调用分析。
- 关键字段：请求时间、客户端IP、请求方法、URI、状态码、响应大小、User-Agent。
- 采集方式：负载均衡器（如ALB/CLB）自带访问日志功能，可以配置投递到OSS或日志服务。自建Nginx则需要通过Agent采集。
3. 数据库审计日志（RDS审计 / 自建数据库审计）
这类日志记录的是对数据库的SQL操作。比如谁执行了SELECT、谁删除了表、谁修改了数据。
- 典型场景：等保三级要求“数据库操作行为审计”，防止数据泄露。
- 关键字段：SQL语句、执行时间、客户端IP、数据库用户、影响行数、执行结果。
- 采集方式：云数据库（如RDS）通常提供审计日志功能，可以开启后投递到日志服务。自建数据库则需要安装审计插件（如MySQL Audit Plugin）或使用数据库代理。
二、日志采集架构设计：Agent vs Agentless
日志源搞清楚了，接下来就是怎么把日志从源头“搬”到审计中心。这里有两个主流流派：Agent模式和Agentless模式。说白了，一个是在服务器上装个“小兵”，一个是让云平台自己把日志送过来。
1. Agent模式
在每台需要采集日志的服务器上，安装一个日志采集Agent（如Filebeat、Logstash、Fluentd）。Agent负责读取日志文件，解析后发送到中央日志系统。
- 优点：灵活、可控。可以采集任意格式的日志，支持自定义解析规则。
- 缺点：运维成本高。需要管理大量Agent的版本、配置、升级。Agent本身也会消耗服务器资源（CPU、内存）。
- 适用场景：自建应用、传统架构、需要精细控制日志采集逻辑的场景。
2. Agentless模式
利用云平台提供的原生日志服务，直接配置日志投递。比如AWS CloudTrail自动投递到S3，阿里云SLS直接采集OSS访问日志。
- 优点：零运维。不需要安装任何Agent，云平台帮你搞定采集和传输。
- 缺点：灵活性差。只能采集云平台支持的日志类型，无法采集自定义日志。
- 适用场景：云原生架构、使用云平台标准服务（如ALB、RDS、OSS）的场景。
三、核心逻辑：一张图看懂日志采集架构
为了让你更直观地理解，我画了一张架构图。它展示了从日志源到审计中心的完整链路。
这张图的核心逻辑是：日志源 -> 采集层（Agent/Agentless） -> 传输层 -> 审计中心。你想想看，无论你用哪种采集方式，最终目的都是把日志安全、完整、实时地送到审计中心。
四、如何选择采集策略？
嗯，这里没有银弹。我一般会按以下原则来选：
| 场景 | 推荐采集方式 | 理由 |
|---|---|---|
| 云原生服务（ALB、RDS、OSS） | Agentless | 零运维，云平台原生支持，稳定可靠 |
| 自建应用（Nginx、Tomcat） | Agent | 需要自定义日志格式和解析规则 |
| 混合架构（部分云原生+部分自建） | 混合模式 | 云原生用Agentless，自建用Agent |
| 高安全要求（金融、政务） | Agent + 加密传输 | 确保日志在传输过程中不被篡改 |
五、避坑指南与个人经验
最后，分享几个我踩过的坑：
- 日志格式不统一：我曾经接手过一个项目，不同团队的日志格式五花八门，有的用JSON，有的用纯文本，有的用自定义分隔符。结果解析规则写了整整一周。所以，建议从一开始就统一日志格式，推荐JSON。
- 日志时间戳问题：不同服务器的系统时间可能不一致，导致日志时间错乱。我建议所有日志统一使用UTC时间，并在采集时加上时区信息。
- 日志丢失：Agentless模式偶尔会出现日志投递延迟或丢失的情况。我曾经遇到过，某次ALB访问日志延迟了2小时才到达。所以，建议设置告警，监控日志延迟和丢失率。
- 成本控制：日志存储成本不容小觑。我建议设置日志生命周期策略，比如热数据存7天，温数据存30天，冷数据存1年，然后自动删除。
好了，这一章的内容就到这里。日志源和采集策略是审计系统的地基，地基打牢了，后面的分析、告警、报表才能站得住脚。