摘要
- New Relic 提供了一条从代理和 OpenTelemetry 数据到 NRDB、NRQL 告警条件、异常模型、关联和通知工作流的连贯路径。这可以代替手动观察仪表盘并缩短调查时间，但只有被正确收集、命名、保留和查询的信号才能被检测到。
- 平台自身的文档指出了一些使日常运维复杂化的条件：已接受的遥测请求仍可能在后续验证中失败，采样追踪可能丢失 span，稀疏或延迟的数据可能被错误评估，编辑条件会重置其评估和异常历史，以及静默或路由选择可能会抑制运维人员预期的告警。
- 供应商案例研究报告了告警量和解决时间的大幅减少，而 New Relic 的 2026 年分析将启用 AI 的账户与较低的噪音和更快的问题关闭联系起来。这些是生产环境使用的可靠迹象，但不是对新客户将获得的收益的受控估计；仪表化质量、团队成熟度和对高级功能的自选仍然是混杂因素。
- 一个健全的采购案例使用每个可操作告警的成本：平台和遥测费用、仪表化、查询治理、调优、分类、事件回顾和迁移成本，除以那些识别出真实状况、及时送达正确负责人并支持有用行动的告警。那些被遗漏的、影响客户但未生成任何告警的故障，仍然作为故障计入分母。
告警是链条的末端，而非起点
最简单的 New Relic 演示从一个图表开始。一个应用程序代理报告响应时间和错误；一条线上升；一个 NRQL 条件超过阈值；Slack 或 PagerDuty 收到一条消息。很容易将这一序列描述为自动化检测。更难描述的是，为了让这个消息值得采取行动，必须保持哪些条件为真。
应用程序必须发出故障的证据。代理或收集器必须保留有用的字段并将其传送出去。服务名称和其他属性必须标识正确的生产组件。NRDB 必须保留并公开查询所期望的记录。查询必须反映用户受损，而不仅仅是内部的异常状态。其聚合窗口以及对延迟或缺失数据的处理必须与数据源相匹配。一个静态阈值或学习到的基线必须能够区分正常波动和麻烦。关联必须将症状分组，同时不合并不相关的故障。工作流必须与产生的问题匹配，并且目标凭据和值班归属必须是最新的。最后，工程师需要足够的上下文和权限才能采取行动。
New Relic 在几乎每个阶段都提供了重要的机制。但它并不在每个阶段都掌握真理。客户代码、云集成、OpenTelemetry 组件、网络传输、第三方事件工具以及人工服务知识仍然是生产系统的一部分。上游遗漏的信号无法被下游更好的告警模型所弥补。一个正确检测到的阈值无法修复过时的路由标签。一个说服力强的问题摘要无法使一个无人认领的服务变得可操作。
这就是为什么有用的分母不是创建的告警事件，而是可操作的告警：即那些对应于需要关注的真实状况、足够早地到达以改善结果、送达适当的负责人、包含足够证据以开始诊断、并导致合理行动的通知。这个定义特意设得很高。它只在自动化改变了工作时才给予自动化肯定。
它也暴露了两种不同的错误。一个误报或低价值的告警消耗了注意力而没有改善服务。一个漏报的告警让损害持续，直到用户、另一个监控系统或工程师注意到它。调整灵敏度通常是用一种错误换取另一种错误。增加持续时间或延迟可以抑制瞬态噪音，但延长了检测时间。收紧异常带可以暴露更小的偏差，但增加了告警。没有一种通用设置可以解决这种权衡，因为漏掉支付故障的成本与短暂的批处理作业减速的成本是不同的。
New Relic 拥有平台，而非客户的服务模型
New Relic 是一家老牌的可观测性公司，而非一个新的告警封装器。其作为上市公司的最后一份年报描述了一个结合了指标、事件、日志和追踪与分析工具的平台，报告了 2023 财年 9.256 亿美元的收入，并称其服务超过 16,000 家付费客户。该文件还将 Datadog 和 Dynatrace 列为直接的一体化可观测性竞争对手，并承认大型组织可以构建自己的类似能力。2023 年 11 月，Francisco Partners 和 TPG 完成了 65 亿美元的收购，此后 New Relic 的股票停止公开交易。
产品边界很广但依然可定义。New Relic 运营着托管的数据和分析平台、NRDB、NRQL、自有的代理、告警、仪表盘、事件智能和通知配置。它接受通过供应商中立的 OpenTelemetry 生态系统以及其他集成产生的遥测数据。OpenTelemetry 本身是 CNCF 的一个项目，拥有 API、SDK、语义约定、OTLP 协议和 Collector；它并非 New Relic 的产品。PagerDuty、Slack、ServiceNow、Jira、云服务以及客户的运维手册同样是独立的系统，即使 New Relic 向其发送数据时也是如此。
这种区别在归因成功和失败时非常重要。如果 New Relic 代理自动仪表化一个受支持的框架，并暴露了团队以前无法看到的错误，那么代理和平台确实值得称赞。如果一个 OpenTelemetry Collector 因为队列容量不足而丢弃数据，那么检测失败不能仅归咎于 NRDB。如果 New Relic 创建了一个问题，但过期的 webhook 密钥导致无法传递，那么托管的告警计算是有效的，而运行结果却是失败的。采购仍应关注最终结果，因为客户购买的是端到端的能力，但工程团队应准确定位出故障的层次。
法律和商业边界也很重要。New Relic 针对符合条件的 Pro 和 Enterprise 订单的服务水平承诺，定义了以能够登录并查看客户数据为目标的可用性，力求在商业上合理的努力基础上达到 99.8% 的月度可用性，并排除了客户技术、第三方服务和公共互联网传输等原因。标准版以及一些基于用量的协议不享受相同的承诺。这比“每个重要的告警都会正确地按时到达”的承诺要窄。购买方需要阅读自己的实际订单、支持计划和外部通知协议，而不是从平台可用性推断告警结果的保证。
仪表化决定可以知道什么
New Relic 可以从其语言和基础设施代理、浏览器和移动端组件、云集成、API、Prometheus 和 OpenTelemetry 摄取遥测数据。这种广度很有价值，因为许多事件跨越不同层次。当上升的 HTTP 错误率可以关联到一次部署、一个数据库等待、一个饱和的主机或一个失败的依赖时，它就更有用。同样的广度也带来了治理工作：更多的数据源产生更多的属性、更多的命名约定、更多的成本，以及两个看似可比的信号却可能意味着不同事情的更多可能性。
OpenTelemetry 减少了专有仪表化的锁定，但并未消除仪表化设计。New Relic 的OpenTelemetry 资源指南解释说，资源属性用于合成实体，其中service.name对于服务是必需的，而诸如service.instance.id等字段则建议用于区分实例。一个缺失或不稳定的服务名称会改变界面中显示的内容以及告警所依据的维度。一个在某个部署中不存在的环境标签，可能会将生产数据路由到一个原本用于预发布环境的查询中，或者使其同时脱离两者。
即使一个成功的传输响应也不能证明可用的数据已到达。New Relic 的OTLP 端点文档指出，有效负载必须保持在 1 MB 以下，导出器应适当分批，启用压缩并重试瞬态故障，同时考虑速率限制。更微妙的是，端点在检查认证、有效负载大小和速率限制后作出响应，而内容验证则是异步进行的。因此，一个成功状态码可能先于稍后记录为NrIntegrationError的摄取失败出现。只检查 HTTP 成功状态的操作员验证的是送达前门，而非可查询的遥测数据。
New Relic 代理引入了它们自己的选择。事件上限和采样旨在控制应用和平台开销。事件采样文档警告说，采样的事件数据可能与未采样的指标不一致，并且更长的断连时间会导致从本地存储的数据中进行更多采样。分布式追踪在常见配置中使用自适应采样；缺失追踪指南列出了缺少导出器、采样、span 限制、延迟 span、时钟偏差和跨账户权限等导致追踪不完整的原因。
这并不使基于采样的可观测性不可信。采样通常是控制开销和花费的合理方式。但这确实意味着查询设计者必须清楚哪些证据是完整的，哪些是估计的，哪些是被选中采样的。一个构建在适当聚合指标上的错误率告警，即使个别追踪缺失，也可能是可靠的。而一个假定每个失败事务都有完整追踪的取证查询则不可能。平台的底层能力是存储和评估提供的数据；产品可靠性包括它如何清晰地暴露收集故障；部署可靠性取决于客户是否监控这些故障并围绕它们进行设计。
仪表化也是会变化的软件。代理发布添加框架支持、更改默认值并修复缺陷。OpenTelemetry 的语义约定会演进。New Relic 指出，从原生仪表化切换到 OpenTelemetry API 可能会为诸如 Elasticsearch 和 RabbitMQ 等系统产生不同的 span 或指标名称，这可能破坏依赖精确名称的仪表盘和告警。因此，升级计划需要遥测契约测试：部署一个已知的事务、错误和依赖调用；验证期望的属性和实体关联；并在推广新的代理或收集器配置之前比较告警查询。
持续的工作不仅仅是安装一个代理。必须有人维护版本、检查导出器和代理的错误、控制敏感字段、维护命名规则、识别未仪表化的服务、决定采样策略，并在变更后测试遥测数据。自动仪表化可以使第一周快速启动。但它不能让接下来的三年无人负责。
NRQL 将运维判断转化为可执行的条件
NRQL 是 New Relic 最强大的特性之一，因为它允许团队在统一的数据存储上表达检测逻辑。一个条件可以监控错误百分比、延迟百分位数、队列深度、业务事件计数或者从遥测数据中得出的几乎任何数值结果。分面（Faceting）可以将一个条件应用于许多服务、主机或租户。这比一组固定的基础设施告警更灵活，并可以将技术行为与业务事务联系起来。
灵活性将责任转移到了查询设计上。平均值可能掩盖一小部分严重受影响的用户。百分位数在低流量时可能不稳定。计数可能因为需求消失而不是因为服务改进而下降。如果分母包含健康检查，用所有事务去除错误可能会低估故障。按短暂的 Pod 标识符分面，当真正的运维单元是部署时，可能会产生一连串短暂存在的信号。从仪表盘复制过来的过滤器可能遗漏了最近重命名的环境。
NRQL 告警也不仅仅是一个每分钟运行一次的图表。New Relic 的流式告警文档描述了三种聚合方法。事件流（Event flow）是默认方法，适用于频繁且基本有序的数据。事件计时器（Event timer）适用于不规则或批量到达的数据。节奏（Cadence）使用 New Relic 的挂钟时间，被公司描述为较旧、较差的选择。数据经过过滤，收集到一个聚合窗口内，允许一个额外的延迟或计时器，折叠为一个值，然后在阈值持续时间内进行测试。
每个设置都会改变检测器。更长的窗口可以平滑尖峰，但可能隐藏短暂的严重故障。更长的延迟给延迟的遥测数据到达的时间，但延长了发出告警前的间隔。事件计时器可以等待批量数据中的平静期，而事件流则需要后来的时间戳才能关闭更早的窗口。如果计时器针对不一致的数据设置得太短，New Relic 警告说窗口可能会在所有数据点到达之前就被评估，从而产生不正确的通知。
空窗口需要另一个决策。将缺口留空可以重置阈值持续时间计时器。用零填充可能会让缺失的数据对一个查询表现为健康，而对另一个查询表现为灾难。传递上一个值可以保留过时的故障或过时的成功。信号丢失检测有所帮助，但它仅在信号存在之后才激活；当一个数据源已经缺失时，一个刚启用的条件无法回溯式地发现这种缺失。在分面条件下，每个分面都是自己的信号，这在短暂实体作为正常扩缩容的一部分而终止之前是非常强大的。
查询语言有明确的边界。LIMIT与 NRQL 告警不兼容，因为需要评估完整的结果集。子查询和子查询连接与流式告警不兼容，因为它们需要多次数据传递。账户和条件限制也很重要：当前文档列出每个账户 4,000 个告警条件，每个 NRQL 条件 20,000 个分面，每分钟 3 亿个匹配数据点以及每分钟 25 亿次查询扫描操作。滑动窗口可能会大幅增加匹配的数据点，并且在某些计算计划上会增加消费费用。
对于许多组织来说，这些是慷慨的上限，但设计上的影响比硬限制来得更早。一个跨数千个易变维度的分面条件，比一个有意限定范围的服务级别告警更难负责、测试和路由。因此，查询治理不应该只问 NRQL 是否接受该表达式，还应问它代表哪个人群，其分母行为如何，零流量时会发生什么，它创建了多少个不同的信号，以及每个信号由哪个团队负责。
异常检测学习历史并继承其模糊性
静态阈值容易解释但难以泛化。一个五秒钟的延迟阈值对于结账可能是无法容忍的，但对于一个通宵报告来说却是正常的。中午的流量与午夜的流量不同。New Relic 的异常条件通过从先前行为预测下一个值并在观察值远离预测值足够远时打开告警来解决这个问题。灵敏度通过距离预测值的距离来表示，而方向和持续时间则控制哪些偏差算数。
异常检测文档做了适当的限制。新信号历史短且预测不稳定。一致的信号产生更窄的带；不规则的信号产生更宽的带。系统可以自动推断季节性，也可以按小时、日、周或无季节性使用。不支持每月和每年的模式。因此，一个每周的销售周期可能被建模，而年度续费高峰或月末批处理则需要另外设计。
异常并不等同于有害的故障。一次成功的促销活动可能产生异常的流量激增。一个使低效端点普遍变慢的部署，如果持续下去，可能会成为新的常态。一个低流量的安全或支付错误，即使每次发生都很重要，也可能留在一个宽泛的带内。相反，如果季节性设置错误，一个预料之中的批处理也可能发出告警。模型检测与学习到的行为的偏差；客户决定学习到的行为是否可以接受，以及偏差是否需要干预。
条件维护创造了一个特别重要的可靠性边界。New Relic 声明，更改查询、聚合方法、窗口、延迟、缺口填充、异常方向、阈值或滑动间隔会重置 NRQL 条件评估。对于基于持续时间的阈值，这至少会创建一个在新事件可以打开之前经过所配置的等待期的时段。对于异常条件，所有异常学习都将丢失并重新开始。因此，在风险发布前一个出于好意的编辑，恰恰可能在需要信心的时刻创造了一个盲目或不稳定的时期。
这使得告警配置成为一项需要变更管理的资产。编辑应记录原因、先前的值、预期效果和负责人。团队应预览历史信号，在可能的情况下在非关键时期应用更改，并在条件变为活动状态后运行已知故障演练。对于异常告警，负责人应将重新学习期视为信心降低的时期，在风险需要时将其与静态或合成的防护措施配对，并避免重复进行会重置模型的外观编辑。
New Relic 增加了异常值检测，它将实体与同类进行比较，而不是将一个信号与其过去进行比较。这可以从一个原本健康的组中发现单个过载的服务器。其异常值检测指南也给出了有价值的警告：报告较早时间戳的实体可能完全被排除在比较之外。推荐的补救措施，即按报告行为拆分条件或延长窗口，再一次在覆盖率与延迟和维护之间做了权衡。更复杂的检测并不能消除理解时间的必要性。
缺失的遥测数据可能看起来健康、损坏或仅仅是延迟
遥测数据的丢失是监控中最危险的模糊情况之一。没有错误事件可能意味着没有发生故障，没有请求到达，进程停止了报告，过滤器排除了记录，或者传输失败了。正确的响应取决于发生了哪种缺失。
New Relic 为此提供了几种工具。信号丢失条件可以在计时器到期后打开或关闭告警事件。缺口填充可以插入一个静态值或上一个已知值。NrIntegrationError记录可以揭示格式错误的数据、限制和配置失败。账户限制界面报告一些摄取和查询事件。这些控件允许团队监控可观测性本身，但它们需要单独的条件和独立的路由。一个关于缺失告警的告警，如果使用相同的失败遥测路径，并不能提供完整的保障。
基数问题使问题复杂化。一个指标时间序列由其名称和唯一的属性组合定义。添加客户、请求、容器或不受限制的标识符值，可能会使序列数量急剧增加。New Relic 目前描述每个账户每天有 1500 万个基数预算，每个指标默认有 10 万个基数预算，并带有付费扩展和裁剪控制。当达到限制时，行为因限制而异；数据限制文档指出，某些请求速率超额会收到 429 响应，而达到指标基数限制则可能在 UTC 日的剩余时间内关闭聚合数据，即使原始数据可能仍被存储。
基数并不仅仅是一个成本话题。它改变了告警数量和查询性能。在一个高变动字段上的分面告警可能会创建数千个短暂的信号，增加告警评估工作并使路由变得毫无意义。裁剪该字段可以控制支出，但会移除隔离单个租户所需的维度。正确的单元通常是一个运维上负责的服务、区域、工作负载或客户层级，而不是最容易附加的任何标识符。
该平台 2026 年的状态历史展示了为什么这一层必须被测量而不是假设。New Relic 的公开事件信息流记录了涉及延迟或缺失的告警通知、误报、错误的信号丢失通知以及遥测数据异常的事件。例如，在2026 年 3 月 20 日，该公司表示一些使用 Azure 集成的美国区域客户可能收到了错误、延迟或缺失的通知，并且受影响的数据可能无法恢复。在5 月 18 日，它报告称第三方云提供商的中断导致了数据延迟，以及对一些美国和欧盟客户的延迟、缺失或错误通知。在1 月 21 日，它记录了超过四个小时的时间段，期间一部分美国客户可能会遇到实时通知延迟或缺失的情况。
这些披露是特定事件的证据，而不是一个经过测量的故障率。该信息流没有披露受影响的账户数量、所有降级状况或成功评估的分母。它也展示了 New Relic 检测、沟通和解决服务问题的能力。正确的运维结论更为狭窄：可观测性提供商本身就是一个分布式的云依赖，具有严重风险的客户需要对其收集和通知路径进行外部检查。
这种外部检查可以是一个独立路由的轻量级合成监控，针对最关键的资源的云原生告警，在 New Relic 之外观察到的摄取心跳，或者来自另一个提供商的用户旅程信号。复制每个告警会重现噪音和成本。保护少量关键路径可以创建一个有用的控制，而无需重建整个平台。
关联减少扇出但无法证明共同原因
一个大型事件可能会为每个主机、服务、区域和症状创建一个告警。分别呼叫每个事件会将技术故障转变为注意力故障。New Relic 的事件智能将告警事件分组为问题，并可以应用内置的、建议的或客户定义的关联决策，这些决策基于时间、属性、文本相似性和实体关系。它可以在激活前针对近期数据模拟一个建议的决策。
这解决了一个真实的需求。Google 的 SRE 指南建议，噪音告警应接近与事件一对一的关系，并警告说反复的低优先级呼叫可能会使严重告警获得的关注减少。一项针对超过四百万次华为云告警的为期两年的行业研究同样发现了描述不清、误导性的严重级别、过时的策略、反复切换以及集体风暴等问题；其工程师在服务或告警策略变更后仍不得不重新配置屏蔽、聚合和关联。
New Relic 的关联机制可以在平台规模上执行这种聚合。其文档记录的决策包括对来自同一 Kubernetes 部署、应用程序或合成监控的事件进行分组，以及基于相似性的规则和拓扑关系。长达 20 分钟的缓期给系统时间收集和关联活动，然后再进行通知。好处是减少了碎片化的工作项，并在一个问题页面上提供更多上下文。
权衡是时间和可能的过度分组。两个在时间和拓扑上接近的告警可能共享一次部署，也可能代表独立的故障。相似的标题可能是由通用模板生成的，而非共同的原因。更长的缓期给关联提供了更多证据，同时推迟了第一次告警。一个足够宽泛以抑制风暴的规则，可能会将第二个问题合并到一个问题中，而该问题的负责人已经在追踪错误的假设。
因此，应在问题层面评估该产品的精确率和召回率，而不仅仅是关联率。精确率询问分组的事件中有多少真正属于同一个运维问题。召回率询问一个问题的多少个事件被成功分组。仅靠积极分组就可以制造出高关联率。客户的结果是分组是否能减少重复工作，而不隐藏不同的行动或负责人。
建议的决策和模拟有所帮助，但它们使用的是过去的数据。新的架构、重命名和罕见的复合事件仍然处于那段历史之外。事后回顾应检查被分组的事件和被排除在外的事件。决策需要负责人和到期审查，就像阈值一样。
路由是检测可靠性的一部分
一旦一个条件打开了一个告警事件，并且关联形成了一个问题，New Relic 的工作流就会过滤问题事件，并将选定的触发器发送到目的地。它们可以用 NRQL 结果丰富通知，并指定电子邮件、Slack、PagerDuty、ServiceNow、Jira、webhook 或其他集成为目标。标签可以将服务指向其团队。针对激活、确认、调查、关闭、优先级变更和后续更新，通知触发器可以有所不同。
这非常强大，因为没有归属的检测仅仅是一条记录。这也是另一个配置面。工作流过滤器在策略或标签更改后可能不再匹配。目标凭据可能会过期。电子邮件收件人可能未验证地址。Webhook 有效负载可能会改变。丰富查询可能返回空数据。New Relic 的工作流测试使用现有的匹配问题，因此一个没有相关历史记录的配置可以显示它没有找到匹配，而无法证明未来的路由是否能正常工作。
静默规则为维护和已知中断添加了必要的控制。它们应用于告警生命周期的末端附近：评估继续进行，告警事件仍然存在，但通知可以被抑制。静默文档区分了当静默结束后仍有活动问题存在时进行通知和抑制该后续通知的情况。因此，一个设置了错误时区、过滤器或结束行为的定期静默，可能会造成在配置上看似有意、但在操作中却有害的沉寂。
团队应测试路由，而不仅仅是条件。在安全环境中触发一个合成故障应验证条件打开、问题分组、工作流匹配、目的地送达、值班确认和关闭。关键路由需要定期检查，因为近期没有告警并不能证明路径是健康的。检查应记录端到端的时间，而不仅仅是 New Relic 的评估时间戳。该公司的文档指出，由于数据处理的原因，显示的告警事件时间和初始通知时间可能相差最多三分钟，这还不包括客户配置的窗口、延迟、缓期和外部送达时间。
客户结果令人鼓舞但有选择性
New Relic 发布了详细的、署名的团队减少告警负担的案例。PicPay 的客户案例显示，在设定告警标准和集中化日志后，事件量减少了 65%，平均解决时间缩短了 30%，每年停机时间减少了 51%。Viewpoint表示，其每周告警噪音从超过 3,500 次减少到不到 600 次，相比之前的监控解决方案节省了 57% 的成本。The Access Group报告称告警噪音减少了 99%，大约每天只有 9 次告警，并描述在经过调优和整合后，调查大约需要十分钟。
这些案例很重要。它们明确了客户、工作负载、前后对比数据和实践者。它们表明 New Relic 可以嵌入到重要的生产运维中，并且告警合理化可以产生巨大的收益。它们也表明，结果并非由异常模型一键实现。PicPay 设定了平台告警标准并集中化了日志。Viewpoint 对 Kubernetes 应用进行了仪表化，并扩大了跨职能的访问权限。The Access Group 精细调整了告警，使用了静默功能，并添加了业务仪表化。组织工作是结果的一部分。
这些证据是由供应商选择的，缺乏重要的分母。这些页面没有提供合同价格、工程实施小时数、匹配的对照组、置信区间、遗漏的事件、假阴性计数，或者由 New Relic 而非整合和流程重新设计所带来的改进比例。“告警噪音”也可能由每个客户不同地定义。从 3,500 条通知减少到 600 条可能很出色，但如果不知道客户发现的故障是否也减少了，则信息是不完整的。
New Relic 的2026 年 AI 影响报告提供了一个更宽广的观察视角。它指出该分析涵盖了 2025 年期间约 660 万名活跃用户的聚合、去标识化的使用数据。启用 AI 的账户的噪音告警大约占 46%，而未启用的账户为 63%，问题关联率大约是后者的两倍，平均关闭时间也低大约 25%。在 5 月，报告的平均值分别为 26.75 分钟和 50.23 分钟。
这一规模使这种关联变得有趣，但不是因果关系。该报告将生成式、机器学习和确定性功能归入“New Relic AI”之下。它没有公布随机分配、每个队列的账户数量、匹配方法、服务复杂性、团队成熟度、严重性组合、关闭惯例或假阴性结果。启用高级功能的团队可能也在仪表化和事件实践上投入了更多。平均关闭时间不一定是恢复时间；一个问题可以自动、手动或根据政策关闭，而无需证明用户已经恢复。
正确的解读是，集成的关联和辅助工具可能是降低运维投入的可信贡献因素，并且 New Relic 在其自身平台上看到了持久的关联。买家不应将 25% 放入投资回报模型作为保证的节省。它应在本地测量相同的阶段：信号开始、事件打开、通知送达、确认、调查开始、缓解、服务恢复和问题关闭。只有这样才能确定 New Relic 缩短了哪些时间。
可操作告警的成本揭示了工作转移到了哪里
New Relic 的商业模型使遥测数据量和用户访问可见。当前公开的列表条款包括每月 100 GB 的免费摄取，然后按每 GB 0.40 美元列出原始数据，每 GB 0.60 美元列出 Data Plus，以及用户和高级计算费用。公开定价会发生变化，企业承诺也各不相同，因此这些数字是参考点而非报价。Data Plus 还改变了保留策略和查询限制，这意味着成本与调查可以检查多少历史数据有关。
直接发票只是告警经济的一部分。一个有用的月度等式是：
可操作告警成本 = (平台 + 摄取 + 保留 + 计算 + 仪表化 + 收集操作 + 查询治理 + 告警调优 + 路由维护 + 分类 + 事件回顾 + 培训 + 迁移摊销) / 可操作告警数
这个分母必须只包括那些满足运维验收规则的告警。一条发到错误团队的告警，对于那条路由来说是不可操作的。一个在用户已经报告中断后才到达的正确告警并没有改善检测，尽管它可能仍有助于诊断。一个重复的告警并不是另一个价值单元。一个在审查前自动关闭的事件可能是有用的证据，但除非团队验证了该抑制是安全的，否则不应计为避免的人工操作。
遗漏的故障需要一个配套指标，因为它们不会在分母中产生任何项目。追踪那些由 New Relic、另一个监控工具、员工或客户首次发现的、影响客户的事件。追踪那些产生了有用 New Relic 通知的覆盖事件。然后同时计算告警精确率、可操作覆盖率和首次检测比例，以及成本。一个漏掉高代价故障的更便宜的告警系统，其实并不便宜。
分子应以金钱和工程师时间两种方式衡量。仪表化包括添加服务和业务属性、测试升级以及维护收集器。收集操作包括队列、重试和基数控制。查询治理包括审查、版本化和归属。调优包括灵敏度、窗口、季节性、缺口处理和静默。分类包括每个查看过通知的接收人，而不仅仅是最终的解决者。事件回顾包括在服务修复后修复告警。
摄取定价创造了一个重要的激励。更多的遥测数据可以改善诊断和覆盖率，但其中大部分可能永远不会有助于一个有用的决策。积极的数据丢弃或采样可以节省资金，但可能会移除解释事件的罕见追踪。经济目标不是最小的 GB 数，而是最经济的证据集，它可以保持对约定风险的检测和诊断。这通常意味着高质量的服务级别和业务信号，用于调查的选择性详细信息，以及按用例明确保留，而不是无限制地收集所有内容。
席位和访问权限同样塑造了人力投入。让开发人员直接获取上下文可以消除交接，而昂贵的完全访问权限可能会将调查集中于一个小型平台团队。采购方应该规划出每个角色实际需要哪些能力，基本访问是否足够，以及告警接收者是否可以在不等待拥有不同许可证或账户权限的人的情况下检查关联证据。
即使 OpenTelemetry 提高了可移植性，迁移成本仍需计入计算。基于开放 API 编写的仪表化可以向另一个后端发送数据，但 NRQL 条件、仪表盘、问题决策、静默规则、工作流过滤器、历史基线和调查习惯都是 New Relic 特有的资产。导出的遥测数据不会自动转化其中蕴含的运维含义。未来的退出需要并行运行、规则转换、重新培训，并证明替代品能检测到相同的故障。
认真的评估应使用普通故障并保留每次尝试
演示不应成为验收测试。评估应覆盖反复出现的普通服务和部署，包括那些消耗值班时间的平淡案例。选择一组有代表性的服务：稳定的高流量、低流量、定时批处理作业、自动扩展的服务、基于云轮询的指标、一个 OpenTelemetry 服务和一个原生代理服务。在配置告警之前，定义业务症状和预期的负责人。
仅在预发布或受控的生产演练中注入经授权的、可逆的故障。示例包括已知的错误率升高、对测试依赖项增加的延迟、停止的遥测数据导出器、延迟的批处理、更改服务名称的部署、过期的测试 webhook 以及预期的自动扩展终止。也包括正常但不寻常的事件，例如流量促销和计划内维护。目标不是最大化检测，而是区分有害的变化和无害的变化。
记录每个预定的案例，包括那些从未产生事件的案例。对于每次重复，捕捉遥测数据发出时间、可查询时间、告警事件时间、问题时间、通知送达、确认、正确负责人到达、诊断、缓解和服务恢复。将结果分类为：真正可操作、真实但迟到、重复、错误的负责人、不可操作、误报、漏报或未解决。保留第一次尝试；不要因为条件被编辑并重新运行了测试，就将漏掉的通知变为合格。
运行足够多的重复，以跨越例行变更：代理升级、一次部署、一个流量周期边界、一个周末、一次收集器重启和一次条件编辑。异常条件需要时间来学习，因此测试必须比较冷启动期和成熟期。在遥测延迟和部分缺失的情况下重复测试。对于关联，创建一个带有多个症状的故障和两个同时发生的不相关故障；既要衡量分组，也要衡量有害的合并。对于路由，除了初始激活外，还要测试确认和关闭更新。
与一个真实的替代方案进行比较。那可能是之前的平台、一个云原生告警、一个 Prometheus 加 Alertmanager 的路由，或者一个手动仪表盘流程。保持服务和故障不变。比较端到端的检测、有用的上下文、工程师耗时、遗漏的案例和每月成本。一个精美的问题页面只有在改善了上述某个结果时才有价值。
运维仪表盘应在采购后继续使用。有用的衡量指标包括：可操作告警率；覆盖事件的召回率；客户首次检测率；每个事件的重复通知数；错误负责人率；通知时间的中位数和尾部分布；诊断所需工程师耗时的中位数；无负责人或运维手册的告警；六个月未审查的条件；最近重置的异常条件；遥测错误率；触及基数限制的事件；以及按服务划分的每个可操作告警的成本。一个单一的全局分数将掩盖需要修复的服务。
替代方案阐明了 New Relic 被付费做什么
New Relic 与包括 Datadog、Dynatrace、Splunk Observability 和 Elastic 在内的集成商业平台，以及云原生服务和开源组件竞争。相关的比较不是功能清单，而是谁运营数据存储、集成、升级、扩展、查询系统、告警评估、关联和支持，以及有多少上下文能到达工程师手中。
Prometheus 将告警评估与Alertmanager分离，后者对告警进行分组、路由、抑制和静默。Grafana 可以跨数据源提供仪表盘和告警；Loki 和 Tempo 覆盖日志和追踪；OpenTelemetry 可以标准化收集。这套技术栈可以做到有效、透明和可移植。但它也将容量、高可用性、保留、升级、跨信号关联以及组件间接口的责任留给了客户，除非有托管提供商接手这些工作。
对于集中在 AWS、Azure 或 Google Cloud 的工作负载，云原生告警可能更简单。它们可以在没有额外代理的情况下查看平台指标，并提供一个独立的回退方案。但在跨多个云、应用和业务事件时，它们的连贯性会降低。一个专门的错误追踪器可以在开发者异常工作流方面胜过通用平台，同时将基础设施和服务级别的证据留在别处。
合理的架构可以是混合的。使用 New Relic 进行广泛的应用和跨栈分析，在可移植性和控制性重要的地方使用 OpenTelemetry，并为少数关键路径设置独立的告警。将业务级别的合成检查与内部症状告警分开。当导出每个高容量细节的增量价值很小时，使用本地或云原生指标。目标不是工具的纯粹性，而是可靠的检测，同时具有可理解的归属和成本。
当一个团队拥有足够多的异构服务，使得一个托管的数据和查询层能消除真正的集成工作时，New Relic 最有吸引力；但如果可观测性纪律如此之少，以至于平台变成了一个无人认领信号的仓库，则不然。当一个小规模系统已被原生云告警很好地服务，当数据传出或驻留约束占主导地位，当团队无法为仪表化的所有权提供资金，或者当现有的开源运维已经以可持续的成本交付可信的结果时，它的吸引力就较低。
哪些证据会改变判断
最缺失的证据是在重复的、公开的任务中的条件级别可靠性。New Relic 可以通过发布静态、异常和异常值条件在带版本的数据集上的精确率、召回率和检测时间分布来实质性地加强论据，并包含冷启动期、延迟数据、缺失数据、季节性变化和编辑。关联结果应报告有害的合并和遗漏的组，而不仅仅是被关联事件的比例。
如果包含前后条件数量、事件分母、客户首次检测、工程耗时、合同和摄取范围、实施持续时间、假阴性以及噪音的定义，客户证据将更具可迁移性。当有害事件的覆盖率保持稳定或有所改善时，告警数量的减少才具有说服力。没有这项衡量标准，静默可能意味着高效，也可能意味着盲目。
平台可靠性报告如果能包含受影响账户的比例以及摄取、评估和通知等组件的特定成功率，将会更有益。公开状态信息流很有用，但它无法生成告警送达率。采购方应索取自己的历史服务报告、支持响应承诺以及其订单中确切的可用性定义。
对于 New Relic AI，受控的或精心匹配的队列研究将有助于区分产品效果与客户成熟度。公布账户数量、采纳标准、严重性和架构控制、关闭机制以及置信区间。将平均关闭时间与独立的服务恢复时间戳联系起来。披露建议的根本原因或查询被接受、更正或忽略的频率。这些度量将把一个宽泛的关联转变为一个团队可用于容量规划的证据。
如果此类证据显示出高可操作覆盖率、低有害关联率，以及在计入仪表化和调优劳动之后工程师耗时持续减少，那么判断将变得更加正面。如果收益依赖于庞大的专家团队，如果异常重新学习产生了有意义的盲目期，如果路由故障很常见，或者如果成本控制一再移除诊断所需的证据，判断将变得更加负面。
结论：购买检测系统，为其维护者编制预算
New Relic 提供了一个技术上相当充实的可观测性平台。其共享的数据层、富有表现力的 NRQL、广泛的仪表化、流式评估、异常检测、事件关联和工作流，可以替代人工观察和碎片化的工具搜索。署名的客户报告了噪音和解决时间的大幅减少。OpenTelemetry 的支持减少了一个重要的锁定来源，而且文档对于延迟数据、重置、限制和缺失信号等方面异常坦诚。
该平台无法决定企业认为什么是有害的，无法保证客户的仪表化将其表达出来，也无法随着服务变更保持每个查询和路由都正确。更高级的模型改善了遥测数据与注意力之间的机制；但它们并没有消除监督这些机制的必要性。重复出现的人工工作从盯着仪表盘转变为设计信号、治理查询、审查异常、测试路由以及在事件后修复条件。
这可能是一笔极好的交易。几个小时的严谨告警工程可以节省更多重复的分类时间，并减少对客户的损害。当团队仅衡量摄入的数据和通知计数，允许条件在没有负责人的情况下累积，或将较低的告警量视为更高可靠性的证据时，这也可能是一笔糟糕的交易。
因此，New Relic 应作为检测系统而非神谕来购买和运维。测量从发出证据到合理行动的完整路径。保持对遗漏故障的可见性。将仪表化和调优的成本计入依赖它们的告警。用独立的检查保护最关键的路径。决定性的数字不是 NRDB 能容纳多少信号，也不是一个算法能分组多少事件。而是该系统多久能告诉正确的人一些真实的事情，足够早地产生影响，且总成本低于它防止的故障和劳力花费。