New Relic vs AppSignal：一次慢任务，需要多少调查上下文

用户已经提交订单，确认邮件却迟迟没有到达。Web 请求很快返回了成功，真正堵住的是后台任务：可能还在排队，也可能已经执行，但一直等待数据库或第三方接口。只看首页响应时间，这次问题几乎不可见。

New Relic 与 AppSignal 都能参与这种调查，区别在于团队怎样组织证据。AppSignal 的框架集成可以把开发者带到熟悉的任务与异常；New Relic 则适合把服务、主机、日志和跨服务调用放进更广的调查路径。选择不能只按公司大小决定，还要看目前缺的是哪一段上下文。本文依据 2026 年 10 月 21 日官方资料比较托管服务，安装在应用旁的 Agent 或 Collector 不等于自托管分析后端。

先区分任务等待与任务执行

以 Rails 加 Sidekiq 为例，AppSignal Ruby 集成会在符合条件的 Rails 应用中插入 Sidekiq 服务端中间件，并围绕 worker 动作组织性能与错误信息；独立 Ruby 进程可能需要显式启动集成。队列长度、队列延迟和执行时长解决的是不同问题，不能把 worker 的耗时曲线当成用户从提交到收到邮件的总等待时间。Sidekiq 集成

这种贴近框架的组织方式有实际价值：如果同一团队拥有入口代码、后台任务和数据库，按任务名称进入样本、看 SQL 或外部调用，再查看异常，往往正好对应修复工作。但入口出现一条 enqueue 事件，不必然代表后台执行已与它组成完整链路。当前 Sidekiq 文档把跨任务的分布式追踪明确限定在 Ruby 的 Collector mode；默认集成与这一模式不能混写。

New Relic 的分布式追踪也依赖调用双方传递上下文和实际采集到的 spans。标准方案采用头部采样，Infinite Tracing 则通过 trace observer 提供尾部采样路径。尾部决策不是凭空补齐数据：没有埋点、未传递上下文或在到达观察器之前已被丢弃的部分，仍然无法恢复。追踪机制

因此，值得拿来试运行的是一次“请求已成功、任务后来失败”的完整流程。先看排队，再看执行，再看重试，最后确认告警对应的是最终失败还是每次尝试。这个问题比“装上以后有没有图”更接近日常使用。

OpenTelemetry 接入以后，界面还需要什么

AppSignal 已支持通过 OpenTelemetry 接入 Go、Java、PHP 等语言，并非只能覆盖少数原生 SDK。官方同时提醒 OTel 支持仍有功能与配置差异，不能假设所有原生集成特性都会出现。例如 Java 安装路径需要 OTel Java Agent、AppSignal Collector，以及应用名称、环境和凭证等配置；成功导出数据只是第一步。OTel 支持范围、Java 安装

New Relic 也有专门的 OpenTelemetry APM 界面，但 OTel span 与 New Relic transaction 并非同一个原始概念，页面中的事务与部分指标需要转换或推导。官方指出，从已采样 spans 推导的分段分析会受到采样影响；span 上出现 exception event，也不单独决定它被计入错误，错误状态还要正确设置。OpenTelemetry APM UI

这会影响迁移时的对账。如果两个页面上的错误数不同，应该先看统计的是任务尝试、异常事件还是错误 span，以及采样发生在哪里。让数字一致之前，需要先让它们指向同一种事件。业务上的“这封邮件最终发出了吗”，仍应由业务状态或明确的自定义事件回答。

日志补足链路没有保留的解释

AppSignal 的日志不是一个附带的文本窗口。它支持日志查询、自定义属性、触发器与日志指标，也可以通过额外的 Long-Term Log Storage 将日志导出到 S3 兼容存储。与此同时，当前日志文档列出每应用每分钟 50 万行、单行 10,000 字符以及深层 JSON 不支持等限制。日志很长或结构很深的系统，应先检查截断与字段处理，而不是笼统判断“有日志功能就够了”。日志文档

New Relic 的 APM logs in context 可以为日志添加 trace.id、span.id 和实体信息，并通过 Agent 转发；也允许只保留关联元数据，由现有日志采集链路负责转发。已有采集器的团队要避免把同一批日志通过两条路径重复发送。关联成功的前提仍是对应字段存在且含义一致。APM 日志关联

在邮件任务场景里，业务标识适合帮助找到重试记录，trace ID 则帮助定位某一次尝试。二者不要互相替代。若第三次尝试属于新链路，只搜第一次 trace ID 就可能漏掉最终成功记录；若只搜订单号，又可能把多次尝试的耗时混在一起。

预算取决于请求怎样变成数据

AppSignal 当前付费配置示例显示：每月 25 万次应用请求，按年付款为 279 美元，即折合每月 23.25 美元；日志有独立容量配置，长期日志存储另列付费附加项。免费方案列出 3 万次请求、1 GB 日志与 5 天保留，不能据此推断付费方案也统一保留 5 天。所有方案列有无限用户与应用，但这不等于请求和日志无限。当前价格页

New Relic 当前文档区分 Data + User 与 Data + Core Compute，后者仍处于 Preview，需要联系账户代表；另有 Advanced Compute。按用户方案看接入数据和用户类型，按计算方案还要看实际计算消耗。因此旧式“New Relic 永远按席位，AppSignal 永远按请求”的对比不够完整。New Relic 计费机制

做预算时，同一个业务订单可能产生一次入口请求、多次任务尝试、大量日志和多个 spans。应该用真实接入后的计量核对，而不是把订单量直接代入两个价格表。New Relic 的保留还按数据类型和账户设置区分，Transaction、TransactionTrace、Span 和 Log 的有效窗口不应概括成一个天数。保留配置

选能走完调查的那条路径

主要工作围绕受支持框架内的异常、后台任务与性能样本，且团队希望在应用语境中完成修复时，AppSignal 值得优先试运行。把接入方式、日志大小和实际额度验证清楚，比凭“小团队工具”标签作决定更可靠。

若事故经常跨越多个服务、主机与团队，已经需要跨数据类型查询，并愿意维护服务关联和用量治理，New Relic 更值得放在首选验证路径中。更大的产品范围也意味着更多配置与治理工作；不能假设买到这些能力就自动拥有完整证据。

两者的验收都可以落到同一件事：提交一次任务，制造一次可恢复失败，找到它的等待、执行、重试与最终结果，并让下一位值班人员沿同样入口走一遍。

在观测云中检查同一条任务链路

如果同时评估观测云，可用已接入的请求在链路详情中查看 spans、耗时与关联信息。先确认后台任务的上下文传递和日志关联，再扩大采集；页面能展示链路，并不代表未采集的排队时间会自动出现。