Cloudflare日志管道概览

💡 原文英文,约1600词,阅读约需6分钟。
📝

内容提要

Cloudflare的可观察性平台团队负责管理收集来自Cloudflare基础设施各个服务的调试日志的日志管道。这些管道使用Go的zerolog和C++的KJ_LOG等日志库将日志打印到stdout/stderr流中。然后,日志由systemd-journald和syslog-ng收集,它们在转发日志到核心数据中心之前应用速率限制并添加常见字段。通过将日志复制到两个不同的数据中心实现冗余。Kafka用于缓冲日志,以便轻松添加消费者并容忍瞬时故障。然后,日志存储在ElasticSearch/Logstash/Kibana(ELK)和Clickhouse集群中。未来的项目包括改进多租户功能,迁移到Open Telemetry,实现尾采样和更好地平衡Kafka集群。

🔎

延伸解读

高可用设计:双数据中心与log-x机制

Cloudflare的日志管道通过将日志同时发送到位于美国和欧洲的两个核心数据中心来实现冗余,任一数据中心故障都不会导致日志丢失。此外,当某个数据中心与核心数据中心断开连接时,syslog-ng会将日志重复发送到可用接收端,并标记为发往另一接收端,接收端将其存入死信队列(DLQ),再通过Kafka Mirror Maker同步到不可达的数据中心。这种log-x机制确保了即使发生瞬时故障,每个核心数据中心仍能保有完整的日志副本。

Kafka缓冲:容忍故障与分区策略的权衡

Kafka在日志管道中充当缓冲区,使得新的消费者可以随时加入而无需修改管道,并且能够容忍消费者长达八小时的故障而不丢失数据。然而,由于syslog协议的时间戳精度限制,Cloudflare使用主机名和服务名作为分区键来保证同一服务在同一机器上的日志顺序。这可能导致不同机器上同一服务的日志速率差异很大,从而造成Kafka分区不平衡。团队正在迁移到Open Telemetry Logs以解决这一问题。

存储后端:ELK与Clickhouse的分工与演进

日志最终存储在两个后端:一个90节点的ElasticSearch集群和一个10节点的Clickhouse集群。ElasticSearch集群中,节点分为master、data和HTTP三种角色,其中HTTP节点专门处理查询请求,通过积极缓存显著降低查询时间。Clickhouse集群目前提供另一种查询接口,允许工程师使用SQL和Bash脚本访问相同的日志,同时团队正在将其迁移为 primary 存储。这种双后端策略为工程师提供了灵活性,并支持渐进式迁移。

未来方向:多租户、OpenTelemetry与尾采样

Cloudflare计划在未来改进日志管道的多个方面:增强多租户能力,为工程师提供更好的资源洞察;将syslog-ng管道迁移到OpenTelemetry;实现尾采样以替代当前的概率头采样;以及更好地平衡Kafka集群。这些项目旨在应对不断增长的可观测性需求,提升工程师体验,并优化资源利用。文章未给出具体时间表,但表明团队正在积极规划这些改进。

❓

Q&A

Cloudflare的日志管道是如何实现高可用和冗余的?

Cloudflare通过将日志复制到两个不同的核心数据中心(一个在美国,一个在欧洲)来实现冗余。每个数据中心的接收器将日志插入Kafka。如果某个数据中心暂时无法连接,syslog-ng会将日志发送两次给可用的接收器,第二份标记为发往另一个接收器,并进入死信队列(DLQ),然后通过Kafka Mirror Maker同步到不可达的数据中心,从而确保每个核心数据中心都有完整的日志副本。

Cloudflare日志管道中Kafka的作用是什么?

Kafka用于缓冲日志,提供两个主要好处:一是允许在不修改现有系统的情况下轻松添加新的日志消费者;二是能够容忍消费者的瞬时故障而不丢失数据,最多可承受8小时的消费者中断。此外,Kafka还通过分区保证同一主机上同一服务的日志顺序。

Cloudflare的日志存储使用了哪些后端?各自有什么特点?

Cloudflare使用两个存储后端:ElasticSearch/Logstash/Kibana (ELK) 栈和Clickhouse集群。ELK集群有90个节点,分为master、data和HTTP节点,HTTP节点专门处理查询以提高缓存效率。Clickhouse集群有10个节点,正在迁移为主存储,提供SQL和Bash脚本接口,而ELK提供Lucene查询接口。

Cloudflare日志管道未来有哪些改进计划?

未来的项目包括:改进多租户功能并提供更好的资源洞察;将syslog-ng管道迁移到Open Telemetry;实现尾采样以替代当前的概率头采样;更好地平衡Kafka集群。

Cloudflare的日志管道如何处理高吞吐量场景?

对于高吞吐量服务,Cloudflare提供了绕过journald的替代路径:syslog-ng监听一个Unix Domain Socket,服务可以直接写入该socket,避免journald的全局排序限制,从而提高吞吐量。这种方式需要手动创建管道并打开socket,通常只用于有需要的服务。

为什么Cloudflare的日志管道被称为“journal管道”?

因为Cloudflare使用systemd管理大多数服务,服务的stdout/stderr流通常被管道到systemd-journald,由它处理本地机器日志。journald的RateLimitBurst和RateLimitInterval配置提供了控制服务输出的简单方法,因此日志管道最初被称为“journal管道”,尽管现在已扩展到包括其他来源。

🏷️

标签

➡️

继续阅读