作者：来自 Elastic David Hope

在我作为开发者、 SRE ，以及现在的可观测性产品负责人的20年里，软件通常以一个稳定的速度发展。但现在，两项变革性技术的出现正在从根本上重塑企业可观测性：生成式 AI（ GenAI ）和 OpenTelemetry（ OTel ）。

我们为一份新报告调查了超过 500 位 IT 决策者：《2026 年可观测性现状：在成本与创新之间取得平衡》。数据证实了许多从业者的直觉：这些已经不再是科研项目。它们已经进入生产环境，正在重塑厂商决策，并改变团队实际的工作方式。

生成式 AI：炒作是真实的，但局限性也同样存在

如今，85% 的组织在可观测性中使用某种形式的 GenAI 。在两年内，这一数字将达到 98% 。到那时，这将成为任何值得评估的平台的基本门槛。

为什么这么快？可观测性产生的数据规模大到人类无法手动处理。在一次事件中关联日志、指标和追踪，以前需要一名能够在脑中容纳整个系统拓扑的工程师。 GenAI 自动化了这种模式识别，并让团队可以用自然语言查询遥测数据。

这就是承诺。但现实更加复杂。

团队实际上是如何实现生成式 AI 的

由于没有任何一种方法能把所有事情都做好，组织通常会同时运行多种方案。

独立工具（如 ChatGPT 和 Claude ）以及平台内置能力的采用率几乎相同，分别为 53% 和 52% 。两者都无需定制开发即可轻松部署。

然后，发展轨迹开始分化。

• 15% 计划增加独立的 GenAI
• 23% 计划专注于内置功能
• 厂商集成的 GenAI 在两年内达到 75% 的采用率

这很合理；独立工具缺乏上下文。你可以把日志粘贴到 ChatGPT 中，但它并不了解你的服务依赖关系或部署模式。它适合用于临时的分析，但不适合生产工作流。厂商集成的解决方案在上下文已经存在的情况下运行在你的数据之上。

为可观测性专门构建的 GenAI 和 agentic AI 需要更多的集成工作。目前采用率较低，但在已经超越基础阶段的团队中，兴趣很高。

GenAI 的成熟度比预算更重要

早期阶段的团队显示出 71% 的 GenAI 采用率，而成熟组织为 85%–88%。更有意思的模式在于他们使用哪种 GenAI 解决方案。

独立的通用 GenAI 在不同成熟度水平上保持不变，因为它在任何地方都很容易采用。差距出现在可观测性特定的实现上。厂商集成的、专用的，以及 agentic AI 与成熟度高度相关。

agentic AI 的表现尤其明显。这些自主系统可以在无人启动的情况下调查问题、关联数据并执行修复。目前有 23% 的团队在使用，另外还有 38% 计划使用。按成熟度划分：

• Expert 团队：35%
• Mature 团队：28%
• In-process：17%
• Early-stage：0%

Early-stage 为零，是因为 agentic AI 有一些前置条件，而 Early-stage 团队通常不具备：全面的遥测数据、一致的 schema、已文档化的依赖关系、已编码的 runbook，以及成熟的事件响应流程。如果你还没有定义清楚什么是修复，就无法部署自主修复。

如果你仍在构建基础覆盖，先关注厂商集成的 GenAI。真正自主的那部分可以以后再做。

使用 GenAI 的可观测性团队效率提升有限 —— 目前如此

68% 的团队报告效率有所提高；只有 14% 称提升显著。其余团队只看到适度改进。GenAI 有帮助，但对大多数团队来说，还没有彻底改变运营。

未来五年的预测显示，84% 的团队预计效率会提高，56% 预计会有显著提升 —— 是当前水平的 4 倍。

这个差距很合理。目前的实现都是第一代，应用范围有限。团队仍在摸索有效的工作流。这与其他自动化技术类似 —— 最初的提升有限，直到流程围绕新能力重组后才显现。

效率真正体现的地方在于让现有数据可访问。许多组织的数据湖未被充分利用，因为只有少数工程师知道如何查询；数据就这样闲置。自然语言接口让这些投资重获价值。过去需要专家花费数分钟完成的查询，现在任何人都能在 60 秒内完成。

仅这一点，就足以让许多团队投资，即使没有自主修复功能。

GenAI 实际有效的可观测性领域

关联和自动化推动最高价值的应用：

• 日志、指标、追踪的自动关联（58%）：在事件中连接不同类型的 telemetry 信号。过去需要熟悉整个系统的人来完成。
• 根因分析（49%）：跨故障模式、依赖关系和历史数据进行模式匹配。
• 修复和自动化操作（48%）：执行已知流程、扩展资源、应用修复。需要设置保护措施。
• 未知未知（47%）：AI 识别未被监控的异常。在分布式系统中尤其有用，因为人工告警总有漏洞。
• 助手任务（47%）：报告、仪表板和查询优化。让非专业人员也能使用 observability。

这些担忧是合理的

99% 的人对 observability 的 GenAI 有担忧。具体如下：

安全和数据泄露排在首位，占 61%。Telemetry 往往包含敏感信息。将其发送到外部 LLM 是一个合理的问题。这也推动了对供应商解决方案的偏好，这类方案能在现有安全边界内保留数据。

幻觉问题占 53%。AI 会自信地生成错误信息。在事件响应中，根据错误信息行动会使故障加重。

成功使用 GenAI 的团队把输出当作假设，而不是结论。保持人类在环中，AI 可以识别需要升级的设备，发现有问题的配置，并找出历史数据中的模式。你负责验证和执行。即使不让 AI 做决策，也能节省时间。

让 AI 在无人审查的情况下做改动很危险。一个 AI 工具可能决定打开所有防火墙端口，并自信地解释为什么这是好主意 —— 实际上并不是。保护措施和人工审查仍不可或缺，也许一段时间内都如此。

整体上，对 GenAI 有用性的怀疑很低，仅 24%。团队不是质疑价值，而是在解决实施问题。技术有效，只是还不成熟，所以要相应对待。

LLM observability：人人计划，却无人完成

部署 GenAI 用于 observability 的组织，也在构建需要监控的内部 GenAI 应用。85% 计划启用 LLM observability，但只有 8% 完成。36% 正在进行中；41% 有计划但尚未开始。

可能有两个原因。

1. 内部 GenAI 开发是新的，而 LLM observability 需要传统框架不具备的能力，比如 token 跟踪、prompt 有效性、响应质量、LLM 特有延迟和成本归因。
2. 94% 的团队正在实施或计划实施，因为 GenAI 应用需要像任何生产系统一样的严格性。

早期实施者获得了其他人没有的可见性，其余团队在自己的 AI 上基本是盲操作。

OpenTelemetry：正成为 observability 数据的默认选择

OTel 在生产环境中的使用同比几乎翻倍，从 6% 增至 11%。绝对数字仍然有限，但趋势显示加速。

• 36% 的团队正在试验（比之前的 31% 增加），但尚未进入生产阶段。
• 33% 的团队在评估他们的选项。
• 19% 的团队对 OTel 采纳不感兴趣。

总体来看，这是早期采用。但对于新的服务监控，OTel 正日益成为默认选择。真正重要的不是采纳百分比，而是团队从评估阶段进入生产阶段时发生的变化。

生产经验改变一切

在已经将 OTel 投入生产的组织中，89% 认为供应商合规性至关重要或非常重要；而在仍处于评估阶段的团队中，只有 37% 认为其至关重要或非常重要。

生产阶段会教你什么最重要。完整的规范支持、语义约定处理、无需增加延迟或丢失精度的直接 OTel 摄取。真正符合 OTel 的解决方案在生产环境中至关重要。

随着更多实现进入生产阶段，供应商对 OTel 的支持从差异化特性变为必需条件。缺乏强大原生集成的供应商会被排除在考虑之外。

供应商发行版正在领先

供应商提供的 OTel 发行版从 44% 增加到 60% —— 同比增长 36%。自定义和原生发行版下降。

供应商发行版集成更容易，包含支持，并针对特定用例优化。维护自定义发行版需要工程资源、构建专业知识、测试基础设施和文档 —— 大多数团队有更好的方式使用这些能力。

仍然优先考虑供应商独立性的组织会选择自定义发行版。更广泛的市场则偏向便利性。

根本性变化是数据收集正在商品化。OTel 以供应商中立的方式处理机制。价值和差异化在于摄取之后发生的事情 —— AI 驱动的洞察、调查加速和结果优化。这才是现在有趣的问题所在。

2026 年的 Observability 供应商选择

GenAI 与 OpenTelemetry 的采用融合，为评估 observability 供应商创建了新的标准。组织必须评估：

• GenAI 集成：供应商提供的集成功能在价值实现时间上优于自定义集成。预计 75% 的采用率使其成为标准评估标准。
• Agentic AI 路线图：需求随成熟度增加。在承诺前验证护栏和人工参与控制。
• OTel 支持：89% 的生产用户认为合规至少非常重要，包括完整规范、语义约定和原生摄取。
• LLM observability：85% 计划实施，其中令牌跟踪、提示管理和成本归因是供应商差异化因素。
• 安全性：61% 在实施 GenAI 时将安全性视为主要关注点。供应商需要强大的控制和透明度。

2026 年 observability 的勇敢新世界

GenAI 和 OpenTelemetry 正从新兴技术转向基础设施。预计 GenAI 在两年内达到 98% 的采用率。OTel 增长缓慢但稳定，随着实施成熟，其战略重要性不断提升。

供应商选择标准正在变化。集成 GenAI、全面的 OpenTelemetry 支持以及 LLM observability 功能成为 observability 平台的必需条件。在这些领域投入的供应商处于有利位置，其余供应商将面临劣势。根据这些新要求评估你的解决方案，因为延迟会带来风险，行业不会等待。

想了解 observability 领导者如何管理 observability 成熟度、成本管理及最大化 observability ROI 的战略举措，请阅读本配套博客。或下载完整报告：2026 年 Observability 全景：平衡成本与创新。

本博客中描述的任何功能或特性发布及时间完全由 Elastic 决定。任何当前不可用的功能或特性可能不会按时或根本不会提供。

在本博客中，我们可能使用或提及第三方 generative AI 工具，这些工具归其各自所有者拥有和运营。Elastic 对这些第三方工具没有控制权，也不对其内容、操作或使用承担任何责任，亦不对你使用这些工具可能产生的任何损失或损害负责。使用涉及个人、敏感或机密信息的 AI 工具时，请谨慎操作。你提交的任何数据可能用于 AI 训练或其他用途。无法保证你提供的信息会被安全或保密。请在使用前熟悉任何 generative AI 工具的隐私实践和使用条款。

Elastic、Elasticsearch 及相关标志为 Elasticsearch B.V. 在美国及其他国家的商标、标识或注册商标。其他公司和产品名称均为其各自所有者的商标、标识或注册商标。

原文：https://www.elastic.co/blog/2026-observability-trends-generative-ai-opentelemetry