Cloudflare 最近证实，在 11 月 14 日，他们发生了一起影响 Cloudflare 日志 的事件，在 3.5 小时内丢失了 55% 的日志。
该事件影响了使用该服务的大多数客户，配置错误引发了一系列系统故障，并暴露了处理意外流量激增方面的弱点。Jamie Herre、Tom Walwyn、Christian Endres、Gabriele Viglianisi、Mik Kocikowski 和 Rian van der Merwe 解释道：
通常，Cloudflare 每天向客户发送大约 4.5 万亿个单独的事件日志。尽管这只占需要处理的 50 万亿个客户事件日志总量的不到 10%，但在构建可靠且容错的系统时，它带来了独特的规模挑战。
为了提供来自全球 330 多个城市的数万台服务器的日志，Cloudflare 开发了 Logpush，这是一种 Golang 服务，旨在收集日志并将其推送到可预测的文件大小，同时根据使用情况自动扩缩。内部 Buftee 服务为每个 Logpush 作业提供了缓冲区，其中包含由区域或帐户生成的 100% 的日志。Logpush 从这些缓冲区读取日志，并将它们分批推送到各种客户配置的目的地，每天处理超过 6 亿个批次。
在这篇文章中，该团队重点介绍了 11 月 14 日出现的问题，详细介绍了所涉及的系统、所经历的故障以及 Cloudflare 计划采取的行动。作者承认：
我们进行了一个变更，以支持 Logpush 的附加数据集。这需要向 Logfwdr 添加一个新的配置，以便它知道要为这个新流转发哪些客户的日志。(......) 该系统中的一个缺陷导致向 Logfwdr 提供了一个空配置。
尽管团队在 5 分钟内发现了该缺陷并恢复了更改，但这次故障触发了 Logfwdr 中的第二个潜在错误，导致了大量的过载，从而导致 buttee 无响应。ESET 高级企业网络安全顾问 Nermin Smajic 评论道：
这一事件说明了为什么网络安全不仅仅是为了防止外部威胁，也是为了维护能够抵御复杂技术挑战的强大、有弹性的内部系统。
从错误的 Buftee 配置中恢复花了 Cloudflare 几个小时的时间。作者澄清道：
当 Logfwdr 开始为所有客户发送事件日志时，Buftee 开始在这些日志到达时为每个客户创建缓冲区 (......) 这种巨大的增长导致缓冲区增加了大约 40 倍，这不是我们提供的 Buftee 集群所能处理的。
来源：Cloudflare 博客
Airbnb 的软件工程师、《Surfing Complexity》一书的作者 Lorin Hochstein观察到：
Cloudflare 始终如一地提供了所有科技公司中质量最高的公开故障报道。他们最近一次的报告也不例外。(......) 自动化的安全机制本身增加了复杂性，而且我们在实现无缺陷的安全代码方面并不比实现无缺陷的特性代码方面做得更好。
虽然 Cloudflare 的运维团队承诺将实施更多监控预警，以确保这些特定的错误配置不会被忽略，但他们承认错误和错误配置是不可避免的。他们强调，所有 Cloudflare 系统的目标都应该是以可预测和优雅的方式应对此类问题。
Renato Losio 作为云架构师、技术主管和云服务专家拥有丰富的经验。目前，他住在柏林，作为首席云架构师远程工作。他的主要兴趣领域包括云服务和关系数据库。他是 InfoQ 的编辑，也是公认的 AWS 数据英雄。你可以在 LinkedIn 上与他联系。
原文链接：
https://www.infoq.com/news/2024/12/cloudflare-incident-log-loss/
声明：本文为 InfoQ 翻译，未经许可禁止转载。
OpenAI 史上最长宕机：自研 K8s 成“拦路虎”，导致数小时无法修复
700 多亿打水漂后，这家巨头突然舍弃了无人驾驶出租车业务！新老员工炸锅：刚还在加班、“一群傻瓜”
1620 天后，Redis 之父强势归来：开始着手修复社区裂痕，并布局下一代向量数据库
