本文介绍了使用 ClickHouse 构建日志平台的过程及相关技术决策等内容:
- 背景与动机:ClickHouse 团队相信在可能的情况下应使用自身技术,去年已用 ClickHouse 构建内部数据仓库,此次探索内部可观测性用例,以解决 ClickHouse Cloud 产生的大量日志数据存储问题,为用户提供更好服务且节省成本。
- ClickHouse 优势:其压缩比高,能在高效扩展成本的同时提供良好查询性能,如将 19 PiB 数据压缩至 1.13 PiB。在相同工作量下,成本远低于 Datadog,假设按列表价,ClickHouse 至少便宜 200 倍。
- 架构与部署:ClickHouse Cloud 在 9 个 AWS 和 4 个 GCP 区域可用,Azure 支持即将推出。日志通过 Kubernetes 标准配置捕获到
stdout
和stderr
,OpenTelemetry 代理读取并转发至 ClickHouse。虽数据主要来自 ClickHouse 服务器和 Keeper 日志,但也收集云数据平面日志。为避免监控系统与被监控系统的依赖,在每个区域运行“迷你 ClickHouse Cloud”,使用 ClickHouse Cloud 的 Kubernetes 操作符,其架构中 ClickHouse 实例在 Kubernetes 中以 pod 形式部署,由自定义操作符编排。 - 早期设计决策:不跨区域发送日志,在每个区域部署 LogHouse 集群;未采用 Kafka 队列作为消息缓冲区,因 ClickHouse 插入数据速度快,使用 Kafka 增加架构复杂度和成本;从最初的纯文本日志发送改为结构化 JSON 日志,便于提取和优化查询;选择 OpenTelemetry 作为最大设计决策,基于其社区采用度、对未来的投资以及可扩展性等因素。
- 数据处理与存储:OTel 收集器在节点上作为代理收集日志,在网关处处理后发送至 ClickHouse,采用经典代理 - 网关架构。每个网关可处理约 60K 事件/秒,内存中缓冲事件,不足 2 小时,若缓冲区满,前端事件会被丢弃。通过调整批处理大小和超时时间,确保数据在 2 分钟 SLA 内可用。利用 ClickHouse 的 Materialized Views 转换数据,将字段提取到专用列以提高查询性能。
- 数据存储与管理:不同日志有专用模式,如 ClickHouse 服务器日志模式,按
EventDate
分区,可利用 ClickHouse 的核心数据管理功能高效过期数据。 - 可视化与查询:Grafana 是推荐的可视化工具,通过自定义插件 LogHouse UI 满足特定需求,如提供特定可视化、自动限制查询范围、切换模式等。为实现跨区域查询,最初使用 Distributed 表但效率低,后利用 Grafana 和自定义插件进行区域感知路由。
- 成本分析:当前 AWS LogHouse 基础设施每月成本 12.5 万美元,包括硬件托管网关,存储 6 个月 19 PiB 数据。经计算,每 TiB 每月成本约 23.76 美元,存储 19.11 PiB 数据约每月 15 万美元,而 Datadog 相同情况下每月约 4230 美元,是 ClickHouse 的 200 倍以上。
- 未来展望:从 ClickHouse 核心数据库开发角度,期待半结构化数据相关功能如 Variant 类型的发展,以更好支持日志用例;在集成方面,继续提升 OpenTelemetry exporter 和 Grafana 插件。
总之,通过使用 ClickHouse 构建日志平台,实现了高效存储和处理大量日志数据,节省成本且提供良好服务,展示了 ClickHouse 在可观测性方面的优势。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。