Apache OzHera 2.2.6 介绍与选型指南

Apache OzHera 2.2.6 介绍与选型指南：小米捐献、仍在孵化的云原生 APM 应用观测平台（最新正式版 2.2.6-incubating，2026-10 仍有 2.2.7 RC 在迭代），讲清以应用为核心的指标/链路/日志/告警一体化架构、Kubernetes operator 部署路径，并与 Uptrace、SigNoz、OpenObserve 给出量化选型对比。

Apache OzHeraOzHeraApacheAPM云原生2026/10/19

Apache OzHera 2.2.6 介绍与选型指南

目标：基于 Apache 孵化器状态页、GitHub Releases 与官方网站的联网溯源（查询日期 2026-10-19），讲清 Apache OzHera（Incubating）——小米捐献、以应用为核心的云原生 APM 应用观测平台——的定位、架构、最新正式版与部署路径，并给出与 Uptrace、SigNoz、OpenObserve 的量化选型对比。本文为认知篇，不做本地部署实测。

一、信息基准

本节给出本文全部关键数据的基准与来源，所有版本号与状态信息均在 2026-10-19 联网核验。

二、软件概述

2.1 项目定位

Apache OzHera（孵化中）是面向云原生时代的 APM（Application Performance Monitoring）应用观测平台：以应用为核心，把指标监控（metric）、分布式链路追踪（trace）、日志（logging）与告警（alerting）四类能力整合到一个平台。官方给出的目标量化口径是：故障发生时1 分钟内发现、5 分钟内定位。项目由小米开发并捐献给 Apache，官网说明其曾在小米经历大量压测实践（日均处理超过 1 PB 原始数据的规模宣称，来源：ozhera.apache.org 首页特性说明）。

2.2 版本现状

截至 2026-10-19：项目入孵两年余仍处孵化期；正式版本线为 2.2.x，最新正式版 2.2.6-incubating（2026-06-17），2.2.7-incubating 的三连 RC（10 月上旬）表明社区处于持续活跃的开发状态。版本命名均带 -incubating 后缀，属孵化器规范要求，表示尚未获得 ASF 完全背书。

三、核心架构

3.1 能力整合模型

依据官网特性说明与文档结构（查询日期 2026-10-19）：

  • 数据采集与标准：遵循 OpenTracing 标准，集成 OpenTelemetry 生态，应用侧以探针/SDK 方式接入；
  • 数据面组件：集成 Prometheus（指标）、Elasticsearch（日志与追踪存储）、Grafana（可视化）、CAdvisor（资源指标）等开源组件，OzHera 在其之上做平台化整合；
  • 以应用为中心的组织方式：指标、链路、日志均按"应用"维度聚合，而非按存储/组件维度；
  • 告警与定位闭环：基于 RPC 与业务错误码解析计算"业务可用性"指标（业务可用性 = 1 − 异常请求数/总请求数），过滤无效告警；通过 traceId 把告警、指标、链路、日志串成闭环，缩短定位路径；
  • 部署面：提供 Kubernetes operator，面向 K8s 环境一键部署整套平台（官方部署文档 https://ozhera.apache.org/en/docs/deployment.html ）。

💡 技术拓展：APM/可观测平台的两种形态对比——

形态代表特点
组合自建Prometheus + Grafana + ES + Jaeger灵活、组件自选，但四类数据割裂、定位靠人工串联
一体化平台OzHera、SigNoz、OpenObserve、Uptrace以应用/traceId 为中心打通四类信号，定位路径短

OzHera 属于后者：以应用为中心 + traceId 闭环是其与"裸组件组合"路线的本质差异。

3.2 平台化能力

官网说明平台内置账户、权限、应用管理与消息通知机制，核心联动模块解耦设计、对业务系统低侵入；平台自身经历过小米的大规模压测实践（官网宣称日均 1 PB+ 原始数据）。

四、关键特性

以下特性依据官网特性页归纳（查询日期 2026-10-19）：

  • 拥抱云原生：遵循 OpenTracing 标准，集成 OpenTelemetry、Grafana、Prometheus、Elasticsearch、CAdvisor 等主流开源组件；
  • 精确告警：基于 RPC 与业务错误码解析提取业务可用性指标，以"业务可用性"而非纯技术指标驱动告警，减少无效告警干扰；
  • 快速定位：以 traceId 打通告警-指标-链路-日志的闭环联动，官方目标口径"1 分钟发现、5 分钟定位"；
  • 成本宣称：官网宣称链路存储成本"低于千分之一"、满足 99.9% 的追踪需求（官方口径，实际以部署实测为准）；
  • 企业级配套：账户/权限/应用管理与消息通知机制内置，核心模块解耦、业务低侵入；
  • AI 辅助：官网说明引入 AI 工具辅助问题定位与原因分析（官方宣称特性）；
  • 固有限制（孵化期导致）：版本带 -incubating 后缀、尚无 ASF 完全背书；社区规模小（主仓星标 124，2026-10-19 实查）；部署依赖组件多、运维面大。

五、快速上手

以下为官方快速上手路径的转述（来源：https://ozhera.apache.org/en/guide/quick-start.html ，查询日期 2026-10-19；认知篇不重复本地部署实测）：

  1. 在线体验：官方提供在线 Demo（ozhera.demo.m.one.mi.com，体验账号 ozhera@ozhera.com / 口令 123456），部署前可先零成本感受平台界面与功能；
  2. Kubernetes 环境部署：官方部署文档面向 K8s 环境，通过 operator 部署 OzHera 全套组件（文档：https://ozhera.apache.org/en/docs/deployment.html ）；平台组件较多（含 ES/Prometheus/Grafana 等），建议先核对官方资源要求；
  3. 应用接入：平台部署后自带两个预集成的示例应用，自有应用按官方应用集成文档接入（文档：https://ozhera.apache.org/en/docs/application-integration.html ），遵循 OpenTracing/OpenTelemetry 采集口径；
  4. 使用平台：以应用为中心查看指标/链路/日志，配置业务可用性告警与通知渠道。

⚠️ 注意：2.2.6-incubating 属孵化期版本，升级与兼容性以官方 Release 说明为准；2.2.7 的 RC 系列（2026-10）尚在候选阶段，生产使用请以正式版为准。

六、适用场景与限制

适用场景：

  • 云原生（K8s）环境下的 Java 等应用 APM 需求，希望指标/链路/日志/告警一站式整合、以 traceId 快速定位；
  • 已在小米系技术栈内或对中文生态友好的观测平台有偏好的团队；
  • 应用数量较多、需要账户/权限/应用管理这类"企业级平台"配套的场景。

限制与注意：

  • 孵化期项目：尚未毕业，ASF 未完全背书；社区规模小（主仓星标 124），长期演进取决于小米及社区的持续投入；
  • 部署体量：平台整合 ES、Prometheus、Grafana 等多个组件，资源占用与运维复杂度显著高于单进程方案；
  • 官方宣称指标未经独立验证：如"1 分钟发现/5 分钟定位""存储成本低于千分之一"均为官方口径；
  • 若诉求是轻量部署、低资源占用的一体化可观测，建议同时评估 Uptrace/SigNoz/OpenObserve（见第七章）。

七、同类选型对比

面向"一体化开源 APM/可观测平台"的横向对比（星标数为 GitHub 仓库实查值，版本为各仓库 Releases 实查，查询日期 2026-10-19）：

方案形态当前状态最新版本GitHub Stars关键差异
Apache OzHera 2.2.6一体化 APM（K8s operator 部署）孵化中，活跃开发2.2.6-incubating（2026-06-17）124以应用为核心 + 业务可用性告警 + traceId 闭环；依赖 ES/Prometheus/Grafana 等组件
Uptrace一体化 APM（OTel 原生）活跃v2.1.0-rc.1（2026-10-08，预发布）4.3k基于 OpenTelemetry 与 ClickHouse 存储，轻量、单二进制风格
SigNoz一体化 APM（OTel 原生）活跃v0.146.0（2026-10-14）32kOpenTelemetry 原生 + ClickHouse，社区规模最大，日志/指标/追踪一体
OpenObserve一体化可观测（日志/指标/追踪）活跃v1.1.1（2026-10-16）22kRust 单二进制、低成本存储为卖点，日志场景强势

数据来源：各仓库 Releases 页（github.com/<org>/<repo>/releases.atom）与 shields.io 星标接口（查询日期 2026-10-19）。其中 OpenObserve 在本站有完整专栏与选型文档：《OpenObserve 介绍与选型指南》。

选型建议：看重"以应用为中心 + 业务可用性告警 + 中文生态"，且能承担多组件部署成本，可评估 OzHera；追求社区规模与 OTel 原生标准路线，选 SigNoz；追求轻量单进程与低资源占用，选 Uptrace 或 OpenObserve（日志为主选后者）。孵化期项目进入生产前务必做容量与稳定性实测。

八、参考链接