什么是日志聚合（Log Aggregation）？原理、步骤与观测云落地实践
日志聚合是把分散在主机、容器和云服务中的日志收集并集中存储的过程。本文讲解日志聚合的定义与五步落地流程，并给出基于观测云 DataKit 采集、Pipeline 解析、多索引存储的完整实践路径。
日志聚合（Log Aggregation）是指从生产环境的各个应用、主机、容器和网络设备中收集日志，集中存储到统一平台以便检索、分析和监控的过程。 它是日志管理中最基础的一环：先把散落的日志"收拢到一处"，后续的查询、告警、可视化才有可能实现。
单机单应用时登录服务器翻日志尚可应付；一旦系统具备一定规模，碎片化方式会迅速失效。
核心要点速览
- 日志聚合是把分散在各处的日志收集并集中存储到统一平台的过程，是日志管理的基础环节。
- 五步落地：盘点来源 → 选定目的地 → DataKit 采集 → Pipeline 清洗标准化 → 多索引集中存储。
- DataKit 四种采集方式：磁盘文件、容器 stdout、TCP/UDP/HTTP 远程推送、Sidecar（logfwd）。
- 成本控制三板斧：黑名单过滤、精准 Pipeline 规则、多索引差异化存储策略。
为什么日志聚合必不可少
设想线上故障现场：服务跑在十几台机器上，你逐一 SSH 登录、手工 grep 拼凑故障全貌——等定位到根因，用户早已流失。
而完成聚合的团队面对的是另一番景象：所有日志实时汇入一个平台，一次查询横跨全部服务，快速锁定异常时间点与关联服务。差距不只是效率，更是关键时刻避免遗漏与人为失误的能力。此外，只有集中后的日志才能支撑趋势可视化与告警，让团队从"事后救火"转向"事前预防"。
日志聚合五步落地（观测云路径）
第一步：盘点日志来源
先想清楚哪些日志对排障、审计、分析有价值：
- 应用日志（业务服务输出）
- Web 服务器日志（Nginx、Apache）
- 容器与 K8s 平台日志
- 数据库与中间件日志（MySQL 慢日志、Redis 等）
- 主机系统日志与安全日志
- 云服务日志
不必一次收齐，优先覆盖核心业务链路，再逐步补全。
第二步：确定集中存储的目的地
日志最终要有个"家"。注册观测云并创建工作空间后，日志数据即可统一汇入；后续可按业务线在日志 > 索引中创建多索引做数据分流（如按业务、环境、重要程度分索引，各自配置存储时长）。
第三步：用 DataKit 采集日志
观测云的开源采集器 DataKit 覆盖四类采集场景，可按环境组合使用 ：
| 采集方式 | 适用场景 | 要点 |
|---|---|---|
| 磁盘文件采集 | 主机/虚机上写文件的传统应用 | 在 logging.conf 配置文件路径（支持通配符）；只采集 DataKit 启动后有更新的内容 |
| 容器 stdout 采集 | K8s 环境 | 应用日志输出到 stdout 即可；可按镜像名定点采集，或用 Pod Annotation 染色标记 |
| 远程推送 | 应用直推/第三方平台接入 | 支持 TCP/UDP/HTTP；如 Java log4j、Python SocketHandler 均可直发 |
| Sidecar（logfwd） | K8s 中无法改 stdout 的应用 | Pod 内挂 logfwd 边车捞取磁盘日志并推送，自动附加 Pod 名称、namespace 等属性 |
主机环境安装 DataKit 后，复制 conf.d/samples/logging.conf.sample 为 logging.conf，配置 logfiles、source、service 三项，重启即生效 。
第四步：Pipeline 解析、过滤与富化
来自不同系统的日志格式千差万别，需要"标准化"处理。观测云 Pipeline 支持两种执行位置：本地 Pipeline（DataKit 在宿主机上直接处理，敏感数据不出机）和中心 Pipeline（平台侧处理）。典型动作包括：
- 字段提取：用切割脚本从原始文本提取字段；务必提取
time（日志时间）与status（日志级别），未提取时 time 取系统当前时间、status 置为 公开资料未说明 ； - 脱敏与丢弃：用
cover()按范围遮蔽、replace()按正则替换、drop()丢弃指定字段或整条日志，从源头保护敏感信息 ； - 降噪过滤：配置黑名单过滤无效日志，直接减少写入量与存储成本；
- 多行切割：对堆栈跟踪、MySQL 慢日志等多行日志配置切割规则，保证一条日志完整聚合。
需要注意 Pipeline 的性能开销：规则越复杂、正则越重，CPU 消耗越高。观测云官方测试显示，针对具体日志格式优化后的单一匹配 Pipeline 处理 10 万行日志仅需约 4.4 秒，而通用完整版需 43 秒——建议按来源分别编写精准规则 。
第五步：集中存储与留存策略
日志入库后按预设规则自动分拣到匹配的日志索引；每个索引可配置差异化的数据存储策略，到期自动清理。需要长期留存的日志可通过数据转发归档至对象存储或外部系统，满足审计与回溯需求。
日志聚合的常见挑战与对策
| 挑战 | 典型后果 | 观测云对策 |
|---|---|---|
| 日志量突增 | 摄入延迟、成本飙升 | 采集端黑名单过滤 + Pipeline 降噪 |
| 敏感数据泄露 | 合规风险 | 本地 Pipeline 脱敏，敏感值不出宿主机 |
| 字段格式混乱 | 无法关联分析 | Pipeline 统一切割 + 多索引按规则分流 |
| 历史日志回溯难 | 审计缺失 | 数据转发长期归档，需要时可直接查询 |
| 采集链路不可见 | 采集中断无感知 | datakit monitor 命令查看采集器运行状态 |
如何选择日志聚合方案
评估清单：生态兼容性（是否覆盖你的主机/K8s/云环境）、处理性能（Pipeline 实测吞吐）、总拥有成本（开源组件自运维 vs 托管服务）、多云适配、安全能力（脱敏/权限）。DataKit + 观测云的组合把"采集-解析-存储-检索"整合为一体化管道，避免了多套开源组件拼接的集成与运维成本。
常见问题（FAQ）
Q：日志聚合和日志管理有什么区别？
聚合聚焦"收集与集中"，是日志管理的子集；管理还涵盖解析、检索、告警、留存治理等完整生命周期。
Q：日志聚合等于日志采集吗？
不完全等于。采集只负责"拿到日志"，聚合还包括解析、标准化、过滤和集中存储——在观测云里，DataKit 负责前者，Pipeline 与索引负责后者。
Q：应用可以直接把日志推送到平台吗？
可以。应用可通过 TCP/UDP/HTTP 远程推送给 DataKit，无需落盘；但建议关键业务仍落盘一份作为兜底，防止网络抖动导致日志丢失。
Q：历史存量日志会被采集吗？
磁盘文件采集方式只采集 DataKit 启动后有更新的文件；DataKit 停止期间的空窗日志也不会补采。对历史回溯有强需求的场景，建议提前规划数据转发归档。
总结
日志聚合是生产级日志体系的第一步：盘点来源、DataKit 采集、Pipeline 清洗标准化、多索引集中存储。聚合质量决定了后续检索、告警、可视化的一切上限。
