ClickHouse 官方文档：使用 ClickHouse 构建可观测性解决方案【1/5】

本文字数：3933；估计阅读时间：10 分钟

作者： ClickHouse官方

本文在公众号【ClickHouseInc】首发

本文是 ClickHouse 官网文档可观测性系列文章，共有 5 篇：

1. 概述

2. 设计数据模型

3. 管理数据

4. 与 OpenTelemetry 集成

5. 使用 Grafana 分析数据

本篇为第一篇《概述》，正文如下：

简介  

本指南适用于希望使用 ClickHouse 构建基于 SQL 的可观测性 (observability) 解决方案的用户，重点关注日志和跟踪。指南内容涵盖从数据摄取到模式优化以及从非结构化日志中提取结构化信息的所有方面。

ClickHouse 本身并不是一个开箱即用的可观测性工具，但它可以作为一个极高效的存储引擎，为可观测性数据提供卓越的压缩率和极快的查询速度。为了在可观测性解决方案中使用 ClickHouse，用户需要配备用户界面和数据收集框架。我们目前推荐使用 Grafana 进行可视化，并使用 OpenTelemetry 进行数据收集（这两个工具均为官方支持的集成）。

不仅限于 OpenTelemetry  

尽管我们推荐使用 OpenTelemetry (OTeL) 项目来收集数据，但也可以使用其他框架和工具构建类似的架构，例如 Vector 和 Fluentd（可参见 Fluent Bit 的示例）。此外，还可以选择其他可视化工具，例如 Superset 和 Metabase。

选择 ClickHouse 的理由

集中式可观测性存储的核心功能是快速汇总、分析和搜索来自不同来源的海量日志数据。通过集中化存储，能够有效简化故障排查，帮助快速定位服务中断的根本原因。

在现今成本敏感的环境中，用户越来越倾向于寻找高性价比、成本可控的日志存储解决方案，而不是那些价格高昂且不可预测的开箱即用工具。只要查询性能满足要求，ClickHouse 提供的高效与经济性使其价值尤为突出。

凭借卓越的性能与成本优势，ClickHouse 已成为可观测性产品中日志和跟踪存储引擎的事实标准。具体来说，以下特点使得 ClickHouse 非常适合存储可观测性数据：

• 卓越的压缩能力：可观测性数据通常包含一些来源于特定集合的字段，例如 HTTP 状态码或服务名称。借助列式存储中按排序存储的方式，以及专为时间序列数据设计的多种编解码器，ClickHouse 可以实现极高的压缩效率。相比其他存储需要与原始 JSON 数据大小相当的空间，ClickHouse 平均能够将日志和跟踪压缩至 14 倍。这不仅能为大型可观测性系统显著节省存储成本，还能加速查询，因为需要从磁盘读取的数据大幅减少。

• 快速聚合性能：可观测性解决方案通常通过图表展示数据，例如显示错误率的折线图或流量来源的柱状图。GROUP BY 聚合操作是实现这些图表的核心，尤其是在问题诊断的工作流中应用过滤器时，响应速度至关重要。ClickHouse 的列式存储格式与矢量化查询执行引擎相结合，不仅能实现快速聚合，还通过稀疏索引大幅提升了过滤性能。

• 高效的线性扫描：尽管其他技术主要依赖倒排索引进行日志查询，但这通常会显著增加磁盘和资源使用率。而 ClickHouse 提供倒排索引作为可选项，同时其高度并行化的线性扫描能够充分利用机器的所有可用内核。这样即使是高达每秒数十 GB 的压缩数据，也能快速完成扫描和匹配。

• 广泛熟悉的 SQL：SQL 是工程师熟知的通用语言。经过 50 多年的发展，它已经成为数据分析的事实标准，并稳居全球第三大流行编程语言。可观测性只是又一个需要数据处理的场景，而 SQL 无疑是这一场景的理想工具。

• 强大的分析功能 ：ClickHouse 扩展了 ANSI SQL，增加了多种分析函数，使得编写 SQL 查询更加简单。这些功能在根本原因分析中尤为关键，用户可以轻松对数据进行切片和分块操作。

• 灵活的二级索引：ClickHouse 支持布隆过滤器等二级索引，以加速特定查询。用户可以按列启用这些索引，从而实现细粒度的性能优化和成本控制。

• 开源与开放标准：作为一款开源数据库，ClickHouse 拥抱开放标准，例如 OpenTelemetry。用户可以参与社区贡献并享受开放生态的灵活性，同时避免供应商锁定的问题。

哪些场景适合使用 ClickHouse 实现可观测性

如果您打算使用 ClickHouse 存储可观测性数据，需要接受基于 SQL 的可观测性方法。我们推荐阅读一篇关于 SQL 可观测性历史的博客文章，但简而言之：

以下情况表明基于 SQL 的可观测性适合您：

• 您或您的团队熟悉 SQL，或者希望学习使用 SQL。

• 您倾向采用开放标准（例如 OpenTelemetry），以避免供应商锁定并实现系统的可扩展性。

• 您愿意构建一个由开源创新驱动的完整生态系统，从数据收集到存储和可视化都基于开源技术。

• 您预期管理的可观测性数据量将增长到中型或大型规模，甚至是非常大规模。

• 您希望控制总拥有成本 (TCO)，并避免可观测性成本持续增长。

• 您不希望因为节省成本而缩短可观测性数据的保留周期。

以下情况可能说明基于 SQL 的可观测性不适合您：

• 您或您的团队不愿学习或生成 SQL。

• 您希望使用一个完整、打包好的端到端可观测性解决方案。

• 您的可观测性数据量较小（例如小于 150 GiB），且预计不会有显著增长。

• 您的用例主要依赖指标数据，并需要使用 PromQL。

  在这种情况下，您仍可以使用 ClickHouse 存储日志和跟踪数据，同时用 Prometheus 存储指标数据，并通过 Grafana 在展示层将它们统一起来。

• 您更倾向于等待基于 SQL 的可观测性方法和相关生态系统进一步成熟，实现更加开箱即用的体验。

日志与跟踪

在可观测性领域，通常包括三大核心要素：日志、跟踪和指标。这三者的数据类型和访问模式各有特点。

目前，我们推荐使用 ClickHouse 存储以下两类可观测性数据：

• 日志：日志是记录系统中发生事件的时间戳数据，详细描述了软件运行的各个方面。这些数据通常是非结构化或半结构化的，可能包括错误信息、用户活动日志、系统变更记录等事件。日志在故障排查、异常检测以及分析问题根因的过程中发挥了关键作用。

54.36.149.41 - - [22/Jan/2019:03:56:14 +0330] "GET
/filter/27|13%20%D9%85%DA%AF%D8%A7%D9%BE%DB%8C%DA%A9%D8%B3%D9%84,27|%DA%A9%D9%85%D8%AA%D8%B1%20%D8%A7%D8%B2%205%20%D9%85%DA%AF%D8%A7%D9%BE%DB%8C%DA%A9%D8%B3%D9%84,p53 HTTP/1.1" 200 30577 "-" "Mozilla/5.0 (compatible; AhrefsBot/6.1; +http://ahrefs.com/robot/)" "-"

• 跟踪：跟踪记录了请求在分布式系统中穿越不同服务的全过程，详细呈现了请求路径及其性能表现。这类数据高度结构化，由跨度 (span) 和跟踪 (trace) 组成，描述了请求每一步的执行过程及时间信息。通过跟踪，开发者可以深入了解系统性能，发现瓶颈、延迟问题，并优化微服务的运行效率。

指标

尽管 ClickHouse 也支持存储指标数据，但目前这一领域的功能仍在完善中，包括对 Prometheus 数据格式及 PromQL 的支持尚未完全实现。

分布式跟踪

分布式跟踪是可观测性中的核心功能。它通过记录请求在系统中的流转路径，展示了一个请求从起点到终点的全过程。请求通常由终端用户或应用程序发起，并在系统内传播，形成微服务之间的一系列操作流。通过记录这些事件序列并将它们关联起来，分布式跟踪帮助可观测性用户或站点稳定性工程师 (SRE) 诊断应用程序流中的问题，无论系统架构多么复杂，甚至是无服务器架构。

每个追踪由多个跨度 (span) 组成，其中第一个跨度被称为根跨度 (root span)，负责记录整个请求的起点到终点。根跨度之下的其他跨度则详细记录了请求过程中各个步骤或操作的具体信息。如果没有跟踪功能，在分布式系统中诊断性能问题将非常困难。而分布式跟踪通过清晰展现请求流转过程中各事件的详细顺序，使调试和理解分布式系统的过程更加高效。

大多数可观测性工具会将这些信息以瀑布图的形式进行可视化。瀑布图通常使用横向条形的长度来表示各事件的相对时间。例如，在 Grafana 中：

如果您想深入了解日志和跟踪的概念，我们强烈推荐参考 OpenTelemetry 的官方文档。【https://opentelemetry.io/docs/concepts/】

征稿启示

面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com