为什么要集中
一次安全事件通常横跨多个来源：认证在操作系统、操作在应用、访问在负载均衡、结果在数据库。日志留在各自设备上时，排查要逐台登录、时间还对不上。集中采集把产生、传输、解析、存储、检索串成一条链路，让「按请求标识或账号一次查全」成为可能，同时也让日志具备离开执行者控制的前提，为防篡改打基础。
基本信息
| 采集对象 | 操作系统、数据库、网络设备、中间件、应用、云 API 调用日志 |
|---|---|
| 传输方式 | Syslog（TCP 或 TLS）、日志代理、云日志服务 |
| 解析要求 | 时间戳规范化、字段标准化、来源标识唯一 |
| 存储分层 | 热存供检索、冷存归档、关键日志进防篡改层 |
| 主要风险 | 丢日志、时间不准、来源混杂、检索无法结构化 |
典型使用场景
- 跨主机检索：一次查清某个账号在全部系统上的动作
- 合规集中留存：按保存期要求长期保存审计相关日志
- 关联分析：把登录、提权、配置变更串成完整时间线
- 网络设备日志：高流量设备日志量大，需采样与短存策略
- 多云与混合环境：统一接入格式，避免每个云各自一套检索方式
链路上各环节要点
| 环节 | 要点 | 常见问题 |
|---|---|---|
| 产生 | 本地先落盘缓冲，再转发 | 只转发不落盘，网络中断即丢日志 |
| 传输 | 优先 TCP 或 TLS，避免纯 UDP | UDP 拥塞时静默丢包且无感知 |
| 解析 | 时间戳统一为带时区格式 | 各设备时间不准导致事件顺序错乱 |
| 存储 | 热冷分层，按合规要求设保存期 | 只留短周期，事后无法取证 |
| 检索 | 按主体、对象、请求标识等字段可查 | 只存自由文本，无法结构化查询 |
| 告警 | 关键动作实时告警，其余按需 | 全量告警造成疲劳，关键被淹没 |
采集与转发示意
采集与转发示意
# 本地写入并转发：先落盘，转发失败也不丢本地副本
*.* /var/log/all.log; @@logserver.example.net:514 # 单 @ 为 UDP，双 @@ 为 TCP
# 来源标识不可省：多主机汇聚后必须能区分谁发的
$template Central,"%TIMESTAMP% %HOSTNAME% %syslogtag% %msg%\n" # 统一模板便于解析
# 时间同步是前提：时钟漂移会让跨源关联分析直接失效
chronyc tracking # 检查偏移量，超过阈值先修时间再谈日志
# 大流量设备的策略：采样入库、完整日志短周期留存时间源统一是集中采集的隐藏前提。多台设备时钟相差几分钟，关联分析就会把先后顺序搞反，判断「改动导致故障」这类结论会整体失效。
采集通道本身也是攻击面：未鉴权未加密的转发可被伪造或注入假记录。跨网络传输要加密，接收端要校验来源，避免日志库被污染。