【可观测性工程】日志管道：Fluent Bit、Vector、Logstash、Cribl 的取舍
内容提要
本文对比了四种日志管道工具：Fluent Bit、Vector、Logstash 和 Cribl。从采集、解析、丰富、过滤、路由五个阶段分析其架构与配置，并比较了 Fluent Bit 与 Vector 的资源占用。重点讨论了背压处理、Kubernetes DaemonSet 部署模式，并给出选型建议：K8s 默认用 Fluent Bit，复杂变换用 Vector，遗留系统用 Logstash，商业优化选 Cribl。
延伸解读
背压策略：ERROR 不丢，INFO 可丢
文章强调背压处理是日志管道可靠性的核心。推荐对 ERROR/WARN 使用 disk buffer 并设置上限和告警，INFO 可 drop，DEBUG 默认不采。这避免了内存 buffer 导致 OOM 或磁盘写满的风险。实际部署时，需将 Fluent Bit 的 storage.total_limit_size 与 Kubernetes emptyDir 的 sizeLimit 对齐，防止节点磁盘被日志占满。
Fluent Bit 与 Vector 的假设模型对比
文章给出了一个假设模型对比：在 5000 行/秒的 nginx 日志负载下，Vector 的 CPU 占用（0.4–0.7 core）低于 Fluent Bit（0.8–1.2 core），但内存占用略高（120–200 MB vs 80–150 MB）。作者明确声明这不是 benchmark，仅用于数量级选型。若变换链复杂（如超过 10 个 regex），Vector 优势更明显；若只是 tail 到 Loki，Fluent Bit 足够。建议在自身环境用相同日志样本验证。
K8s DaemonSet 部署的坑点
文章列出了多个 Kubernetes 日志采集的常见坑点：Refresh_Interval 默认值过大会导致 tail CPU 尖刺；disk buffer 无上限会写满节点磁盘；禁止双 DaemonSet tail 同一文件以避免重复和 inode 竞争；multiline 日志需先 merge 再 json parse；Loki label 高基数问题（如 pod_name 作 label 需谨慎）；RBAC 权限不足会导致 metadata 为空。这些坑点直接影响日志的完整性和查询效率。
Q&A
日志管道通常分为哪五个阶段？
日志管道通常分为五个阶段：采集（Collect）、解析（Parse）、丰富（Enrich）、过滤（Filter）和路由（Route）。
Fluent Bit 和 Vector 在资源占用上有何区别？
根据假设模型，Fluent Bit 的 CPU 占用约为 0.8-1.2 核，内存占用 80-150 MB；Vector 的 CPU 占用约为 0.4-0.7 核，内存占用 120-200 MB。Vector 在 CPU 上更优，而 Fluent Bit 内存占用更低。
在 Kubernetes 环境中，默认推荐使用哪种日志管道工具？为什么？
在 Kubernetes 环境中，默认推荐使用 Fluent Bit，因为它生态成熟、有现成的 Helm Chart、内存占用低，并且是 CNCF 毕业项目。
Logstash 适合什么场景？
Logstash 适合遗留系统，特别是已有大量 Grok 正则表达式的场景，因为迁移成本低。但它的 JVM 架构导致内存占用较高（heap 1GB+）。
Cribl Stream 的主要作用是什么？
Cribl Stream 是一个商业日志路由器，主要用于在将数据发送到 Splunk 或 Elasticsearch 之前进行过滤和瘦身，以优化许可证成本。它不是采集器，常与 Fluent Bit 或 Beats 组合使用。
如何处理日志管道中的背压问题？
处理背压的策略包括：使用磁盘缓冲区（disk buffer）实现 at-least-once 语义，设置缓冲区上限并告警；对于 ERROR/WARN 日志使用磁盘缓冲，INFO 可丢弃，DEBUG 默认不采集；也可以阻塞输入将背压传递给应用，但可能拖慢业务。
在 Kubernetes 中部署 Fluent Bit 作为 DaemonSet 时，有哪些注意事项？
注意事项包括：设置资源请求和限制（如内存 512Mi、CPU 1 核）；使用 tolerations 允许调度到所有节点；挂载 /var/log 和存储目录；设置 emptyDir 的 sizeLimit 与 Fluent Bit 的 storage.total_limit_size 对齐；使用 priorityClassName 防止被驱逐。
日志管道中常见的工程坑点有哪些？
常见坑点包括：Refresh_Interval 设置过大导致 CPU 尖刺；磁盘缓冲区无上限导致节点磁盘满；双 DaemonSet tail 同一文件导致重复和 inode 竞争；multiline 顺序错误导致解析失败；Loki label 高基数问题；OTel 和 Fluent Bit 双缓冲只设一层硬上限；字符集未声明导致乱码；RBAC 权限不足导致 metadata 为空；log rotation 丢行；Kafka output 未设置 acks=all 导致静默丢数据。
