跳到主要内容
跳到主要内容
编辑此页

使用 ClickHouse 进行可观测性

介绍​

本指南专为希望使用 ClickHouse 构建自己的基于 SQL 的可观测性解决方案的用户而设计，重点关注日志和追踪。 这涵盖了构建您自己的解决方案的各个方面，包括摄取方面的考虑、针对您的访问模式优化 schema 以及从非结构化日志中提取结构。

ClickHouse 本身并不是一个开箱即用的可观测性解决方案。 然而，它可以作为可观测性数据的高效存储引擎，能够实现无与伦比的压缩率和闪电般的查询响应时间。 为了让用户在可观测性解决方案中使用 ClickHouse，需要用户界面和数据收集框架。 我们目前建议使用 Grafana 来可视化可观测性信号，并使用 OpenTelemetry 进行数据收集（两者都是官方支持的集成）。

NEEDS ALT
不仅限于 OpenTelemetry

虽然我们建议使用 OpenTelemetry (OTel) 项目进行数据收集，但也可以使用其他框架和工具（例如 Vector 和 Fluentd）生成类似的架构（请参阅 Fluent Bit 的示例）。 还存在其他可视化工具，包括 Superset 和 Metabase。

为什么使用 ClickHouse？​

任何集中式可观测性存储最重要的特性是其能够快速聚合、分析和搜索来自各种来源的大量日志数据。 这种集中化简化了故障排除，使确定服务中断的根本原因变得更加容易。

随着用户对价格越来越敏感，并且发现这些开箱即用产品的成本与它们带来的价值相比过高且不可预测，因此，查询性能可接受的、经济高效且可预测的日志存储比以往任何时候都更有价值。

由于其性能和成本效益，ClickHouse 已成为可观测性产品中日志记录和追踪存储引擎的事实标准。

更具体地说，以下几点意味着 ClickHouse 非常适合存储可观测性数据

  • 压缩 - 可观测性数据通常包含一些字段，这些字段的值取自不同的集合，例如 HTTP 代码或服务名称。 ClickHouse 的面向列的存储（其中值按排序存储）意味着这些数据压缩得非常好 - 尤其是当与一系列用于时间序列数据的专用编解码器结合使用时。 与其他数据存储不同，其他数据存储需要与数据的原始数据大小（通常为 JSON 格式）一样多的存储空间，而 ClickHouse 平均可将日志和追踪压缩高达 14 倍。 除了为大型可观测性安装提供显着的存储节省外，这种压缩还有助于加速查询，因为需要从磁盘读取的数据更少。
  • 快速聚合 - 可观测性解决方案通常大量涉及通过图表可视化数据，例如显示错误率的折线图或显示流量来源的条形图。 聚合或 GROUP BY 对于驱动这些图表至关重要，当在工作流程中应用过滤器进行问题诊断时，这些图表也必须快速响应。 ClickHouse 的面向列的格式与向量化查询执行引擎相结合，非常适合快速聚合，稀疏索引允许快速过滤数据以响应用户的操作。
  • 快速线性扫描 - 虽然替代技术依赖于倒排索引来快速查询日志，但这总是会导致高磁盘和资源利用率。 虽然 ClickHouse 提供倒排索引作为额外的可选索引类型，但线性扫描是高度并行化的，并且使用机器上的所有可用内核（除非另有配置）。 这可能允许每秒扫描 10 GB（压缩）以使用高度优化的文本匹配运算符查找匹配项。
  • SQL 的熟悉性 - SQL 是所有工程师都熟悉的通用语言。 经过 50 多年的发展，它已证明自己是数据分析的事实语言，并且仍然是第三大最流行的编程语言。 可观测性只是另一个 SQL 非常适合解决的数据问题。
  • 分析函数 - ClickHouse 使用分析函数扩展了 ANSI SQL，旨在使 SQL 查询更简单、更易于编写。 这些对于执行需要对数据进行切片和切块的根本原因分析的用户至关重要。
  • 二级索引 - ClickHouse 支持二级索引，例如 Bloom 过滤器，以加速特定的查询配置文件。 这些可以在列级别选择性启用，从而为用户提供精细的控制，并允许他们评估性价比。
  • 开源和开放标准 - 作为开源数据库，ClickHouse 拥抱 Open Telemetry 等开放标准。 贡献和积极参与项目的能力很有吸引力，同时避免了供应商锁定的挑战。

何时应将 ClickHouse 用于可观测性​

将 ClickHouse 用于可观测性数据需要用户接受基于 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/)" "-"
  • 追踪 - 追踪捕获请求在分布式系统中遍历不同服务的过程，详细说明这些请求的路径和性能。 追踪中的数据是高度结构化的，由跨度和追踪组成，这些跨度和追踪映射出请求执行的每个步骤，包括时间信息。 追踪提供了对系统性能的宝贵见解，有助于识别瓶颈、延迟问题并优化微服务的效率。
指标

虽然 ClickHouse 可以用于存储指标数据，但这个支柱在 ClickHouse 中还不够成熟，正在等待对 Prometheus 数据格式和 PromQL 等功能的支持。

分布式追踪​

分布式追踪是可观测性的关键功能。 分布式追踪（简称追踪）映射请求在系统中的旅程。 请求将源自最终用户或应用程序，并在整个系统中扩散，通常会导致微服务之间的操作流。 通过记录此序列并允许后续事件关联，可观测性用户或 SRE 能够诊断应用程序流程中的问题，无论架构多么复杂或无服务器。

每个追踪由多个跨度组成，与请求关联的初始跨度称为根跨度。 此根跨度捕获从开始到结束的整个请求。 根跨度下方的后续跨度提供了对请求期间发生的各个步骤或操作的详细见解。 如果没有追踪，则诊断分布式系统中的性能问题可能非常困难。 追踪通过详细说明请求在系统中移动时发生的事件序列，简化了调试和理解分布式系统的过程。

大多数可观测性供应商将此信息可视化为瀑布图，相对时间使用比例大小的水平条显示。 例如，在 Grafana 中

NEEDS ALT

对于需要深入了解日志和追踪概念的用户，我们强烈推荐 OpenTelemetry 文档。