概述

什么是可观测性

可观测性（Observability）是指通过系统的外部输出数据来推断其内部状态的能力。可观测性平台通过采集、存储、可视化分析三大可关键数据：日志（Logging）、链路追踪（Tracing）和指标（Metrics），帮助团队全面理解分布式系统的运行状态，支撑资源优化、故障预警、根因分析等，提升系统可靠性和用户体验。

为什么可观测性越来越重要

可观测性平台有下面一些重要的使用场景，对于提升系统稳定性、优化运维效率、支持业务创新非常关键。

1. 故障排查与根因分析：通过实时监控、异常检测和链路追踪，快速定位故障点并分析根本原因。例如，在金融行业中，可观测性结合交易链路和 AI 技术，能缩短故障恢复时间，保障业务连续性。支持混沌工程模拟故障场景，验证系统容错能力。
2. 性能优化与资源规划： 分析系统资源利用率、响应时间等指标，识别性能瓶颈并动态调整配置（如负载均衡、自动扩缩容）。基于历史数据预测资源需求，优化云资源分配，降低成本。
3. 业务决策支持： 将 IT 性能数据与业务成果（如用户留存率、交易量）关联，辅助制定业务策略。例如，通过分析用户体验指标优化产品功能。
4. 安全与合规监控： 检测异常行为（如零日攻击）并触发自动化响应，提升系统安全性。同时，通过日志审计满足合规要求。
5. 开发与运维协同： 在灰度发布中，通过流量染色追踪新版本表现，结合调用链分析决定发布进度。帮助开发团队优化代码性能，减少生产环境事故。

近年来可观测性越来越重要，主要是下面两方面的因素：

1. 业务和 IT 系统越来越复杂： 随着云计算、微服务的发展，业务系统越来越复杂，例如，一个 GenAI 应用的请求可能涉及到 App、服务网关、鉴权服务、计费服务、RAG 引擎、Agent 引擎、向量数据库、业务数据库、分布式缓存、消息队列、大模型 API 等几十个服务，登录服务器查看运行状态和分析故障的方式在复杂系统中已经不再有效，而可观测性平台统一采集和存储 Log, Trace, Metrics 数据，提供统一可视化分析，能够有效快速发现问题。
2. 业务可靠性要求越来越高： 系统故障对用户体验的影响成本越来越高，因此对故障定位和恢复的效率要求也越来越高，可观测性通过全域数据打通和全景可视化分析，支持团队快速定位问题根源，减少业务中断时间，保障服务可用性，进一步通过全局数据分析和预测，能够提前发现系统资源瓶颈，提早处理避免故障发生。

怎么选择可观测性解决方案

可观测性数据有下面一些特点，如何解决海量数据存储分析的挑战是可观测性解决方案的关键。

1. 数据存储量大且对成本敏感： 可观测性数据特别是 Log 和 Trace 规模通常非常庞大，且其生产周期呈现不间断的特点，特别是在中大型企业中，每天产生的可观测性数据在 TB 甚至 PB 量级。为了满足业务需求或符合监管要求，数据往往需要存储半年甚至更长时间，存储总量经常达到 PB 级别，产生高昂的存储成本。而随着时间的推移，这些数据的价值也在逐渐下降，因此对于可观测性平台来说，存储成本也变得更加敏感。
2. 数据写入吞吐高且需要实时： 面对每天 TB 甚至 PB 量级新增数据，要求平台具备 1 ～ 10GB/s、百万 ～ 千万条/s 的高吞吐写入能力，以应对持续迅猛增长的数据；同时，考虑到可观测性数据常用于故障排查、安全追踪等时效要求很高的场景，还要求平台保证秒级写入延迟，确保数据的实时性和可用性。
3. 需要实时分析且支持全文检索： Log 和 Trace 数据中有大量的文本，如何在其中快速检索关键词和短语是该场景的核心需求。由于数据规模庞大，传统的全量扫描和字符串匹配方式在性能和扩展性上往往无法达到实时响应的要求，特别是在上述高吞吐低延迟实时写入的前提下，实时文本检索更加困难。因此，构建针对文本的倒排索引成为实现秒级查询响应的关键。
4. 数据模式动态变化且需频繁扩展： Log 数据最初始的表现形态为非结构化原始日志，以 Free Text 的形式存在，随着技术的发展，进一步产生了以 JSON 为主的半结构化 Log 和 Trace，数据生产者会动态调整 JSON 内部的字段，其 Schema 非常灵活。然而，传统数据库和数据仓库难以高效处理此类灵活模式的数据，而数据湖系统虽然在存储方面提供了较大的灵活性，但在处理性能和实时性方面却难以满足需求。
5. 需要对接多种数据源和分析工具： 可观测性生态的数据采集器、可视化分析等工具很多，存储分析引擎需要与不同的生态工具进行对接，满足多样化数据和工具集成的需求。

面对 Elasticsearch、Clickhouse、Doris、云厂商日志服务等，可观测性解决方案该如何选择，选型评估的关键点是哪些呢？

1. 性能：包括写入性能和查询性能。 因为可观测性常用于故障排查等紧急情况，一方面查询的响应要快，特别是 Log Trace 数据中的文本，需要实时全文检索去支撑用户迭代式探索分析，另一方面要能查询到最新产生的数据，只能查到一天、一小时甚至十分钟前的数据是不够的，需要查询到最近几秒的新鲜数据。

   • Elasticsearch 以倒排索引和全文检索著称，提供秒级实时检索的能力，但是在高吞吐下写入性能较低，高峰期容易出现写入拒绝和延迟高的问题。另外，它的聚合统计分析性能也比低。
   • 云厂商日志服务通过丰富的资源满足写入和查询性能，同时也带来下面的成本问题。
   • Clickhouse 通过列式存储和向量化引擎，能提供很高的写入性能和聚合查询性能，但是全文检索性能比 Elasticsearch 和 Doris 慢几倍到几十倍，且一直处于实验状态达不到生产可用的要求。
   • Doris 采用列式存储和向量化引擎，针对可观测性分析场景优化倒排索引，实现比 Elasticsearch 更好的性能，写入性能提升 5 倍左右，查询性能提升 2 倍左右。聚合统计分析性能更是达到 Elasticsearch 6 ~ 21 倍。

2. 成本：包括存储成本和计算成本。 由于可观测性数据特别是 Log 和 Trace 规模通常非常庞大，中大型企业中每天产生的可观测性数据达到 TB 甚至 PB 量级。为了满足业务需求或监管要求，数据往往需要存储几个月甚至更长时间，存储总量经常达到 PB 甚至 EB 级别，产生高昂的存储成本。相比于业务数据，可观测性数据的存储量更多、价值密度相更低，而且随着时间的推移，这些数据的价值也在逐渐下降，因此存储成本也变的更加敏感。除了存储成本，海量数据写入和查询带来的计算成本也很高，GB/s 的数据写入、TB 甚至 PB 级的数据检索往往需要大量的计算资源。

   • Elasticsearch 的成本高是一个非常广泛的痛点问题，它采用原始数据行存 + 倒排索引 + docvalue 列存的存储模式，压缩比通常只有 1.5:1，存储空间和成本很高。此外，由于 JVM 性能开销和构建倒排索引，写入 CPU 占用很高，导致计算资源成本高。
   • Doris 针对可观测性场景进行了大量性能和成本优化，同样的负载相对与 Elasticsearch 成本可以减少 50% ~ 80%。这些优化包括存储方面的倒排索引简化、列式存储、ZSTD 压缩，压缩比达到 5:1 ~ 10:1，而且通过冷热存储分层进一步降低成本，写入方面的单副本写入、时序 compaction 减少写放大、向量化索引构建等。
   • Clickhouse 的采用列式存储和向量化引擎，存储和写入成本也较低。
   • 云厂商日志服务的成本跟 Elasticsearch 一样也很高。

3. 开放性：包括开源开放和多云中立。 可观测性平台的建设还需要考虑是否会被锁定，包括是否开源，在多个云平台是否都有服务，是否支持开放的生态等。

   • Elasticsearch 是由 Elastic 公司运营的开源项目，在多个云上提供服务。它的 ELK 生态比较独立，比较难跟其他生态打通，比如 Kibana 只支持 Elasticsearch 而且很难扩展到其他系统。
   • Doris 是由 Apache 基金会运营的的开源项目，全球主流云厂商提供了云上 Doris SaaS 服务。Doris 支持 OpenTelemetry, Grafana, ELK 等开源生态，保持生态开放性和中立性。
   • Clickhouse 是由 Clickhouse 公司运营的开源项目，在多个云上提供服务。Clickhouse 支持 OpenTelemetry, Grafana 等开源生态，同时收购了一家可观测性商业公司，在生态支持上将很难保持中立性。
   • 云厂商日志服务会和自己的云绑定，不提供开源的选项，不同的云厂商之间的产品不同，用户很难在不同云厂商之间保持一致的体验或者方便的迁移。

4. 易用性：包括易维护性和方便使用。 由于数据量大，可观测性平台一般都采用分布式架构，部署、扩容、缩容、升级等维护操作是否方便，对于可观测性平台的扩展性很重要。系统提供的接口也很重要，它决定了可观测性平台调用底层存储的开发效率，也影响最终用户使用的体验。

   • Elasticsearch 的 ELK 生态中 Kibana Web 界面是非常易用的，可维护性也很好，但是它提供的 DSL 查询语言复杂，使用门槛很高，对于可观测性平台对接和应用开发挑战很大。
   • Doris 提供了类似 Kibana 的交互式检索分析界面，并将对接 Kibana 和 Grafana 原生界面，查询语言是标准 SQL 且跟 MySQL 兼容，对于可观测性平台开发、工程师使用都非常友好。Doris 架构简单易于部署和维护，可以不停服务的情况下在线升级和扩缩容并自动负载均衡，提供了可视化 Cluster Manager 进行集群管理。
   • Clickhouse 也提供 SQL 接口，不过语法是自己的体系。Clickhouse 的维护面临很多挑战，比如本地表 + 分布式表的底层概念暴露、扩缩容不能自动均衡等问题，使用 Clickhouse 通常需要开发一套运维系统来支撑。
   • 云厂商日志服务提供 SaaS 服务，用户不需要自己维护系统，使用也比较方便。

基于上述分析，Doris 实现高性能写入和查询的同时保持很低的成本，SQL 接口简单易用，简单的架构易于维护和扩展，保持多云的一致体验，是构建可观测性平台的理想选择。

基于 Doris 的可观测性解决方案

系统架构

Doris 是一个现代化数据仓库，采用 MPP 分布式架构，结合向量化执行引擎、CBO 优化器、丰富的索引以及物化视图等先进技术，支持大规模实时数据上的极速查询分析，为用户提供极速的查询分析体验。经过持续的技术创新和迭代，Doris 已经在单表 ClickBench、多表 TPC-H、TPC-DS 等多个权威分析型数据库性能评测中获得全球领先甚至第一的成绩。

Doris 针对可观测性场景的特点，增加了倒排索引以及极速全文检索能力，实现写入性能和存储空间极致优化，能够很好的应对上述挑战，使用户可以基于 Doris 构建高性能、低成本、开放的可观测性平台。

基于 Doris 的可观测性平台主要由 3 大核心部分组成：

• 数据采集和预处理：支持多种可观测性数据采集工具，包括开放的 OpenTelemetry 生态和 ELK 生态中的 Logstash、Filebeat，通过 HTTP API 将 Log, Trace, Metrics 数据写入 Doris。
• 数据存储和分析引擎：Doris 提供高性能、低成本的统一可观测性数据存储，并通过 SQL 接口提供丰富的检索和分析能力。
• 查询分析和可视化：对接最常用的可观测性可视化分析工具，包括广泛使用的 Grafana 和 ELK 生态中的 Kibana，为用户提供简单易用的界面，以进行检索、分析，并设置告警规则，实现实时监控和快速响应。

基于 Doris 的可观测性解决方案有下面一些特点和优势：

• 高性能
  • 高吞吐、低延迟写入： 支持每天 PB 级（10GB/s）的 Log, Trace, Metrics 数据持续稳定写入，同时保持延迟在秒级甚至 1s 以内。
  • 高性能倒排索引和全文检索： 支持倒排索引和全文检索，日志场景关键词检索等常见查询秒级响应，比 Clickhouse 快 3 ~ 10 倍。
  • 高性能聚合分析： 通过 MPP 分布式架构和向量化 Pipeline 执行引擎，充分利用集群分布式和 CPU 多线程资源，在 ClickBench 测试中性能全球领先，适用于可观测性场景的趋势分析、监控告警等常见查询。
• 低成本
  • 高压缩率和低成本存储： 支持 PB 级海量存储，压缩率达到 5:1 ~ 10:1 甚至更高（包括索引），相对于 Elasticsearch 存储成本节省 50% ~ 80%，支持冷数据存储到 S3/HDFS，存储成本再降 50%。
  • 低成本写入： 同样的写入流量，CPU 资源消耗比 Elasticsearch 降低 70% 以上。
• Flexible Schema
  • 顶层字段变更：可以通过 Light Schema Change 发起 ADD / DROP COLUMN / INDEX 增加 / 删除列 / 索引，能够在秒级完成 Schema 变更。用户在可观测平台规划时只需考虑当前需要哪些字段创建索引。
  • 字段内部变更：专门为可扩展的 JSON 数据设计了半结构化数据类型 VARIANT，可以自动识别 JSON 中的字段名和类型，并自动拆分频繁出现的字段进行列式存储，提高压缩率和分析性能。相对于 Elasticsearch 的 Dynamic Mapping，VARIANT 允许一个字段的类型发生变化。
• 易用
  • 标准 SQL 接口： Doris 支持标准 SQL、兼容 MySQL 协议和语法，因此基于 Doris 构建的可观测性平台能够使用 SQL 进行查询，对工程师和数据分析师非常友好。
  • 拥抱可观测生态：包括 OpenTelemetry 生态和 ELK 生态，对接广泛使用的 Grafana 和 Kibana 可视化生态，便于用户进行数据采集和可视化分析。
  • 运维方便： 支持不停服务在线扩缩容、自动均衡，私有化部署提供可视化 Cluster Manager 和 k8s operator 工具，云上提供开箱即用的 Fully managed 服务。
• 开放
  • 开源开放：Doris 是一个 Apache 基金会的顶级开源项目，被全球 5000 多家企业采用，支持 OpenTelemetry Grafana 等可观测性生态。
  • 多云中立： 全球主流云厂商提供了云上 Doris SaaS 服务，为用户提供多云一致的体验。

Demo & Screenshot

下面以 OpenTelemetry 社区的一个全方位 demo 来展示基于 Doris 的可观测性平台。

被观测的业务系统是一个用于演示的电商网站，由前端接口、认证、购物车、交易、物流、广告、推荐、风控等十多个模块组成，整个系统的复杂度比较高，因此对可观测性数据采集、存储、分析都有较大的挑战。

压力模拟程序 Load Generator 持续请求入口服务，在整个电商系统中产生大量的可观测性数据（Log, Trace, Metrics），这些数据使用 OpenTelemetry 的多语言 SDK 进行采集，发送给 OpenTelemetry Collector，Collector 中的 Processors 进行预处理，然后经过 OpenTelemetry Doris Exporter 写入到 Doris。Doris 通过 MySQL 接口对接上层的分析工具如 Grafana，提供可视化查询分析功能。

Grafana 通过 MySQL Datasource 连接到 Doris，提供统一的 Log, Trace, Metrics 可视化分析，还可以实现 Log 和 Trace 的联动。

• Log

• Trace

• Metrics

Grafana 的 Log 可视化和分析能力相对于 Kibana 来说是比较简单的，因此有第三方厂商实现了类似 Kibana Discover 的检索分析能力，未来也会集成到 Grafana Doris datasource 中，提供更好的统一 Log Trace Metrics 可视化分析能力。此外，后续还会通过兼容 Elasticsearch 查询协议，让原生 Kibana 连接到 Doris，对于 ELK 用户来说，将 Elasticsearch 替换成 Doris，不改变日志采集和可视化分析使用习惯的前提下，达到降本增效的效果。