New Relic 与 Grafana Cloud：已有指标体系，下一步怎么走

团队已经维护了几年 Prometheus 告警和 Grafana 仪表盘，却仍会在一次发布后卡住：延迟曲线变高了，相关服务很多，究竟是哪一次请求先出了问题？有人建议接入 New Relic，把应用调查集中起来；也有人希望保留现有指标体系，转向 Grafana Cloud。

两条路都可能成立。关键不在于谁的首页更完整，而在于已有查询和告警如何延续、指标如何连接到请求，以及托管之后还有哪些工作留给团队。Grafana Cloud 不是仅仅把 Grafana 界面放到云上，New Relic 的统一入口也不等于关联字段会自动出现。

先决定保留数据，还是只保留查询方式

Grafana Cloud 的数据源机制允许查询外部系统，也包含为托管指标、日志、链路和剖析服务配置的数据源。连接现有 Prometheus，与把指标写入 Grafana Cloud，是两种不同安排。

前一种保留了原后端的存储与运维责任；后一种把相应数据放入托管服务，但要重新核对采集配置、保留与用量。仪表盘查询能继续使用，并不证明原来的记录规则、告警权限和通知路由都已经迁移。

外部数据源还受网络和插件限制。Grafana Cloud 不能任意安装私有或未签名插件；私网地址需要合适的连接方式。PDC 可由客户部署 agent，把查询连接到私有网络内受支持的数据源。它提供连接路径，不会替你维护那里的数据库，也不会自动复制所有历史到云端。

这一区分对试用尤其重要。如果只把旧仪表盘接到了新的界面，应该评估的是查询入口是否改善，而不是宣称已经完成观测平台迁移。

从延迟曲线走到请求，需要真实关联

在已有 Prometheus 体系里，服务、集群和环境标签通常已经形成习惯。但指标里的 service 与链路资源的 service.name 是否代表同一对象，日志里是否还能找到对应请求，并不一定一致。

Grafana 的 trace-to-logs 配置会将 span 属性映射到日志查询，标签名称和时间范围需要匹配。能点击一个链接只是第一步；若查回的是整个服务的全部日志，还需要确认是否启用了适当的 trace 过滤以及对应标识确实存在。

New Relic 的 logs in context通过受支持的应用 Agent 补充 trace、span 和实体元数据，帮助从应用继续看日志。使用原生 OTLP 接入时，也要检查资源属性和信号格式。统一平台能缩短操作路径，但不能建立数据里没有的关联。

可以选一次发布回归作为试用任务：从同一个延迟告警开始，缩小到受影响版本，再打开一个慢请求和它的日志。比较的不是谁先显示一条曲线，而是谁能在现有权限与采样条件下保留完整解释。调查途中需要手工切换服务名、补时间范围或另找数据源的地方，就是下一步需要投入的维护工作。

Grafana Cloud 已有应用调查层

将 Grafana Cloud 描述为 Loki、Tempo 和指标的三个独立面板，会漏掉当前的 Application Observability。面向新组织的 knowledge graph 体验根据遥测发现服务与关系，并把指标、日志、链路及 profiles 连接到应用调查中。已有 classic 体验与新路径应分开核对，不宜把旧版手工配置要求套到所有账户。

新体验仍依赖采集质量。接入文档要求 OpenTelemetry 插桩，通过 Alloy 或其他 Collector 发送遥测，并配置用于识别服务的资源属性。已有业务指标和 exporter 不会凭空产生完整的应用 span。

因此，New Relic 与 Grafana Cloud 的差异不再是“有 APM”和“没有 APM”。更实际的是比较应用语言覆盖、团队已有配置、默认调查路径，以及缺少数据时能否定位原因。自动发现可以帮助组织证据，不能证明推断出的依赖就是某次故障的根因。

托管之后，配置仍需要负责人

采用 Grafana Cloud 可以减少相应托管后端的集群维护，但 Collector、抓取目标、标签治理和外部数据源仍在系统里。采用 New Relic SaaS 也不等于业务属性、采样与告警规则不再需要维护。两边都应该明确应用团队和平台团队各自修改哪些内容。

如果保留现有 PromQL，应重放有代表性的告警条件，核对窗口、缺失数据和标签分组。若把调查转到 New Relic，则需要重建相应 NRQL 查询与告警语义，而不是只复制图表标题。相同名称的“错误率”可能使用不同分母、过滤条件或聚合周期。

迁移时可以保留一段双写或并行查询窗口，但要区分验证成本与常态成本，并避免重复通知。结束窗口前，还应让值班人员验证旧事故链接、近期基线与历史查询的去向。数据离开旧系统之后，重新找到它的成本不会出现在仪表盘截图里。

指标标签与采集频率一起进入账单

Grafana Cloud 的指标计量同时看活跃序列和每分钟数据点 DPM，在计费周期内分别采用 P95，再按活跃序列与总 DPM 除以包含 DPM 两者中的较大值确定用量。仅统计 metric 名称数量，会漏掉标签组合与采集频率的影响。

例如固定 10,000 条序列，每 15 秒采集一次，对应每分钟约 40,000 个数据点。把间隔改成 60 秒会改变 DPM，却不必然改变序列数量；给每条序列加入不断变化的请求 ID 则可能显著增加基数。这只是输入量说明，不是某个套餐的账单报价。应先检查现有抓取与标签，再讨论平台单价。

日志另有规则。当前日志计量区分处理、写入、保留与超过公平使用额度的查询量。Adaptive Telemetry 丢弃数据可减少写入，不会抹掉已发生的处理用量。Application Observability 等产品也有自己的计量，不能把指标费用视为整个平台费用。平台计费概览明确说明了这种分项方式。

New Relic 的基础模型以数据量配合用户或 Core Compute；后者当前仍标为 Preview。Advanced Compute 能力另计。它与按活跃序列的报价不能直接用一个 GB 换算，应该用同一组工作负载分别测量各自的计费输入。

已有积累决定迁移的起点

如果现有 Prometheus 查询、告警与仪表盘是团队稳定的工作语言，Grafana Cloud 值得先从保留这些资产、补齐应用调查来验证。明确哪些后端继续自管，哪些数据进入托管服务，才知道运维责任实际减少了多少。

如果团队更希望围绕应用实体和统一调查入口组织工作，New Relic 可以作为候选，但要把现有规则改写、访问权限和历史基线纳入成本。已经使用 New Relic 的团队，也不需要仅为了“开放”就更换全部平台，可以先验证现有 OTLP 接入是否满足目标。

两者都没有脱离场景的成本或体验胜者。用一条真实的发布回归路径，让接班工程师从告警走到原因，并记录中间需要的人、数据和配置，比比较首页图表数量更有判断力。

在观测云中延续指标到请求的调查

同一任务也可以用观测云的链路详情验证：先定位保留的请求，再查看关联日志和服务上下文。指标告警提供时间与影响范围，链路关联提供具体证据；字段、采样和保留期仍要配合，不能只靠一个统一界面。

资料核对日期：2026 年 10 月 21 日。示例用于说明计量输入，未进行性能或总成本实测。