OpenAI 如何将 Fluent Bit CPU 使用率降低 50%，释放 3 万核计算资源
OpenAI 每天处理超过 9 PB 的日志，对 AI 研究和推理生产至关重要。所有工作负载都运行在 Kubernetes 上，每个节点运行多个 DaemonSet：Fluent Bit、OpenTelemetry Collector、DataDog Agent 等。由于 OpenAI 快速增长，一些日志工作负载向不同存储发送了重复日志，OpenAI 技术人员 Fabian Ponce 称之为“DaemonSet 大杂烩”。
最繁忙的主机开始触发 Linux CFS 限速。日志 DaemonSet 被限速时，日志会丢失。对于 AI 研究来说，每条日志都可能包含重要信息，丢失不可接受。团队无法增加更多 CPU，基础设施已满负荷。
解决方案：用 perf 找根因
发现
Ponce 加入可观测性团队第一个月，使用 Linux 性能分析工具 perf 对 Fluent Bit 部署进行分析。
报告显示异常：CPU 使用时间大部分没用在字符串处理上，反而是 stat 系统调用耗费最多。问题出在 Fluent Bit 如何监控日志文件。默认用 Linux 的 inotify API 监测文件变化，但 inotify 事件不包含写入数据量，Fluent Bit 每次事件后立即调用 stat 获取文件大小，更新数据库，判断读取进度和可读数据量。
在 OpenAI 规模下，容器逐行刷新日志，引发系统调用风暴，成千上万次无意义的 stat 调用，线程高速占用 CPU。
实施
解决办法非常简单：完全关闭 inotify，改为基于 stat 的轮询，只需一行配置改动：inotify: false。Ponce 首次上线测试集群后，CPU 使用率立刻降低 50%。
团队随后在全集群推广此改动，针对频繁写日志的容器，stat 轮询频率最高达每秒一次。即使如此，系统调用次数也比 inotify 少几个数量级。
“我们让 Fluent Bit CPU 使用率降低 50%，为整个研究和应用基础设施释放了大量容量。这就是 CNCF 生态的力量，深刻理解工具，才能实现全局优化。”
— Fabian Ponce，OpenAI 技术成员
由于 CPU 是 Kubernetes 节点共享资源，减少 Fluent Bit 资源占用提升了所有共址工作负载性能。这 3 万核资源重新投入 ChatGPT 推理和 AI 实验。
贡献回馈社区
关闭 inotify 解决了燃眉之急，但长远来看更好的方案是“节流” stat 调用。Ponce 说：“Fluent Bit 其实只需要个时间窗口，收到 inotify 事件后，安排在 500 毫秒内执行一次 stat。”这种防抖方式既保留了 inotify 的响应灵敏性，又避免系统调用爆炸。
和 Fluent Bit 维护者沟通后，他们对该改进持开放态度。OpenAI 计划将此功能贡献到上游，让整个 CNCF 社区受益。
影响：基于 CNCF 打造的 PB 级日志平台 OLogs
OpenAI 的优化支持了 OLogs 平台，内部日志日处理量超 9 PB，完全基于 CNCF 项目：
- Kubernetes 负责编排，保证可扩展性和可靠性。
- Fluent Bit 聚合日志，添加 Kubernetes 元数据，根据动态配置抽样，转换成 OLogs 格式。
- Envoy 负责路由存储，未来分片时关键角色。
- OpenTelemetry 标准化可观测性堆栈。
平台提供 OLogs 查询语言（OQL）快速检索，复杂分析支持完整 SQL。团队还在开发“宽事件”存储高基数数据，传统时序数据库难以承载。
关键成果
- Fluent Bit CPU 使用率全集群降低 50%
- 释放 3 万核 CPU 资源用于 AI 工作负载
- 日处理日志超 9 PB，性能无下降
- 过载主机 Linux CFS 限速事件大幅减少
- 消除因限速导致的主要日志丢失，恢复管道稳定性
- 降低资源争用，提升节点整体性能
- 计划贡献改进给 CNCF 社区
总结与展望
“如果有系统 root 权限，15 分钟就能跑 perf。” Ponce 强调。这次优化不需要 PB 级规模，只要日志量与持续刷写的行为合适，就能带来显著收益。
极端规模才暴露的问题，解决后能提升整个社区的工具质量。
“云时代带来了更多分布式系统思维，有助于可靠性和扩展，但硬件层面的优化知识不可替代。”
— Fabian Ponce，OpenAI 技术成员
OpenAI 正在减少第三方可观测性成本，将更多能力内建于 CNCF 堆栈。团队从 7-8 人扩大到 16 人，成为基于 CNCF 的数据基础设施团队。
