用途：把成千上万个进程的日志汇聚到一处可搜索的位置，兼顾实时排障速度与长期保存成本。日志流水线本身是分布式系统，设计不当会在最需要它的流量尖峰时崩溃，或丢证据、拖垮被观测的应用。
适用场景：多个进程发日志且需联合搜索；需跨服务关联同一请求；日志量已超出单机 grep；或合规要求留存。不适用：单主机单服务用 journald 加日志轮转已足够；p99 延迟、错误率等数值问题属于指标而非日志；在数据证明成本合理前不要全量发送调试日志，先采样。
设计前需明确：日志量（行/秒、字节/秒，均值与峰值）、结构化还是自由文本、查询延迟需求（热索引秒级交互 vs 冷归档取证）、保留与合规（PII 脱敏、法律保留）、丢失容忍度（可否采样丢弃，还是每行都是审计证据）。
主要环节：采集（宿主机代理 Fluentd、Fluent Bit、Vector、Filebeat 读文件/stdout，或应用 SDK 直写结构化事件）；传输缓冲（代理本地磁盘缓冲直发索引器，或 Kafka 等持久日志总线吸收尖峰、解耦、支持多下游与重放）；索引存储（Elasticsearch/OpenSearch 全文本索引，RAM/磁盘开销大；Loki 仅索引标签、正文压缩，成本低但全文本弱）；保留分层（热索引加冷对象存储）。
关键要点：每行必须带关联/追踪 ID 的结构化日志；生产者与索引器之间设有限缓冲，溢出时丢弃或采样而非阻塞应用；按量级与多下游决定是否引入日志总线；激进分层，热窗口对应调试窗口；对摄取速率、投递延迟、丢弃率做计量告警。不要索引高基数自由字段，不要信任到达顺序而应按事件时间排序，不要让日志调用阻塞或拖垮请求路径。
容量估算：行/秒 × 字节/行 得摄取速率；热索引存储约等于每日字节 × 热天数 ×（1+副本+开销），冷归档约每日字节 × 保留天数并压缩约 5–10 倍，并乘以故障峰值系数。
日志行契约示例：{"ts":"2026-05-29T12:00:00.123Z","level":"ERROR","service":"checkout","host":"pod-7","trace_id":"abc123","span_id":"f9","msg":"charge failed"}。ts 为查询排序键，trace_id/span_id 用于跨服务关联，level 与 service 为有界索引标签，高基数值保留在可搜索正文字段。若命名了云厂商可查阅对应 provider 参考文件做托管服务映射；未提供则用通用方案。价格、具体配额与未提及的实现细节暂未提供。