使用 ClickHouse 做日志分析

最新推荐文章于 2025-11-23 15:36:58 发布

原创

最新推荐文章于 2025-11-23 15:36:58 发布 · 2.1k 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#clickhouse

Cloudflare的日志量急剧增加，使用Elasticsearch集群面临Mapping爆炸、多租户支持不足等问题。为解决这些问题，该公司决定用ClickHouse构建新日志管道，介绍了ClickHouse的功能及插入器、批量大小等优化方法，迁移后在存储和查询性能上有显著改善。

原作：Monika Singh & Pradeep Chhetri

这是我们在 Monitorama 2022 上发表的演讲的改编稿。您可以在此处找到包含演讲者笔记的幻灯片和此处的视频。

20231007162314

当 Cloudflare 的请求抛出错误时，信息会记录在我们的 requests_error 管道中。错误日志用于帮助解决特定于客户或网络范围的问题。

我们，站点可靠性工程师 (SRE)，负责管理日志平台。我们已经运行Elasticsearch集群很多年了，这些年来日志量急剧增加。随着日志量的增加，我们开始面临一些问题。查询性能慢、资源消耗高等。我们的目标是通过提高查询性能并提供经济高效的日志存储解决方案来改善日志消费者的体验。这篇博文讨论了日志记录管道的挑战以及我们如何设计新架构以使其更快且更具成本效益。

在我们深入探讨维护日志管道的挑战之前，让我们先了解一下日志的特征。

日志的特征

20231007162651

不可预测：当今世界，微服务数量众多，集中式日志系统将收到的日志量非常难以预测。日志体量估算如此困难的原因有多种。主要是因为新应用程序不断部署到生产中，现有应用程序会自动扩展或缩小以满足业务需求，或者有时应用程序所有者启用调试日志级别并忘记将其关闭。

上下文：对于调试问题，通常需要上下文信息，即事件发生之前和之后的日志。单个日志行几乎没有帮助，通常，是一组日志行有助于构建上下文。此外，我们经常需要将多个应用程序的日志关联起来以绘制全貌。因此，必须保留日志在数据源处填充的顺序。

写入密集型：任何集中式日志系统都是写入密集型的。超过 99% 的已写入日志从未被读取。它们占用空间一段时间，并最终被保留策略清除。剩下的不到1%的被读取的日志非常重要，我们不能错过它们。

日志管道

与大多数其他公司一样，我们的日志记录管道由生产者、路由转发器、队列、消费者和存储组成。

20231007163358

在 Cloudflare 全球网络上运行的应用程序（生产者）生成日志。这些日志以 Cap’n Proto 序列化格式在本地写入。 Shipper（内部解决方案）通过流将 Cap’n Proto 序列化日志推送到 Kafka（队列）进行处理。我们运行 Logstash（消费者），它从 Kafka 消费并将日志写入 ElasticSearch（数据存储）。然后使用 Kibana 或 Grafana 可视化数据。我们在 Kibana 和 Grafana 中内置了多个仪表板来可视化数据。

Cloudflare 的 Elasticsearch 瓶颈

在 Cloudflare，我们多年来一直运行 Elasticsearch 集群。多年来，日志量急剧增加，在优化 Elasticsearch 集群以处理此类量时，我们发现了一些限制。

Mapping 爆炸

20231007163724

Mapping 爆炸是 Elasticsearch 众所周知的局限性之一。 Elasticsearch 维护一个映射，决定如何存储和索引新文档及其字段。当此映射中的键太多时，可能会占用大量内存，从而导致频繁的垃圾回收。防止这种情况的一种方法是使 schema 严格，这意味着任何不遵循此严格 schema 的日志行最终都会被删除。另一种方法是使其成为半严格的，这意味着不属于