diff --git "a/docs/\345\217\257\350\247\202\346\265\213\346\264\236\345\257\237.md" "b/docs/\345\217\257\350\247\202\346\265\213\346\264\236\345\257\237.md" index e430723..93dbda5 100644 --- "a/docs/\345\217\257\350\247\202\346\265\213\346\264\236\345\257\237.md" +++ "b/docs/\345\217\257\350\247\202\346\265\213\346\264\236\345\257\237.md" @@ -1,212 +1,131 @@ # 可观测洞察 -> 调研时间：2026-10-26。范围：国内外可观测厂商的产品主线与技术路线，以及与本仓库（obs-sdk / 社区可观测 / CI 可观测）的关系。 -> 本文是**调研结论**，不是契约；字段与指标定义见 [spec/](../spec/README.md)，建设目标见 [可观测目标.md](可观测目标.md)。 - -## 0. 结论摘要 - -1. **采集层已经商品化**。OpenTelemetry 于 2026-05-21 从 CNCF 毕业，traces / logs / metrics 全 GA、Profiles 成为第四信号；厂商竞争整体上移到"数据底座、成本、以及 AI 驱动的分析与处置"。自研采集不再有价值，**语义对齐**才有。 -2. **2026 年的主战场是两件事**：Agentic Ops（AI 完成定位与处置）与 AI Agent 自身的可观测（Token、成本、效果）。前者仍在"调查可用、修复受控"的阶段，后者已形成语义约定与产品线。 -3. **对我们是利好**：现有的"契约先行 + 薄封装 + 黄金四信号 + 零埋点中间件"路线与行业方向一致；真正要补的只有三件低成本的事——**语义映射、标签纪律、CI 指标的标准命名**。 - ---- - -## 1. 技术趋势 - -| # | 趋势 | 一句话 | 成熟度 | -| --- | --- | --- | --- | -| 1 | 采集商品化 | OTel 毕业，语义约定成为新的契约层 | 已标准 | -| 2 | 零侵入 | eBPF / OBI 不改代码取指标与链路 | 生产可用 | -| 3 | Agentic Ops | 检测 → 假设 → 验证 → 处置的闭环 | 调查可用，修复受控 | -| 4 | AI Agent 可观测 | Token、成本、工具调用、效果评估 | 快速演进 | -| 5 | 成本治理 | 遥测数据的采样、聚合、分层与计价 | 已成选型首因 | -| 6 | 数据底座 | 存算分离、统一查询、变更观测 | 头部已落地 | - -### 1.1 采集层商品化：OTel 毕业，语义约定成为契约层 - -- OpenTelemetry 2026-05-21 成为 CNCF Graduated 项目，三家信号全部 GA，Profiling 进入规范。 -- 语义约定（semantic conventions）实际承担了"跨厂商字段契约"的角色：资源属性（`service.name` / `deployment.environment.name` / `service.instance.id`）、HTTP（`http.server.request.duration`）、异常（`exception.*`）、CI/CD（`cicd.*`，Release Candidate）都已成文。 -- `gen_ai.*` 已**迁出主仓**，由独立的 `semantic-conventions-genai` 仓维护（无 tag，按 commit 锚定），说明这一块的变动仍快。 - -**判断**：采集不是差异化，字段命名才是。字段一旦私有化，换后端、接 AI 工具都要重做。 - -### 1.2 零侵入：eBPF 走向默认 - -- Grafana 的 Beyla 已并入 **OpenTelemetry eBPF Instrumentation（OBI）**，通过 hook TLS 读写拿到明文 HTTP，无需改代码即可产出 span；对 LLM 流量还能直接按 GenAI 语义产出。 -- 同类：DeepFlow（云杉，AutoMetrics / AutoTracing）、groundcover、Pixie、Cilium Tetragon。 -- 国内阿里云已把 OBI 接入做成产品能力。 - -**判断**：资源层、网络层、框架层的信号会被零侵入方案吃掉；**业务语义**仍然只能靠埋点——这正是本仓库 T0（中间件）+ T2（业务指标）分层的价值所在。 - -### 1.3 从"看得见"到"能处置"：Agentic Ops - -- Datadog Bits 系列（SRE / Investigation / Code / Release / Agent Builder / Agent Evals），Dynatrace Intelligence（确定性 Davis + agentic AI），阿里云 STAROps（数字员工 + MCP），腾讯云 Multi-Agent 可观测工作台，以及 Resolve.ai、Traversal、Cleric 等新贵。 -- 共同点：**靠拓扑、变更、历史事件做 ground truth**，靠只读默认、写操作审批、审计日志做 guardrail。 - -**判断**：AI 诊断的上限由数据质量决定。字段乱、基数爆、缺变更信息，再强的 agent 也只能在噪声里猜。先把数据整理干净，比先买 AI 更有效。 - -### 1.4 AI Agent 自身成为观测对象 - -- 新指标层：输入/输出 Token、每任务成本、工具调用链、会话回放、完成率与效果评估。 -- 厂商动作：Datadog Agent Console / Tokenomics（跟踪 Claude Code、Cursor 等编码 agent 的用量与花费）、腾讯云 Agent 可观测（2026-09 上线）、博睿 AI 可观测、Dynatrace AI Observability app。 -- 工程共识：**评估（evals）与观测共用一个 trace store**，避免"链路在 A、评估在 B"的搬运成本。 - -**判断**：传统四信号解释不了非确定性的 agent 行为；如果将来要观测自家机器人调用 LLM，需要另起一层语义，而不是硬塞进 HTTP 指标。 - -### 1.5 成本治理成为一等公民 - -- Grafana **Adaptive Telemetry** 四信号闭环（Metrics / Logs / Traces / Profiles，Profiles 于 2026-08 GA），用自适应聚合与采样降本；Cribl 专做遥测管道；各家普遍支持尾部采样与分层存储。 -- 计价模式在变：从 per-host 转向 per-GB、per-credit、按命名指标数（Datadog Infinite Cardinality）。 -- 行业调查中，**成本已超过功能成为选型的首要标准**。 - -**判断**：厂商的做法本质是"事后补救"——先收全量再压缩。我们的规模下，**从源头控制基数**（高基数不进 label、路由模板、不重复埋点）是同等有效且更便宜的做法。 - -### 1.6 数据底座：统一查询与变更观测 - -- Dynatrace Grail、阿里云 UModel、博睿 Titan、观测云 GuanceDB 3.0、Observe 的 S3 湖：方向一致——**存算分离 + 一套查询同时覆盖指标/日志/链路**。 -- 新兴信号：**变更**被提升为一级数据（观测云把 Jenkins / GitLab / K8s Events / Nacos 的变更纳入叠加分析与风险评分），因为多数故障由变更触发。 - -**判断**：我们已有 Prometheus + LTS + Grafana 的组合，底座不必重建；缺的是把"变更"作为维度接进大盘（发布、配置、镜像 tag）。 - ---- - -## 2. 厂商趋势 - -### 2.1 国际格局：AI 与成本重塑排名 - -Gartner 2026 年 7 月《可观测平台魔力象限》（19 家）： - -| 象限 | 厂商 | -| --- | --- | -| Leader（8） | Chronosphere、Coralogix、Datadog、Dynatrace、Elastic、Grafana Labs、IBM、New Relic | -| Challenger（5） | Alibaba Cloud、AWS、LogicMonitor、Microsoft、Splunk | -| Visionary（2） | BMC Helix、Honeycomb | -| Niche（4） | Apica、HPE、ScienceLogic、SolarWinds | - -与 2025 年版（20 家，Leader 为 Chronosphere、Datadog、Dynatrace、Elastic、Grafana Labs、IBM、New Relic、**Splunk**）相比，本轮的净变化只有两处：**Splunk 降至 Challenger；Coralogix 由 Visionary 升入 Leader**。Chronosphere 是**连续第三年** Leader，不是新晋。 - -报告主题明确指向 AI 工作负载（LLM / agent 观测、agentic AIOps）、遥测成本控制与 OTel 原生摄入，这是 Gartner 与媒体一致的口径。但要注意两点： - -- 魔力象限的坐标轴是 **Completeness of Vision × Ability to Execute**，Challenger 的含义是**执行仍强、愿景相对落后**，不等于某项能力（如 AI）弱； -- Gartner 不公开逐家评分与理由。公开材料能证实的只有 **Coralogix 在 Cost Optimization 用例排第 3**；Splunk 下移更可能与 Cisco 体系内的产品整合与路线图清晰度有关（AppDynamics / Splunk Observability / ThousandEyes 存在重叠），而不是 AI 能力——它恰恰是 2026 年 AI 动作最大的一家（AgenticOps、收购 Galileo）。 - -### 2.2 三条产品路线 - -| 路线 | 代表 | 优势 | 代价 | -| --- | --- | --- | --- | -| **平台型**（全栈 + AI 编排） | Datadog、Dynatrace、Splunk/Cisco、New Relic、阿里云、腾讯云 | 开箱即用、AI 能力强、体验统一 | 价格高、迁移成本高、数据主权受限 | -| **开源 / OTel-native**（可退出） | Grafana Labs、Honeycomb、Chronosphere、groundcover、SigNoz | 数据可导出、成本可控、无锁定 | 运维成本自担、能力需自行拼装 | -| **遥测管道 / 成本层** | Cribl、Observe | 不换后端即可降本、做脱敏与路由 | 多一层组件、只解决成本不解决分析 | - -**判断**：我们走的是第二条路线（Prometheus + Grafana + LTS 自建），退出成本低是结构性优势，应继续守住"数据可导出、字段可映射"。 - -### 2.3 新贵与并购：能力正被大厂吸收 - -- **AI SRE**：Resolve.ai（创始团队含 OTel 共同作者，2026 年估值约 15 亿美元）、Traversal（因果 ML、默认只读）、Cleric（只读 + 受控写）等；同时 Azure SRE Agent、AWS DevOps Agent 已内置于云平台。 -- **LLM 观测**：Langfuse、LangSmith、Arize（Phoenix / AX）、Braintrust，以及 OpenLLMetry（Traceloop，已被 ServiceNow 收编）。 -- **并购**：Cisco 收购 Galileo 补 Agent 观测与 guardrail；Datadog、Dynatrace 持续把 agent 能力并入主平台。 - -**判断**：单点工具的窗口在收窄，自建 AI 诊断的窗口同样在收窄——这类能力更适合"买/接"，而不是"造"。 - -### 2.4 国内市场：云厂商一体化 vs 独立厂商 + 信创 - -| 厂商 | 2026 主线 | -| --- | --- | -| 阿里云 | CMS + SLS + ARMS 合并为**云监控 2.0**，以 UModel 统一模型为底座；**STAROps** 提供数字员工与 SRE Agent；ARMS 的 LLM 监控更名为 **AI Agent 可观测**；已产品化 OBI 接入 | -| 腾讯云 | TCOP 的 Multi-Agent 可观测工作台、SRE Agent、向 L4 无人值守演进；2026-09 上线 **Agent 可观测**（全链路、Token 成本、效果评估）；200+ 云产品 MCP | -| 华为云 | AOM 整合 APM / LTS / CES / Prometheus，AOM 2.0 以应用为中心；**2026 年公开的新能力明显少于阿里/腾讯**，更多是与伙伴联合交付 | -| 火山引擎 | APMPlus 走开放路线，允许第三方探针（如博睿）上报 | -| 博睿数据 | Bonree ONE 4.0：AI 可观测 + Sage AI 运维智能体工作台 + 统一读写引擎；IDC APMO 份额居首 | -| 观测云 | Obsy AI SRE Agent、Blueprint 低代码编排、**变更观测**、GuanceDB 3.0 存算分离 | -| 开源 | DeepFlow（eBPF 零侵入）、夜莺 Nightingale（Prometheus 上层告警）、OpenObserve（S3 低成本日志） | - -**判断**：国内厂商在 Agentic Ops 上的宣传比国外更激进，但落地同样受限于数据质量与权限边界；选型时应看"数据能不能导出、字段能不能映射"，而不是看 agent 的演示。 - -### 2.5 定价与采购关注点 - -- 计价从 per-host 转向用量型（per-GB / per-credit / 按指标数），因为 autoscaling 让 per-host 失真。 -- 采购关注点排序变为：**成本 → OTel / OTLP 兼容 → 可退出性（数据导出）→ AI 能力 → 功能覆盖**。 -- 与我们相关的一条：**不要把可观测数据锁进任何不可导出的后端**；LTS、Prometheus 都支持导出，这是我们的优势，也是将来接 OTLP 的后路。 - ---- - -## 3. 自身相关性 - -### 3.1 已被验证正确的三件事 - -1. **薄封装、不自研 instrumentation**——采集层已被 OTel / OBI 商品化，自研没有价值；我们只做装配与约定，方向正确。 -2. **黄金四信号 + T0 零埋点中间件 + T2 业务指标**——资源层交给官方 instrumentation，业务层才埋点，与行业"零侵入 + 业务语义"的分工一致。 -3. **契约先行**——`spec/` 的四语言契约，本质是一份私有语义约定；它让我们可以在不依赖任何厂商的前提下保证跨语言一致。 - -### 3.2 现在就该做的三件事（低成本、高杠杆） - -| 动作 | 产出 | 状态 | +## 1. 可观测技术通用实现 + +**一张图看全貌**： + +```mermaid +flowchart TB + subgraph S1["① 采集"] + direction LR + a1["自研服务
SDK 埋点"] + a2["第三方 / 开源
pull exporter"] + a3["Agent / 模型运行时
非确定性进程"] + a4["日志
stdout / 文件"] + a5["内核 / 网络
eBPF（OBI）"] + a6["平台 / 作业
轮询平台 API"] + a1 ~~~ a2 ~~~ a3 ~~~ a4 ~~~ a5 ~~~ a6 + end + + subgraph S2["② 归一与传输"] + direction TB + b1["Agent · DaemonSet
富化 k8s 元数据 · 批处理 · 限流"] + b2["Gateway · 有状态
尾采样 · 脱敏 · 扇出 · 路由"] + b1 -->|"按 trace_id 路由"| b2 + end + + subgraph S3["③ 存储"] + direction LR + c1["Metrics → 时序库"] + c2["Logs → 倒排 / 列存"] + c3["Traces → 对象存储 + ID 索引"] + c4["Profiles → 采样栈聚合"] + c1 ~~~ c2 ~~~ c3 ~~~ c4 + end + + subgraph S4["④ 关联和查询"] + direction LR + d1["时间窗"] + d2["资源身份
service / instance / pod"] + d3["请求身份
trace_id / run_id"] + d4["会话身份
conversation_id · 轨迹"] + d5["exemplar · service graph · 三向跳转"] + d1 ~~~ d2 ~~~ d3 ~~~ d4 ~~~ d5 + end + + subgraph S5["⑤ 消费"] + direction LR + e1["大盘：总览 → 服务 → 实例"] + e2["SLO 告警：症状驱动 · 多窗口燃尽率"] + e3["事故流程：分组 / 抑制 / 静默"] + e4["AI 诊断 → 受控自愈"] + e5["成本预算 · 行为审计 · 效果评估"] + e1 ~~~ e2 ~~~ e3 ~~~ e4 ~~~ e5 + end + + S1 -->|"push · pull · 旁读"| S2 + S2 --> S3 + S3 --> S4 + S4 --> S5 +``` + +### 1.1 关键模块与成熟度 + +**收敛度**按「换实现要不要重做」判定，不看有几种实现：**收敛** = 每类问题都有公认答案、换实现不改模型； +**发散** = 换实现要重做，或根本没有答案。发散的来源只有两种 —— **新事物还没有答案**、**厂商各自下注**。 +（「平台轮询」是长尾特例：每接一个平台写一个适配器，不构成产品类别，不计入这两类。） + +| 段 | 模块 | 标准实现 | 成熟度 | 收敛度 | +| --- | --- | --- | --- | --- | +| **① 采集** | SDK 埋点 | OTel SDK| 高（traces / metrics 稳定 · logs 基本稳定 · profiles experimental） | 收敛 | +| | 语义约定 | OTel semconv | 分域定级（HTTP / DB / RPC / messaging stable · GenAI、CI/CD 仍 experimental / RC） | 分域：其余收敛 · GenAI / CI/CD 发散（新事物） | +| | 三方 exporter | `/metrics` 端点 + Prometheus 文本格式 | 高（事实标准，非 OTel） | 收敛 | +| | 旁读采集 | Fluent Bit / Vector | 高（事实标准强于官方标准） | 收敛 | +| | eBPF | OBI（原 Grafana Beyla） | 中（已并入 OTel） | 收敛 | +| | 平台轮询 | 无 | — | 发散（长尾） | +| **② 归一与传输** | agent · gateway | OpenTelemetry | 高 | 收敛 | +| **③ 存储** | 时序库 | Prometheus 数据模型（Prometheus / VictoriaMetrics / Mimir / Thanos） | 高 | 收敛 | +| | 日志库 | Loki / ES / ClickHouse 三足鼎立 | 高 | 发散（厂商各自下注） | +| | trace 库 | Tempo / Jaeger / ClickHouse 系 | 高 | 收敛 | +| | profile 库 | Pyroscope / Parca | 中 | 未定型 | +| | 统一引擎 | ClickHouse / GreptimeDB / SigNoz | 中，无标准 | 发散（厂商各自下注） | +| **④ 关联和查询** | 关联键 · 时间窗 / 资源身份 / 请求身份 | W3C trace context + OTel resource semconv | 高 | 收敛 | +| | 关联键 · 会话身份（Agent 轨迹） | 无（仅实验性 `gen_ai.conversation.id`） | 低 | 发散（新事物） | +| | exemplar | OpenMetrics | 中（exporter 不支持、采样丢目标、SDK 要手动开） | 收敛 · 落地不全 | +| | service graph / span metrics | Collector connector | 中（只画得出被埋点过的边） | 收敛 | +| | 跳转 UI | 无 | 低（Grafana 靠手配 data link） | 发散（厂商各自下注） | +| **⑤ 消费** | 大盘 | Grafana（事实标准） | 高 | 收敛 | +| | SLO / burn-rate | Google SRE 方法论 + OpenSLO（CNCF sandbox） | 中 | 半收敛 | +| | 分组 / 抑制 / 静默 / 路由 | Alertmanager（事实标准） | 高 | 收敛 | +| | AI 诊断 → 自愈 | 无 | 无 | 发散（厂商各自下注） | +| | 成本预算 · 行为审计 · 效果评估 | 无（Langfuse / Phoenix / LangSmith 各自为政） | 低 | 发散（厂商各自下注） | + +**一句话**：发散只有两个来源：**新事物还没有答案**（Ops for AI），**或厂商各自下注**（AIOps）。 + +## 2. 业界实践 + +各挑一个代表：开源看 **Grafana Labs** —— 唯一把五段做齐的开源栈；商业看 **Datadog** —— 一体化最完整的一家。 + +### 2.1 开源阵营：Grafana Labs + +一家把五段全做齐了 —— 这在开源里是独一份，所以拿它当代表最合适。 + +| 段 | 对应产品 | 怎么实现 | | --- | --- | --- | -| **字段语义映射** | [spec/otlp-mapping.md](../spec/otlp-mapping.md)：落盘字段 → OTel 语义键 | 已完成，PR #40 | -| **标签纪律 = 成本治理** | 继续执行"高基数不进 label、路由模板、不重复埋点"；这是比 Adaptive Metrics 更早、更便宜的成本控制 | 已有铁律，需在 review 中守住 | -| **CI 指标对齐 `cicd.*`** | semconv 已有 `cicd.pipeline.*` / `cicd.pipeline.task.*` / `cicd.worker.*`（Release Candidate），可用于统一 CI 观测的命名 | 待评估 | - -关于第三点：CI 可观测是商业厂商覆盖最薄的地方——Datadog / Dynatrace 的 CI 能力主要停留在"接 CI 事件"，没有像 Kubernetes 那样的完整语义。我们自建 `ci-workflow-aggregator` 反而有机会**直接用 semconv 的 CI/CD 词汇**，让指标天然可移植。注意该组属性仍是 RC，需锁版本。 +| ① 采集 | **Alloy** | 本质是 OpenTelemetry Collector 的发行版。Grafana 把原来的 Promtail、Grafana Agent 全部并入 Alloy（Agent 已停维护），一个 agent 同时采 metrics / logs / traces / profiles。所以开源阵营的采集也是 OTel | +| ② 归一与传输 | **Alloy** | 同一份二进制兼做 agent 和 gateway，靠 OTel pipeline 配置。开源侧没有第二个选择 | +| ③ 存储 | **LGTM + Pyroscope** | Loki（日志）· Grafana（展示）· Tempo（链路）· Mimir（指标），各一套引擎，全部对象存储为底，按信号分开存。这是「拼装」的典型：四种信号四个库 | +| ④ 关联 | **Grafana + 各库自带能力** | exemplar 存进 Mimir、`derivedFields` 从 Loki 日志里抓 `trace_id`、Tempo 的 `metrics-generator` 产出 span metrics 与 service graph —— 每一条关联链路都要人配，配通就是端到端，配不通就是四个孤岛 | +| ⑤ 消费 | **Grafana Alerting · Grafana SLO · OnCall** | 告警在 Grafana 里统一；SLO 和 IRM 是商业版 / Cloud 功能，不开源 | -### 3.3 需要预留的两件事 +**要点**：Grafana Labs 是「用开源组件拼出一个产品」的路线。它的开源边界一直推到存储层（LGTM 与 Pyroscope 都开源），所以「自建一套完整可观测」在这条路上是可行的 —— 代价是许可证是 AGPLv3，且要自己运维四套存储。 -1. **trace 二期直接接 OTel SDK**，不要自造上下文传播与 ID 生成。`spec/common-fields.md` 已预留 `trace_id` / `span_id` 注入位，且落盘格式与 W3C trace context 一致，接入时零格式返工。 -2. **`gen_ai.*` 只登记、不实现**。若机器人将来调用 LLM，按 `semantic-conventions-genai` 当前定义埋点；会话 ID、工具调用 ID 等高基数值只进日志 / span，禁止进 metric label。 +### 2.2 商业阵营：Datadog -### 3.4 明确不做的四件事 - -| 不做 | 理由 | -| --- | --- | -| 自研采集 agent / eBPF 埋点 | 已是商品，维护成本远高于收益 | -| 自建 Agentic Ops | 平台商品化 + 我们的故障规模不匹配；先把数据整理干净 | -| 引入重型商业平台 | 成本与锁定风险；现有 Prometheus + Grafana + LTS 足够 | -| 为"AI 可观测"先埋一批高基数指标 | 基数爆炸的代价由我们承担，收益要等真有 LLM 调用再说 | +| 段 | 对应产品 | 怎么实现 | +| --- | --- | --- | +| ① 采集 | **单一 dd-agent** | 一个 Agent 出全部信号：指标、日志、APM 链路、Continuous Profiler、进程、还有 eBPF 的 USM。不靠拼，靠一个进程全拿 | +| ② 归一与传输 | **没有独立组件** | 环节本身没省：批处理、打标、聚合在 Agent 侧，过滤、采样、限流在服务端（Ingestion Control）—— 只是没做成可独立部署的 gateway。不设 gateway，因为不打算让你换后端 | +| ③ 存储 | **全部自研** | 指标自研时序库、日志与链路走自研列存 Husky、profile 自研；后来叠加 Flex Logs 这类对象存储冷层。一套体系按信号分层，不是四个库 | +| ④ 关联 | **Related Assets · Service Map · USM** | 不用 exemplar，不用 data link —— 因为指标、日志、链路、profile 本来就躺在同一个后端里，关联是 join 出来的，不是配出来的。服务图由 APM + eBPF 自动生成 | +| ⑤ 消费 | **Monitor · Incident Response · Bits AI** | 告警、值班、事故流程一体；Bits AI（2024 起）做告警摘要与自动调查 | -### 3.5 风险与边界 +**要点**：Datadog 走的是「单库贯通」路线。它对「跳转」这件事的解法不是补协议，而是消灭跨库。**五段流程一段没省，只是把相邻环节合并、跨进私有实现** —— 代价是数据形态私有、按主机 / 指标基数 / 日志量 / span 数计费、换不出去。 -- **语义约定版本漂移**：`gen_ai.*` 已迁仓、`event.name` 已废弃、`code.filepath` 已改名；映射表必须锁版本（当前锚定 semconv v1.44.0）。 -- **`community` 的位置**：请求级可变，只能作日志/指标属性，**不能进 Resource**，否则中心化服务会把整进程数据写死成一个社区。 -- **LTS 与 OTLP 生态的适配未验证**：如果把日志迁到 OTLP 后端，需要先确认 LTS 的摄入能力；在验证之前只承诺"可映射"，不承诺"可切换"。 -- **自建 CI 观测的维护成本**：aggregator 与事件 agent 是长期负债，命名对齐 semconv 能降低将来替换的成本，但不能消除维护成本。 +### 2.3 小结 ---- +五段流程（采集 / 归一与传输 / 存储 / 关联和查询 / 消费）是行业共同的标准实现 —— 开源与商业都完整履行，没有一家跳过环节。 +差别在环节的边界：开源阵营把每段做成独立可替换的组件，商业阵营把相邻环节合并、跨到私有实现里。 +分离部署 = 可换；合并部署 = 一体化 + 锁定。 -## 4. 行动建议 -| 优先级 | 动作 | 产出 / 验收 | -| --- | --- | --- | -| P0 | 合入 OTLP 映射附录，并在 spec README 中索引 | [spec/otlp-mapping.md](../spec/otlp-mapping.md)（PR #40） | -| P0 | 把"高基数不进 label、路由模板、不重复埋点"写进 PR review 清单 | review 时可对照 checklist | -| P1 | 评估 CI 指标向 `cicd.*` 对齐的改动面（含 `platform` 标签） | 一份差异清单，不改现有大盘 | -| P1 | 在状态页定义 SLO 与错误预算（burn rate），与四信号衔接 | 状态页可用度口径统一 | -| P2 | trace 二期：接 OTel SDK，打通日志的 `trace_id` / `span_id` | 一条日志可跳到对应 trace | -| P2 | 验证 OTel Collector 出口（`filelog` / `prometheus` receiver） | 一条链路跑通即可，不进生产 | - ---- - -## 附：信息来源与口径 - -调研时间 2026-10-26。厂商发布内容多为厂商口径，数字（份额、降本比例、自主率）应以官网或财报为准；部分二手对比站点有 AI 生成痕迹，本文只引用可交叉核对的事实。 - -**标准与规范** - -- [CNCF：OpenTelemetry 毕业公告](https://www.cncf.io/announcements/2026/05/21/cloud-native-computing-foundation-announces-opentelemetrys-graduation-solidifying-status-as-the-de-facto-observability-standard/) -- [OpenTelemetry：毕业之后](https://opentelemetry.io/blog/2026/otel-grad-now-what/) -- [semantic-conventions v1.44.0](https://github.com/open-telemetry/semantic-conventions/releases/tag/v1.44.0) -- [semantic-conventions-genai](https://github.com/open-telemetry/semantic-conventions-genai) -- [OTLP logs.proto（LogRecord 字段）](https://github.com/open-telemetry/opentelemetry-proto/blob/main/opentelemetry/proto/logs/v1/logs.proto) - -**市场与厂商** - -- [Gartner MQ 2026（Grafana 解读）](https://grafana.com/blog/grafana-labs-named-a-leader-again-in-the-2026-gartner-magic-quadrant-for-observability-platforms/) -- [Coralogix 2026 MQ（含 Cost Optimization 排位）](https://coralogix.com/gartner-magic-quadrant-for-observability-platforms-2026/) -- [Chronosphere 2026 MQ（连续第三年 Leader）](https://chronosphere.io/2026-gartner-magic-quadrant-for-observability-platforms/) -- [AI workloads shake up observability market（Network World）](https://www.networkworld.com/article/4197973/ai-workloads-shake-up-observability-market.html) -- [DASH 2026 汇总](https://www.datadoghq.com/blog/dash-2026-new-feature-roundup-keynote/) / [Bits AI](https://www.datadoghq.com/product/ai/bits-ai-agents/) -- [Dynatrace Intelligence 发布](https://www.dynatrace.com/news/press-release/dynatrace-intelligence-redefines-observability/) -- [Grafana Adaptive Telemetry GA](https://grafana.com/press/2026/08/04/grafana-labs-gives-every-observability-signal-an-intelligent-optimization-layer-completing-adaptive-telemetry-suite-with-adaptive-profiles-ga/) -- [阿里云云监控 2.0](https://www.alibabacloud.com/help/zh/cms/cloudmonitor-2-0/what-is-cloud-monitor-2-0) / [ARMS 升级为 AI Agent 可观测](https://www.alibabacloud.com/help/zh/arms/product-overview/platform-upgrade-notification-that-arms-llm-application-monitoring-is-upgraded) -- [腾讯云 Agent 可观测上线](https://news.qq.com/rain/a/20260921A09JSI00) -- [博睿 Bonree ONE 4.0 发布实录](https://m.eeo.com.cn/2026/0526/891585.shtml) -- [观测云 2026 产品路线图](https://www.eet-china.com/mp/a466186.html) -- [国内可观测厂商对比](https://quant67.com/post/observability/23-china-vendors/china-vendors.html)