中国可观测性厂商对比
中国可观测性市场在 2024–2026 年间快速分化:云厂商托管方案(阿里 ARMS、腾讯 APM、华为 AOM)、创业公司(观测云、DeepFlow)、开源包装(夜莺)——20+ 个方案摆在技术负责人的选型清单上。各家 demo 都很好看——但真落地时,绑定、成本、社区生态、信创合规,每家都有自己的坑。
本文从技术架构、产品定位和典型使用场景三个维度做对比,不评价哪个”最好”,只描述哪个在什么场景下最匹配。
一、市场格局与技术路线
三条路线:
- 云厂商托管:ARMS(阿里云)、腾讯云 APM、华为云 AOM。优势:开箱即用、与同厂商云产品(ECS/RDS/CSE 等)联动、等保合规有天然优势。劣势:数据锁定、价格不透明、跨云场景支持差。
- 创业公司 SaaS/私有化:观测云(Guance)、DeepFlow。优势:在某些领域有独特技术优势(观测云的数据探索体验、DeepFlow 的 eBPF 零侵入网络观测)。劣势:生态规模和持续运营能力需要评估。
- 开源自建:夜莺(Nightingale)+ VictoriaMetrics/Thanos/GreptimeDB。优势:数据自主可控、定制性强。劣势:需要 SRE 团队有足够的能力来运维全套开源栈。
二、各方案技术架构对比
| 方案 | 采集方式 | 存储引擎 | 查询语言 | OTel 兼容 |
|---|---|---|---|---|
| ARMS | Java Agent 字节码增强 | 阿里自研 TSDB | 类 PromQL | 部分 |
| 腾讯 APM | Java Agent + SkyWalking | Jaeger + 自研 | Jaeger UI / 腾讯云控制台 | 部分 |
| 华为 AOM | ICAgent(Go) | OTel Collector + 华为自研 | 兼容 PromQL | 是 |
| 观测云 | DataKit(Go) | DataWay → 观测云 SaaS | GuanceQL(类 SQL) | 是 |
| DeepFlow | eBPF 零侵入 | ClickHouse | SQL | 兼容 OTLP |
| 夜莺 | Prometheus + Telegraf | VictoriaMetrics / Thanos | PromQL | 社区集成 |
ARMS:最大的优势是 Java Agent 全自动埋点——阿里在这个领域有十年积累,字节码增强的稳定性和覆盖范围在国内无人能及。最大的劣势是阿里云专属——出了阿里云生态,ARMS 的价值大打折扣。
腾讯云 APM:基于 SkyWalking 内核 + 腾讯云原生集成(TKE、CLB、CDB 等联动)。在腾讯云环境中是默认选择,跨云和多云支持不如 OTel 兼容方案。
华为云 AOM:OpenTelemetry 兼容——这是它和 ARMS/APM 最大的区别。ICAgent 基于 OTel Collector 改造。支持多云和混合云场景(华为云 + 私有数据中心)。
观测云(Guance):以数据探索体验为核心竞争力——Query Builder 的可视化拖拽式查询比手写 PromQL/SQL 门槛低。DataKit 是 Go 写的统一采集器——一个二进制搞定 Metrics/Logs/Traces/Profiles/Security 五种信号的采集。适合不想花太多时间在配置和查询语言上的团队。
DeepFlow:核心差异化是 eBPF 零侵入——不需要改代码、不需要装 Agent(除了 eBPF Agent),就能生成服务拓扑图、网络延迟矩阵、应用请求的 RED 指标。网络观测是它最强的地方——Cilium Hubble 的竞品,但 DeepFlow 更偏向中国企业客户的场景需求。
夜莺(Nightingale):开源监控/告警平台,作为 Prometheus 的上层封装——多数据源管理、可视化 Dashboard、告警引擎、OnCall 流转。Flashcat(夜莺的商业公司)提供商业版。适合已经有一套 Prometheus 生态但需要更高级的告警管理和多数据源整合的团队。
三、场景化选型建议
| 场景 | 推荐 | 理由 |
|---|---|---|
| 全栈阿里云 | ARMS | 云产品联动最好,Java Agent 最成熟 |
| 全栈腾讯云 | 腾讯 APM | 基于 SkyWalking,TKE 集成最好 |
| 多/混合云 | 华为 AOM 或观测云 | OTel 兼容,数据不锁定在单一云厂商 |
| 网络观测优先 | DeepFlow | eBPF 零侵入,网络+应用统一观测 |
| 已有 Prometheus + 要升级监控 | 夜莺 | Prometheus 原生兼容,多数据源整合 |
| 预算有限 + 有 SRE 团队 | 开源自建(本系列 25 篇讨论) | 完全可控 |
四、数据锁定与迁移风险
商业托管方案最大的隐性风险不是价格——是数据锁定。ARMS 的存储格式是阿里自研的,数据只能通过 API 导出——而且导出的数据格式可能不兼容开源标准(Prometheus TSDB block、Loki chunk、Tempo parquet)。一旦选择 ARMS,未来迁移到其他方案的代价是”重新积累历史数据”——可能是几个月到几年的数据断层。
如果担心数据锁定,选择基于开放格式的产品——OTel Collector + 标准 Prometheus TSDB 或 VictoriaMetrics + Loki chunk + Tempo parquet——或者至少确保商业产品支持 OTLP 格式的数据导出。
五、信创合规
对于政府和国企客户(以及渗透到国企供应链的民营企业),等保(信息安全等级保护)和信创(国产芯片/操作系统)是硬件条件。确认候选方案是否支持:国产 CPU(鲲鹏、飞腾、海光)、国产 OS(麒麟、统信 UOS、openEuler)、国产数据库(OceanBase、TiDB、GaussDB、达梦)。国产化程度最高的是华为 AOM(华为全栈信创)和夜莺(开源可自行适配)。
六、关键概念回顾
- 三条路线:云厂商托管 / 创业公司 / 开源自建。各有锁定程度、成本结构和运维复杂度的权衡。
- 数据锁定:商业托管方案最大的隐性风险。优先选择支持 OTLP 和标准开放格式的产品。
- DeepFlow 的 eBPF 零侵入是网络观测的最佳切入点,但对应用层的 visibility 不如 OTel 全栈埋点。
- 信创合规对政企客户是硬约束——要提前确认国产 CPU + OS 的支持情况。
七、下一步
厂商选好之后,日常运营中最重要的可观测性技能是——出了事故怎么高效地追到根因。下一篇 真实事故复盘剧本。
上一篇:混沌工程:ChaosBlade、Chaos Mesh 与可观测性闭环
参考资料
- 阿里云, ARMS 产品文档, https://help.aliyun.com/product/34364.html
- 腾讯云, APM 产品文档, https://cloud.tencent.com/document/product/1463
- 华为云, AOM 产品文档, https://support.huaweicloud.com/aom/
- 观测云, Guance Documentation, https://docs.guance.com/
- DeepFlow, Documentation, https://deepflow.io/docs/
- 夜莺, Nightingale Documentation, https://n9e.github.io/
同主题继续阅读
把当前热点继续串成多页阅读,而不是停在单篇消费。
【可观测性工程】自建 vs 托管:OpenTelemetry 自建栈与 SaaS 的选型决策
OpenTelemetry 成熟之后,自建可观测性栈不再只是大厂的选项。拆解自建(LGTM 栈)与托管(Grafana Cloud / ARMS / Datadog)的 TCO 对比模型、规模临界点、混合方案与迁移路径。
【可观测性工程】网络可观测性:Cilium Hubble、Pixie、DeepFlow、Tetragon
从 L3/L4/L7 三层观测视角出发,讲 eBPF socket filter / tc / XDP 数据采集与 Cilium Hubble 流日志、Tetragon 安全可观测、Pixie 协议自动解析、DeepFlow 架构;展开 bpftrace + kfree_skb_reason 的内核丢包定位、TLS 解密、HTTP/2 解析与服务拓扑自动发现。
【可观测性工程】eBPF 可观测性全景:bcc、bpftrace、libbpf 的工程路径
eBPF 如何实现零侵入、内核级、低开销的可观测性:从 kprobe/uprobe/tracepoint/fentry 钩子机制,到 bcc 工具集、bpftrace 脚本语言、libbpf+CO-RE 可移植编程,再到 Pixie、DeepFlow、Grafana Beyla 等商业化工具,结合内核版本兼容性与生产部署实战。
【可观测性工程】埋点哲学:粒度、采样、基数爆炸与成本模型
埋点不是多加几行日志,而是一整套关于什么该记、什么该采样、什么该丢弃的工程决策体系。从信号分层、基数控制、采样策略到落地规范与工程坑点,给出可操作的埋点治理框架。