Elastic 新的指标能力将显著提升公共部门 IT 的正常运行时间

作者:来自 Elastic Leanne Link, Abhi Pandey

Elastic Observability 中新的列式指标引擎使公共部门 IT 团队能够在一个平台中整合日志、指标和 traces。因此,SRE 可以提升正常运行时间,同时在此过程中保护纳税人的资金。

公共部门站点可靠性工程师(SRE)面临着一系列独特压力,无论他们支持的是联邦机构、卫生部门、公立大学,还是交通管理机构。你需要在复杂的混合基础设施环境中维持任务关键型服务的正常运行时间,同时还要面对严格的审计和合规要求。此外,你必须向监督机构、立法者以及所服务的公众证明每一笔 IT 支出的合理性。

可观测性工具市场长期以来让最后一点变得困难;具备最佳能力的平台通常也是最昂贵的平台,而最昂贵的平台往往会因为现代基础设施所需的丰富数据采集而向你收取额外费用。当成本失控时,常见的应对方式就是减少数据采集、缩短数据保留时间,或者完全跳过高基数指标。在凌晨 2:00 发生影响公众服务、学生门户网站或医院系统的故障时,缺失的上下文信息可能决定快速解决问题还是经历长时间服务中断。

Elastic 最近推出了重构后的指标能力,改变了这一局面,包括完整的列式指标引擎、原生 Prometheus 和 PromQL 支持、开箱即用的基础设施内容,以及基于 agent 的调查工作流。因此,公共部门 IT 团队可以获得完整的运营可见性,而无需接受过去迫使团队在覆盖范围和预算之间做选择的成本权衡。

使用统一平台处理日志和指标,减少可观测性债务

许多公共部门组织已经依赖 Elastic 进行经济高效的日志存储和保留,尤其是为了满足美国政府相关要求,例如 OMB Memorandum M-26-14。

现在,同样值得信赖的日志基础能力也扩展到了指标领域。大多数运行现代基础设施的公共部门组织,都已经因为工具孤岛积累了可观测性债务:一个系统用于日志,另一个用于指标,还有第三个用于 traces。每种信号都存储在不同的后端,使用不同的查询语言,并且需要不断切换上下文才能完成关联分析。当故障发生时,工程师只能在压力环境下,手动跨多个互不连接的系统拼凑出完整情况。

Elastic Observability 将指标、日志和 traces 存储在一个统一后端中。当告警触发时,调查所需的上下文已经被整理好,包括关联的日志事件、之前出现的指标异常,或者相关 trace。工程师不需要打开三个不同的标签页才能形成初步判断。机器学习(ML)异常检测会自动针对基础设施指标运行,因此告警不仅会显示原始阈值超出情况,还会提供发生了什么变化以及偏差严重程度的上下文信息。对于负责管理公众依赖服务的公共部门 SRE 来说,这意味着更快的平均修复时间。对于管理层来说,这意味着更少的长期服务中断,以及更少花费在人工关联分析上的人员时间。

部署灵活性:Cloud、本地部署、隔离网络环境

Elastic Observability 支持三种部署模式:Elastic Cloud Serverless、Elastic Cloud Hosted,以及完全自管理的本地部署或隔离网络(air-gapped)环境。与一些限制本地部署能力,或者只在托管实例中提供最高价值功能的厂商不同,Elastic 的完整能力在这三种模式中均可使用。对于具有严格数据驻留要求的组织,可以在自己的基础设施中运行完整平台,而无需牺牲功能能力。

为预算责任制设计的定价模式

公共部门 IT 预算依赖可预测性。多年期合同、预算周期和拨款流程无法适应由不透明定价机制导致的意外账单。

许多商业可观测性厂商采用的定价模式,会随着现代基础设施增长而不可预测地增加成本。按主机收费的费用模式通常会叠加自定义指标费用和容器超额费用,导致 Kubernetes 环境扩展或 OpenTelemetry instrumentation 增强时账单不断上涨。成本难以预测,因为它们与基数(cardinality)相关,而基数正是复杂环境中可观测性价值的重要来源。

Elastic 的模式完全不同:你根据数据量付费,而不是根据拥有多少主机,或者系统 instrumentation 的粒度付费。在 Elastic Observability Serverless 中,采用时间序列数据流(TSDS)索引模式存储的指标,其采集和保留价格均为标准 Observability 每 GB 费率的25%,即在批量价格层级下,大约为每采集 GB 0.023,以及每月保留GB 0.023,以及每月保留GB0.023,以及每月保留 GB 0.023,以及每月保留GB 0.005。没有按主机授权费用,没有基数相关附加费用,也没有通过自定义指标分类来惩罚更丰富 instrumentation 的收费方式 ,最终成本达到 Datadog 和其他厂商的一半。

长期数据保留也具有明显的成本优势;按照每月约 $0.005/GB 的价格,保留一年甚至更长时间的完整精度指标数据在经济上是可行的,可以支持公共项目通常需要的回溯审计需求。

关于定价和部署模式的说明:

公共部门客户通常对数据存储位置有不可妥协的限制。对于美国组织,Elastic 已在 AWS GovCloud(US)上获得 FedRAMP Moderate 和 High 级别授权。对于运行 Elastic Cloud Hosted 或 自管理 部署的组织,包括在机密环境或高合规环境中常见的隔离网络(air-gapped)环境,目前 TSDS 指标无需额外付费。在这两种情况下,列式存储引擎都意味着指标运行所需的基础设施更少,无论采用哪种部署模式,都能够实现成本效率。

成本节省背后的工程技术

Elastic 新指标能力带来的性能提升,体现了 Elasticsearch 存储和查询时间序列数据方式的一次根本性重新设计。

Elastic 围绕专门为 TSDS 工作负载打造的列式存储引擎,重新构建了指标功能。结果非常显著:

  • 对于 OpenTelemetry 指标,现在每个数据点仅占用 3.75 字节,而一年前为 25 字节 ------ 存储占用降低了 6.6 倍,并且存储效率最高可比 Prometheus 提升 2.5 倍。

  • 时间序列查询速度相比早期 TSDS 版本最高提升 160 倍,相比 Prometheus 最高提升 30 倍,同时索引吞吐量提升最高达 50%。

对于公共部门 IT 团队而言,这些影响非常直接:存储效率提升意味着可以在不牺牲速度或性能的情况下,以过去成本的一小部分保留数月甚至数年的完整精度指标数据,从而支持覆盖重要时间范围的趋势分析、容量规划和审计记录。同时,添加新的 Kubernetes 标签、云标签或应用维度只会增加数据量,而不会触发定价层级变化或带来架构压力。

原生 Prometheus 支持:保护你已经构建的成果

公共部门基础设施通常以缓慢且谨慎的方式演进。采购周期较长,系统集成程度较深,并且面向公众服务的系统存在较高的运营中断风险。任何平台迁移都必须保护已有建设成果。

大多数运行现代云和容器化基础设施的 SRE 团队,都已经在基于 Prometheus 的工具体系上投入了大量资源:scrape 配置、告警规则、PromQL 查询以及 Grafana 仪表板,这些都代表了多年的运营经验积累。过去,迁移指标后端通常意味着需要重写所有这些内容。

Elastic 消除了大部分迁移阻力。Prometheus 指标通过 Prometheus Remote Write 接入,并进入同一个列式存储中,同时保持语义不变。PromQL 可以原生运行在 Kibana 中,因此现有查询、仪表板和告警规则无需修改即可直接迁移。对于希望继续使用 Grafana 作为可视化层的组织,Elasticsearch 提供了原生兼容 Prometheus 的 API,任何兼容的前端都可以直接查询,这意味着团队可以替换后端,同时保留工程师已经熟悉的界面。

简化的迁移流程

迁移过程可以采用渐进式方式,并且大部分可以自动化完成。Observability Migration Platform 是一个基于 CLI 驱动的工作流,可以将支持的 Grafana 和 Datadog 资源转换为 Kibana 原生输出,并生成用于审核结果的证据材料,将迁移过程从人工重建转变为转换与验证流程。

它可以基于导出的资源或实时 API 工作,覆盖来自 Datadog 和 Grafana 两种路径的仪表板和告警内容。对于公共部门团队而言,尤其重要的是,该工作流还会生成面向审核人员的证据材料,例如迁移报告、清单、验证数据包和发布计划,使团队能够清楚了解哪些内容已经成功转换,哪些内容被降级或标记为需要人工审核,以及哪些部分仍需要人工判断。

Elastic 被认可为可观测性领域领导者

Elastic Observability 在市场中的认可度持续提升。2026 年 7 月,Elastic 连续第三年被评为 2026 Gartner® Observability Platforms 魔力象限(Magic Quadrant™)领导者。

我们认为,这一认可体现了 Elastic 对于紧跟市场变化的持续投入,同时为客户提供通过 Prometheus 和 OTel 标准化带来的效率提升,以及使用单一平台统一处理日志、指标和 traces 的能力。

在我们看来,可观测性市场已经不同于我们首次获得这一认可时的市场环境。AI 以难以预料的方式加速了遥测数据量的增长,给存储成本以及负责管理这些数据的团队预算带来了压力。对于 AI 辅助调查的期望,也已经从简单的对话式交互发展为面向实际运营的 agentic 能力。同时,生态系统也持续演进,OpenTelemetry (OTel) 和 Prometheus 已经成为任何严肃平台都需要原生支持的标准,而无需承担 schema 转换带来的额外成本。

我们认为,这一认可体现了我们对这些变化的响应。以下是我们认为帮助我们达到这一目标的关键因素。

日志、指标和 traces 的高成本效率

由于 AI 推动遥测数据量快速增长,整个行业的成本都在上升。标准应对方式通常是减少存储数据:缩短保留周期、更积极地采样、降低某些数据类型的优先级。但这种方法会产生累积影响。每丢弃一条遥测数据,就意味着失去一部分上下文,而上下文正是 AI 驱动调查所依赖的核心。

Elastic 采用了不同的方法。Elasticsearch 存储日志和 traces 的效率最高可比标准索引提升 4 倍,存储指标的效率最高可比 Prometheus 提升 2.5 倍。它通过一个统一接口运行两个专门设计的引擎:一个针对日志和 traces 优化的全文搜索引擎,以及一个针对指标优化的完整列式引擎。每个引擎都根据其处理的数据特点进行设计,这正是效率提升的来源。

两个引擎共享相同的查询语言、API 和仪表板,因此团队可以通过单一界面处理三种信号类型,无需维护独立后端,也无需在不同工具之间切换上下文。在低效平台上只存储一部分数据的成本,高于在 Elastic 上存储全部数据的成本。

你的日志中包含答案。Elastic 能找到它。

日志是可观测性中最丰富的信号,但由于其非结构化特性以及完整保留成本较高,通常没有被充分利用。大多数团队只能根据存储预算保留部分日志,并且通常只有在故障发生时,才由专家被动地进行日志搜索。

Elastic Streams 会自动从原始日志中提取结构、含义和运营上下文,将原本依赖专家、被动使用的信号转变为主动可用的信息。它利用 AI 自动发现 Knowledge Indicators(KIs),无需工程师提前知道应该搜索什么;它会从非结构化数据中提取实体和依赖关系,使相关上下文在告警触发时已经准备就绪。

基于完整上下文的 AI 驱动调查

Elastic 提供基于最丰富上下文构建的 AI agents 和 机器学习(ML)能力,用于调查和根因分析(RCA)。由于遥测数据可以高效存储,无需丢弃任何信息,同时日志数据经过充分结构化,可以直接用于分析,因此 AI 能够基于完整上下文开展工作。

这一切的基础是检索层。Elasticsearch 通过语义方式检索相关日志、指标和 traces,而不仅仅依赖关键词匹配。检索质量决定了 AI 能否找到正确上下文,而不是仅仅找到近似内容。这也是 上下文工程 变得关键的原因:Elastic 在数据采集阶段就对遥测数据进行结构化和增强,标记实体、提取依赖关系并构建服务地图,使数据在告警触发之前就已经准备好供 AI 使用。

对于需要构建自定义调查工作流的团队,Elastic Agent Builder 和 Workflows 提供了构建自定义 AI agents 的基础能力。Elastic 还提供了开放的 Agent Skills 仓库,可以查询 Elasticsearch、执行 ES|QL,并基于结果进行推理。预配置的异常检测和日志分类能力,多年来一直是该平台的核心组成部分。所有这些能力都支持基于 agent 的调查和修复。

基于开放标准面向未来

选择封闭技术栈意味着每当生态系统变化时,都需要进行迁移工作。每一次 instrumentation 变化都会带来工程成本,包括新的数据处理流程、schema 转换以及数据协调。在可观测性领域,OTel 正逐渐成为主流 instrumentation 标准,而 Prometheus 通常是指标领域的默认选择。

Elasticsearch 从设计之初就是开放的,具备 schema 中立性,并且从底层构建于 OTel 之上。使用 Elasticsearch,团队可以从任何来源接收任何数据,无论是 Prometheus、OTel 还是其他格式,均可原生存储并直接查询。数据保持原始格式,不需要转换层,也不会在转换过程中丢失信息。

这一认可对我们的意义

我们认为,连续第三年被评为 Gartner Magic Quadrant 领导者,体现了客户向我们传达的信息:可观测性不应该迫使团队做取舍。团队应该能够高效存储所有遥测数据,基于开放标准而不是封闭标准进行构建,并确保 AI 调查拥有所需的完整上下文。

这里讨论的四个方面彼此关联:效率使完整上下文成为可能,完整上下文使 AI 调查更加可靠,而开放标准确保行业发展变化时,已有投入不会被浪费。我们认为,这一认可体现了我们在这四个领域持续取得的进展。

阅读完整报告

2026 Gartner® Observability Platforms 魔力象限™ 和 2026 Gartner® Observability Platforms 关键能力报告 现已发布。

访问这些报告,了解更多关于可观测性市场的信息,以及为什么我们认为 Elastic 被评为领导者。

探索 Elastic Observability 如何帮助组织更快调查问题、监控 AI 驱动应用、采用开放标准,并有信心地大规模运营。

Gartner,Observability Platforms 魔力象限,

Padraig Byrne、Martin Caren、D.B. Cummings、Neil Young,2026 年 7 月 13 日。

Gartner,Observability Platforms 关键能力,

Martin Caren、Padraig Byrne、D.B. Cummings、Neil Young,2026 年 7 月 13 日。

GARTNER 是 Gartner, Inc. 和/或其关联公司在美国及国际范围内的注册商标和服务标志,MAGIC QUADRANT 是 Gartner, Inc. 和/或其关联公司的注册商标,并经许可使用。保留所有权利。

Gartner 不认可其研究出版物中描述的任何厂商、产品或服务,也不建议技术用户仅选择评分最高或获得其他指定称号的厂商。Gartner 研究出版物代表 Gartner 研究机构的观点,不应被理解为事实陈述。对于此研究,Gartner 不提供任何明示或暗示的保证,包括任何关于适销性或特定用途适用性的保证。

本文中描述的任何功能或功能发布时间均由 Elastic 自行决定。当前尚未提供的任何功能或功能可能不会按计划交付,或者可能完全不会交付。

该图表由 Gartner, Inc. 作为更大研究文档的一部分发布,应结合完整文档进行评估。Gartner 文档可向 Elastic 索取。

---

本文中描述的任何功能或功能发布时间均由 Elastic 自行决定。当前尚未提供的任何功能或功能可能不会按计划交付,或者可能完全不会交付。

本文可能使用或提及了第三方生成式 AI 工具,这些工具由各自所有者拥有并运营。Elastic 无法控制这些第三方工具,也不对其内容、运行或使用承担任何责任,对于因使用这些工具而产生的任何损失或损害亦不承担责任。使用 AI 工具处理个人信息、敏感信息或机密信息时,请务必谨慎。你提交的任何数据都可能被用于 AI 训练或其他用途。Elastic 不保证你提供的信息能够保持安全或保密。在使用任何生成式 AI 工具之前,你应了解其隐私实践和使用条款。

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

原文:Elastic named a Leader in the 2026 Gartner® Magic Quadrant™ for Observability Platforms | Elastic Blog

相关推荐
xbgRS1 小时前
Elasticsearch的查询
elasticsearch
Elasticsearch5 小时前
使用 Lucene 搜索你的 Bean —— Highlighting
elasticsearch
Elasticsearch5 小时前
使用 Lucene 搜索你的 Bean —— Elasticsearch
elasticsearch
Elasticsearch10 小时前
最好的 LLM 只有 59% 的时间能写出正确的 Elasticsearch ES|QL。以下是另外 41% 出错的原因
elasticsearch
垚垚学技术_聚焦云原生10 小时前
Ansible Role 生产环境标准目录结构与规范化实践
java·elasticsearch·ansible
小林ixn10 小时前
从 MySQL 的 LIKE 到 ES 倒排索引:一次把全文检索和混合检索讲透
sql·elasticsearch·全文检索·agent·关键词
MayBaymax11 小时前
ES 基础总结
大数据·elasticsearch·搜索引擎
Elastic 中国社区官方博客11 小时前
两个依赖和一个配置块:通过 Prometheus 远程写入将 Spring Boot 指标发送到 Elasticsearch
大数据·数据库·spring boot·elasticsearch·搜索引擎·全文检索·prometheus
SelectDB技术团队12 小时前
ELK 太占磁盘、ES 总报写入拒绝:从归因到可执行的优化清单
大数据·clickhouse·elk·elasticsearch·全文检索·复杂查询·实时更新
frjc21 小时前
数据库选型:如何从众多数据库中选出最理想的那一个
redis·mysql·clickhouse·elasticsearch