Cloudflare 升级日志管道：从 syslog-ng 迁移到 OpenTelemetry Collector

Cloudflare 是一家互联网基础设施和安全公司，最近通过将其日志管道从 syslog-ng 迁移到 OpenTelemetry Collector，显著升级了其日志处理能力。这一日志管道是 Cloudflare 最大的数据管道之一，负责从其网络中的每台服务器收集和处理每秒数百万条日志事件，是其关键基础设施的重要组成部分。

迁移背景与动机

Cloudflare 的工程师 Colin Douch 和 Jayson Cena 在一篇博客文章中详细介绍了此次迁移的背景和动机，主要包括以下几点：

1. 语言兼容性：OpenTelemetry Collector 使用 Go 语言编写，而 syslog-ng 使用 C 语言。Go 语言对 Cloudflare 的工程团队更为熟悉，这使得更多工程师能够参与日志系统的改进。
2. 与内部库的集成更简便：将 syslog-ng 与 Cloudflare 的内部后量子加密库集成存在挑战，而基于 Go 的 OpenTelemetry Collector 简化了这一过程。
3. 增强的指标支持：OpenTelemetry Collector 支持 Prometheus 指标，使团队能够收集更详细的收集器性能数据。
4. 统一的遥测基础设施：Cloudflare 已经在部分跟踪基础设施中使用了 OpenTelemetry Collector。将不同类型的遥测数据整合到一个系统中，减少了工程团队的复杂性。

自定义组件与部署策略

为满足特定需求并保持与现有系统的兼容性，工程师开发了多个自定义组件，包括：

• 用于 Cloudflare 自有日志格式的自定义导出器。
• 支持额外输出格式的修改文件导出器。
• 将外部 JSON 数据整合到日志条目中的处理器。
• 用于防止单个服务淹没日志管道的速率限制器。

在部署过程中，Cloudflare 采用了两种策略：

• 核心数据中心：由于配置复杂且工作负载多样，采用谨慎的手动部署方式。
• 边缘数据中心：配置较为简单且同质化，采用逐步推出并密切监控的方式。

迁移过程中的挑战与解决方案

迁移过程中遇到了一些挑战：

• 故障转移问题：新导出器最初未能检测到与主日志服务器的连接问题，导致日志积压并影响部分服务。
• 日志收集中断：在停止 syslog-ng 并启动 OpenTelemetry Collector 的过渡期间，日志收集出现短暂中断，影响了以阻塞模式写入日志的部分服务。

为解决这些问题，Cloudflare 采取了以下措施：

• 在自定义导出器中实现更严格的超时机制。
• 修改故障转移行为。
• 调整部署流程以最小化过渡期间的停机时间。

未来计划

Cloudflare 计划实施更复杂的日志采样技术（如尾部采样），并将其部分自定义组件贡献给开源社区。

其他公司的 OpenTelemetry 应用

Cloudflare 并非唯一采用 OpenTelemetry 的公司，其他大型企业如 Shopify、Splunk、Google 和 GitHub 也在使用该技术：

• Google：在 Google Kubernetes Engine 和 Google Compute Engine 中使用 OpenTelemetry Collector，并替换 Cloud Monitoring 和 Cloud Trace 中的 OpenCensus SDK。
• Splunk：在内部采用 OpenTelemetry，并将其用于基础设施监控，同时积极参与项目的开发。
• Shopify：将跟踪收集基础设施迁移到 OpenTelemetry，并在收集器中实现 PII 脱敏、采样和跨度重命名。
• GitHub：采用 OpenTelemetry 标准化其遥测实践，使用 OTLP（OpenTelemetry 协议）作为标准格式，并利用自动检测功能为 Ruby 和 Postgres 添加分布式跟踪。

GitHub 相信，通过 OpenTelemetry 的开放标准，能够自动推导出额外的信号（如自动计算指标并将跟踪事件转换为详细日志），并积极为 OpenTelemetry 项目做出贡献，以惠及更广泛的技术社区。