使用 ClickHouse 实现可观察性
介绍
本指南旨在为希望使用 ClickHouse 构建基于 SQL 的可观察性解决方案的用户提供指导，重点关注日志和跟踪。这涉及到构建您自己解决方案的所有方面，包括数据摄取的考虑、为您的访问模式优化架构以及从非结构化日志中提取结构。
单独使用 ClickHouse 并不是一个现成的可观察性解决方案。然而，它可以作为一个高效的可观察性数据存储引擎，能够实现无与伦比的压缩率和闪电般的查询响应时间。为了让用户能够在可观察性解决方案中使用 ClickHouse，需要一个用户界面和数据收集框架。我们目前推荐使用 Grafana 来可视化可观察性信号，以及使用 OpenTelemetry 进行数据收集（这两者都是官方支持的集成）。
虽然我们推荐使用 OpenTelemetry (OTel) 项目进行数据收集，但使用其他框架和工具（如 Vector 和 Fluentd）也可以构建类似的架构（参见 示例 ）。还存在替代的可视化工具，包括 Superset 和 Metabase。
为什么使用 ClickHouse？
任何集中式可观察性存储的最重要特性是其快速聚合、分析和搜索来自不同来源的海量日志数据的能力。这种集中化简化了故障排除，使得更容易找出服务中断的根本原因。
随着用户对价格的敏感性增加，发现这些现成解决方案的成本高且不可预测，相较于它们带来的价值，成本效益和可预测的日志存储，特别是在查询性能可接受的情况下，显得尤为重要。
由于其性能和成本效益，ClickHouse 已成为可观察性产品中日志和跟踪存储引擎的事实标准。
更具体地说，以下几个因素使 ClickHouse 特别适合存储可观察性数据：
- 压缩 - 可观察性数据通常包含值来自不同集合的字段，例如 HTTP 状态码或服务名称。ClickHouse 的列式存储中，值是已排序存储的，这意味着这些数据在结合一系列专门的时间序列数据编解码器时能极大地压缩。与需要与原始数据大小相同的存储空间（通常为 JSON 格式）其他数据存储不同，ClickHouse 平均能将日志和跟踪压缩至 14 倍大小。除了为大型可观察性安装提供显著的存储节省，这种压缩还有助于加速查询，因为从磁盘读取的数据更少。
- 快速聚合 - 可观察性解决方案通常涉及通过图表视觉化数据，例如显示错误率的折线图或显示流量来源的柱状图。聚合或 GROUP BY 是驱动这些图表的基础，它们在针对问题诊断的工作流中应用过滤时也必须快速和响应。ClickHouse 的列式格式结合向量化查询执行引擎非常适合快速聚合，稀疏索引允许在响应用户操作时快速过滤数据。
- 快速线性扫描 - 虽然其他技术依赖于倒排索引来快速查询日志，但这些通常会导致高磁盘和资源利用率。虽然 ClickHouse 提供倒排索引作为附加的可选索引类型，但线性扫描是高度并行化的，并使用机器上所有可用的核心（除非另行配置）。这可能允许每秒扫描数十 GB（压缩）的数据以寻找匹配项，配合 高度优化的文本匹配操作符。
- 熟悉的 SQL - SQL 是所有工程师都熟悉的通用语言。经过超过 50 年的发展，它已经证明自己是数据分析的事实语言，同时仍然是 第三大流行编程语言。可观察性只是另一个 SQL 理想处理的数据问题。
- 分析函数 - ClickHouse 扩展了 ANSI SQL，引入了分析函数，使 SQL 查询更简单、更容易书写。这在执行根本原因分析时尤其重要，需要对数据进行切片和处理。
- 二级索引 - ClickHouse 支持二级索引，例如布隆过滤器，以加速特定查询配置。这些可以在列级别可选启用，给予用户精细的控制权，使用户能够评估成本与性能的收益。
- 开源 & 开放标准 - 作为一个开源数据库，ClickHouse 支持开放标准，如 Open Telemetry。能参与并积极贡献项目的能力十分吸引，同时避免了供应商锁定的挑战。
何时应该使用 ClickHouse 进行可观察性
使用 ClickHouse 处理可观察性数据需要用户接受基于 SQL 的可观察性。我们推荐 这篇博文 了解基于 SQL 的可观察性的历史，但总结如下：
如果您的团队：
- 熟悉 SQL（或希望学习）
- 更倾向于遵循开源标准（如 OpenTelemetry），以避免锁定并实现可扩展性
- 愿意运行一个由开源创新驱动的生态系统，从数据收集到存储和可视化
- 预计可观察性数据的管理量会从中等增长到大量（甚至非常庞大的量）
- 希望控制 TCO（总拥有成本），避免不断上升的可观察性成本
- 不想因管理成本而被迫缩短可观察性数据的保留周期
那么基于 SQL 的可观察性适合您。
如果您的情况是：
- 学习（或生成！）SQL 对您或您的团队并不吸引
- 您正在寻找一个打包的、端到端的可观察性体验
- 您的可观察性数据量太小，无法产生任何显著的差异（例如小于 150 GiB），且没有预计会增长
- 您的用例以指标为主，并需要 PromQL。在这种情况下，您仍然可以在 Prometheus 旁边使用 ClickHouse 处理日志和跟踪，并在展示层与 Grafana 统一
- 您更倾向于等待生态系统更成熟，基于 SQL 的可观察性实现更易用
日志和跟踪
可观察性用例有三个不同的支柱：日志、跟踪和指标。每一个都有不同的数据类型和访问模式。
我们目前推荐 ClickHouse 存储两种类型的可观察性数据：
- 日志 - 日志是系统中事件发生的带时间戳的记录，捕捉有关软件操作的各个方面的详细信息。日志中的数据通常是非结构化或半结构化的，可能包括错误信息、用户活动日志、系统更改和其他事件。日志对于故障排除、异常检测和理解导致系统问题的特定事件至关重要。
- 跟踪 - 跟踪捕捉请求在分布式系统中穿越不同服务的过程，详细描述这些请求的路径和性能。跟踪中的数据高度结构化，由记录请求经过的每个步骤（包括时间信息）的跨度和跟踪组成。跟踪为系统性能提供了有价值的见解，帮助识别瓶颈、延迟问题，并优化微服务的效率。
虽然 ClickHouse 可以用于存储指标数据，但在 ClickHouse 中这一支柱尚不成熟，缺少对如 Prometheus 数据格式和 PromQL 支持等特性的支持。
分布式跟踪
分布式跟踪是可观察性的重要特性。分布式跟踪（简称跟踪）映射请求在系统中的旅程。请求通常来自最终用户或应用，并在系统中传播，通常会导致微服务间的一系列操作。通过记录这个序列，并允许后续事件的关联，它使得可观察性用户或 SRE 能够诊断应用流程中的问题，无论架构如何复杂或无服务器。
每个跟踪由多个跨度组成，初始与请求相关的跨度称为根跨度。这个根跨度捕捉整个请求的开始到结束。根下的后续跨度提供有关请求过程中发生的各个步骤或操作的详细信息。如果没有跟踪，在分布式系统中诊断性能问题可能会非常困难。跟踪通过详细描述请求在系统中的事件序列，简化了调试和理解分布式系统的过程。
大多数可观察性供应商将这些信息可视化为瀑布图，使用成比例的水平条显示相对时间。例如，在 Grafana 中：
对于希望深入了解日志和跟踪概念的用户，我们强烈推荐 OpenTelemetry 文档。