基于 Apache Doris 构建 Log/Trace/Metrics 统一分析

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

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

核心应用场景

可观测性平台已经成为现代分布式系统不可或缺的基础设施，主要覆盖以下五类场景：

场景	价值	典型用例
故障排查与根因分析	缩短故障恢复时间，保障业务连续性	实时监控、异常检测、链路追踪、混沌工程
性能优化与资源规划	识别性能瓶颈，降低云资源成本	资源利用率分析、负载均衡、自动扩缩容、容量预测
业务决策支持	将 IT 性能与业务成果关联	用户体验指标分析、产品功能优化
安全与合规监控	检测异常行为并自动响应	零日攻击检测、日志审计、合规留存
开发与运维协同	辅助灰度发布与代码优化	流量染色、调用链分析、发布进度评估

推动可观测性升级的两大趋势

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

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

可观测性数据的关键特点

如何应对海量数据的存储与分析挑战，是可观测性方案的核心。可观测性数据具有以下五大特点：

1. 数据存储量大且对成本敏感：Log 和 Trace 规模通常非常庞大，且生产周期不间断。中大型企业每天产生的可观测性数据在 TB 甚至 PB 量级，为满足业务需求或符合监管要求，往往需要存储半年甚至更长时间，存储总量经常达到 PB 级别，成本高昂。随着时间推移，这些数据的价值也在逐渐下降，因此可观测性平台对存储成本更加敏感。
2. 数据写入吞吐高且需要实时：面对每天 TB 甚至 PB 量级的新增数据，平台需要具备 1～10 GB/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 倍左右	比 Elasticsearch 快 2 倍左右	比 Elasticsearch 快 6～21 倍

2. 成本：存储成本与计算成本

中大型企业每天产生的可观测性数据可达 TB 甚至 PB 量级，存储总量常达 PB 甚至 EB 级别。相比业务数据，可观测性数据存储量更多、价值密度更低，且价值随时间逐渐下降，因此对存储与计算成本均高度敏感。

方案	压缩比	存储 / 计算成本
Elasticsearch	约 1.5:1（行存 + 倒排索引 + docvalue 列存）	存储成本高；JVM 开销 + 倒排索引构建导致 CPU 占用高
Doris	5:1 ~ 10:1，配合冷热分层进一步降本	相对 Elasticsearch 节省 50%~80%；单副本写入、时序 compaction、向量化索引构建降低写入成本
ClickHouse	列式存储，压缩较好	存储和写入成本较低
云厂商日志服务	—	与 Elasticsearch 同样高

3. 开放性：开源开放与多云中立

可观测性平台建设需要避免厂商锁定，关注是否开源、是否在多云提供服务、是否支持开放生态等。

方案	项目运营方	多云支持	生态开放性
Elasticsearch	Elastic 公司	多云提供服务	ELK 生态较独立，Kibana 仅支持 Elasticsearch
Doris	Apache 基金会	主流云厂商提供 SaaS	支持 OpenTelemetry、Grafana、ELK 等开源生态，保持中立
ClickHouse	ClickHouse 公司	多云提供服务	支持 OpenTelemetry、Grafana；收购可观测商业公司后中立性受影响
云厂商日志服务	各云厂商	与自家云绑定	不开源，跨云迁移困难

4. 易用性：易维护性与方便使用

由于数据量大，可观测性平台普遍采用分布式架构，部署、扩缩容、升级等运维操作的便捷性，以及查询接口的开发友好度，都是重要考量。

方案	接口与运维
Elasticsearch	Kibana 界面易用、可维护性好；DSL 查询语言复杂，使用门槛高
Doris	提供类 Kibana 交互式检索分析界面，并对接 Kibana / Grafana 原生界面；标准 SQL 兼容 MySQL；架构简单，支持在线升级和扩缩容、自动负载均衡，提供可视化 Cluster Manager
ClickHouse	自有方言 SQL；本地表 + 分布式表底层概念暴露，扩缩容不能自动均衡，通常需自建运维系统
云厂商日志服务	SaaS 服务无需自维护，使用方便

选型结论

基于上述对比，Doris 在性能、成本、开放性与易用性四个维度上均具备明显优势：高性能写入和查询的同时保持很低的成本，SQL 接口简单易用，简单架构易于维护和扩展，多云保持一致体验，是构建可观测性平台的理想选择。

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

系统架构

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

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

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

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

方案核心优势

高性能

• 高吞吐、低延迟写入：支持每天 PB 级（10 GB/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 接口：兼容 MySQL 协议和语法，工程师与数据分析师可直接使用 SQL 查询。
• 拥抱可观测生态：覆盖 OpenTelemetry 与 ELK 生态，对接 Grafana、Kibana 等可视化工具，便于数据采集和可视化分析。
• 运维方便：支持不停服在线扩缩容与自动均衡，私有化部署提供可视化 Cluster Manager 和 K8s Operator 工具，云上提供开箱即用的 Fully Managed 服务。

开放

• 开源开放：Doris 是 Apache 基金会顶级开源项目，被全球 5000 多家企业采用，支持 OpenTelemetry、Grafana 等可观测性生态。
• 多云中立：主流云厂商提供 Doris SaaS 服务，多云一致体验。

Demo 与截图

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

被观测系统

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

数据流向

压力模拟程序 Load Generator 持续请求入口服务，在整个电商系统中产生大量的可观测性数据（Log、Trace、Metrics）。数据流向如下：

1. 使用 OpenTelemetry 多语言 SDK 进行采集
2. 发送给 OpenTelemetry Collector
3. Collector 中的 Processors 进行预处理
4. 经 OpenTelemetry Doris Exporter 写入 Doris
5. 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，可以在不改变日志采集和可视化分析使用习惯的前提下，达到降本增效的效果。