日志聚合的核心目标只有三个：收得全、传得稳、查得快。围绕这三个目标，把链路拆成采集、传输、存储与检索四层，每层只解决一个问题，系统才容易扩展和排障。
一、先明确设计约束
动手前先回答几个问题，它们直接决定选型：
- 日志量级：每天 GB 级还是 TB 级？
- 实时性要求：秒级告警还是离线分析即可？
- 保留周期：7 天、30 天还是更长？
- 查询模式：按关键词全文检索，还是按字段聚合统计？
量级小、查询简单时，单机方案（如一台日志服务 + 本地磁盘）完全够用，不必上复杂集群。
二、采集层：把日志变成结构化事件
采集层的关键不是“能收”，而是“收得对”。
- 统一输出格式：优先让应用直接输出 JSON，字段包含时间戳、服务名、实例标识、级别、trace_id、消息体。结构化日志能省掉大量正则解析成本。
- 选择采集方式：
- 容器环境：以 DaemonSet 方式在每个节点部署采集代理，挂载宿主机日志目录，自动发现容器日志文件。
- 虚拟机/物理机：在每台机器安装采集代理，读取文件并做多行合并（如 Java 异常栈）。
- 无代理方案：应用直接把日志推送到采集端点，适合无法安装代理的场景，但会耦合业务代码。
- 控制采集副作用：设置文件读取位置记录（offset），避免重启后重复采集；对高流量服务做采样或限流，防止采集本身拖垮业务。
三、传输层：缓冲与背压是稳定性的关键
采集与存储之间必须有一个缓冲层，否则存储抖动会直接导致丢日志。
- 消息队列做削峰：日志写入队列，消费端按自身能力拉取。队列积压时，采集端可降级为本地磁盘缓存，恢复后补传。
- 批量与压缩：按大小或时间窗口批量发送，并启用压缩（如 gzip），能显著降低网络开销。
- 至少一次投递：多数日志场景可接受少量重复，换取不丢数据；检索端按唯一 ID 去重即可。
- 多副本与分区：队列按服务名或租户分区，避免单个热点服务影响全局；关键链路开启多副本。
四、存储与检索层：按查询模式选引擎
日志数据的特点是写入量远大于查询量，且查询多为时间范围 + 关键词过滤。
- 倒排索引型：适合全文检索与复杂条件过滤，写入成本较高，适合近期热数据。
- 列式存储型：适合按时间分区的大规模聚合分析，压缩率高，适合冷数据与报表。
- 分层存储：热数据放索引引擎（如近 7 天），冷数据转对象存储，查询时按时间路由。
建索引时注意：
- 时间字段必须作为主分区键，查询优先带时间范围。
- 高基数字段（如 trace_id）可只存不索引，或使用轻量索引。
- 明确字段类型，避免全部按文本处理导致索引膨胀。
五、落地顺序建议
不要一次性搭全链路，按下面顺序推进风险最低：
- 先统一应用日志格式，输出结构化 JSON。
- 单节点部署采集代理 + 存储，跑通“采集→检索”最小闭环。
- 数据量增长后，在采集与存储之间插入消息队列。
- 最后再做冷热分层、采样策略和告警规则。
六、常见坑
- 只采集不定义保留策略，磁盘很快被写满。
- 时间戳用本地时间且不带时区，跨区域排查时顺序错乱。
- 采集代理与业务争抢 CPU/IO，未设置资源上限。
- 索引字段过多，写入放大严重，查询反而变慢。
分层设计的价值在于：每一层都可以独立替换和扩容。先把格式和缓冲做对，后面的存储选型只是可替换的实现细节。