可观测性选型实录：从 OpenTelemetry 到 OpenObserve 的落地之路

来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, 网络安全, 编程
原文链接： https://mp.weixin.qq.com/s/vaMGnMpaMZ44yiwt_clEAQ

摘要

最近在做智能体的可观测性建设。每次对话的执行过程、调用链路、耗时分布都需要被观测到。当用户反馈"Skill 执行慢了"或者"结果不对"，我需要能快速定位是哪个环节出了问题。这就是可观测性的核心价值：从外部输出推断系统内部状态。这篇文章记录了我在可观测性技术选型上的完整调研过程——从理解 OpenTelemetry 协议，到对比多种存储方案，最终选择 OpenObserve 作为落地平台。 ## 一、为什么选 OpenTelemetry？ ## 1.1 可观测性的三大信号可观测性（Observability）源于控制理论，核心思路是：通过系统的外部输出，推...

核心内容

最近在做智能体的可观测性建设。每次对话的执行过程、调用链路、耗时分布都需要被观测到。当用户反馈"Skill 执行慢了"或者"结果不对"，我需要能快速定位是哪个环节出了问题。

这就是可观测性的核心价值：从外部输出推断系统内部状态。

这篇文章记录了我在可观测性技术选型上的完整调研过程——从理解 OpenTelemetry 协议，到对比多种存储方案，最终选择 OpenObserve 作为落地平台。

一、为什么选 OpenTelemetry？

1.1 可观测性的三大信号

可观测性（Observability）源于控制理论，核心思路是：通过系统的外部输出，推断内部状态。

在软件系统中，这转化为三大信号：
信号回答的问题典型场景Traces（链路追踪）请求走了哪些路径？每步耗时多少？定位"Skill 执行慢"瓶颈在哪Metrics（指标）系统级数据如何？CPU 使用率、QPS、错误率趋势Logs（日志）发生了什么离散事件？排查具体错误信息
三者关联起来才是完整的可观测性：从 Metrics 发现异常 → 通过 Traces 定位链路 → 在 Logs 中找到根因。

1.2 OpenTelemetry 是什么

OpenTelemetry（OTel） 是 CNCF 旗下的可观测性框架，由 OpenTracing 和 OpenCensus 合并而来。它不是某个具体产品，而是一套采集和传输标准：

API + SDK：各语言的埋点库（Java/Python/Go/Node.js...）
OTLP 协议：统一的遥测数据传输格式
Collector：数据采集、处理、转发的核心组件
关键定位：OTel 只管采集和传输，不管存储和展示。这避免了厂商锁定——换了存储后端，采集层代码不用改。

1.3 核心架构

应用（OTel SDK / Java Agent）
↓ OTLP
OTel Collector（可选，生产推荐）
↓ OTLP
存储后端（Jaeger / Prometheus / OpenObserve / ...）

Collector 是架构中的关键组件，类似 Logstash 的角色：

Receivers：接收数据（支持 OTLP/Jaeger/Zipkin/Kafka 等多种协议）
Processors：处理数据（过滤、采样、批量发送）
Exporters：导出数据到后端
💡 Collector vs Exporter 的区别（我踩过坑）：
Exporter：SDK 内置的导出器，直接把数据发送到后端
Collector：独立进程，可接收多种协议，集中处理后转发
生产环境建议用 Collector Gateway 做统一入口

二、存储选型：四大流派

OTel 解决了"怎么采"的问题，但"存哪里"才是成本的关键。在可观测性场景中，数据量巨大，存储成本往往占系统总成本的大头。

2.1 四大存储流派

流派代表方案索引方式适用场景全文索引Elasticsearch / OpenSearch全量倒排索引安全分析、复杂搜索标签存储Loki + MinIO/S3仅标签+时间索引日志聚合、Prometheus 生态列式分析SigNoz (ClickHouse)列存 OLAPSQL 聚合分析存算分离OpenObserve + MinIO/S3Parquet + 轻量索引全栈可观测
大致的趋势是：全文索引查询能力最强但存储成本最高，标签/列式/存算分离方案通过减少索引来降低存储成本。

2.2 选型决策树

需要任意关键词全文搜索？
├── 是 → Elasticsearch（安全分析、合规审计）
└── 否 → 日志量多大？
├── 中小规模 → OpenObserve 单节点 / SigNoz
└── 大规模 → Grafana LGTM 或 OpenObserve HA

三、落地平台对比：我的四个候选

基于存储选型分析，我重点对比了四个开源方案，并且每个都实际部署体验过。

3.1 方案速览

方案核心组件部署体验我的感受OpenObserve单二进制（Rust）极简一条 docker run 就跑起来了Grafana LGTMLoki+Tempo+Mimir+Grafana复杂光配置就折腾了一下午SigNozClickHouse + OTel Collector中等docker-compose 一键起来，还算方便UptraceClickHouse + PostgreSQL中等功能丰富但还在 beta

3.2 实际体验对比

OpenObserve

部署：docker run 一条命令，几分钟就启动了
能力：Logs + Metrics + Traces + Dashboards + Alerts 全内置
查询：SQL + PromQL，上手门槛低
踩坑：开源版只有 Admin 角色，没有 RBAC。如果需要多租户，可以用 Organization 级别做数据隔离（每个 org 用不同的 auth key），但细粒度权限控制需要企业版

Grafana LGTM

组件：Loki（日志）+ Tempo（追踪）+ Mimir（指标）+ Grafana（可视化），4-5 个独立组件
优势：可视化能力确实强，Drilldown（无查询体验）很自然，Trace 的 Span 展示分类比 OpenObserve 清晰
代价：4-5 个组件各自安装、配置、运维，学习成本高

SigNoz

存储：ClickHouse 列式 OLAP
部署：Docker Compose 一键启动
优势：一个控制台看所有，APM 功能完整，OTel 原生
感受：整体不错，但对我当前场景来说引入 ClickHouse 有点重

3.3 运维视角对比（选型的关键）

对我来说，运维成本才是选型的核心考量——我没有专职 SRE，可观测系统得自己维护：
运维场景Grafana LGTMOpenObserve安装4-5 个组件各自配置单二进制升级4-5 个组件分别升级升级一个二进制故障排查需定位是哪个组件的问题单一进程，日志集中监控自己每个组件都要监控只需监控自身

四、我为什么选了 OpenObserve

4.1 决策理由

一句话：我需要的是快速落地，不是完美架构。

具体来说：

运维成本最低：All-in-One 设计，我一个人就能搞定部署和维护
存储成本低：Parquet + 对象存储，

...(内容截断，完整内容请查看原文)

本页由自动化脚本生成，待人工审核补充