New Relic vs Papertrail：实时看日志，和保留一条可追查的请求

只想把几台服务器的日志放到一起看，不一定需要先部署完整 APM。Papertrail 的实时日志查看、搜索与保存查询，已经能覆盖不少日常工作。真正需要换到 New Relic 这类平台的时刻，往往是团队不再满足于知道“发生了什么报错”，而要解释某次请求经过了哪些服务、时间花在哪里。

这两种需求也可能长期并存。日志集中的价值并不会因为没有链路瀑布图而消失；APM 的价值也不能靠给日志加一个更复杂的搜索框来衡量。比较时，应把即时查看、历史调查与应用关联分别说清楚。

观测云编辑部 · 2026 年 10 月 27 日。范围为 SolarWinds Papertrail 日志服务与 New Relic SaaS，依据官方资料，不包含接入耗时或查询性能实测。

实时滚动适合观察，完整导出需要另一种处理

Papertrail 的 Event Viewer 将多个来源的日志放到一起，可以搜索并观察新事件。部署后看错误是否继续出现、核对定时任务是否执行，这种直接面向消息的工作流很有用。它不要求先建立一套服务拓扑。Papertrail Event Viewer

但实时查看与完整读取不是同一保证。Papertrail 的 Search API 文档说明，用连续查询实现 live tail 时，如果到达速度高于读取速度，默认方式可能跳过部分结果，以免显示一直落后。需要完整结果时，应使用文档提供的 tail=false 等读取方式，并正确推进分页范围。Search API

这不是“平台随机丢日志”的证据，而是显示目标不同：一个窗口优先跟上现在，另一个任务优先读完所选记录。把浏览器里看到的最后几百条导出当作完整事故证据，或者拿它计算全部错误数量，都会超出这项入口本来的含义。

搜索保留和归档保留是两个期限

Papertrail 的核心搜索保留依套餐区分，官方用量文档列举一天、三天、一周、两周或一个月等配置。付费方案另含一年可下载归档，也可把归档副本写入自己的 S3 桶。不能把“一年归档”翻译成“一年内都以相同方式实时搜索”。用量与保留

归档以压缩的逐行记录保存，包含生成时间、接收时间、来源和消息等字段。官方说明数据约在 6—7 小时后出现在归档中；下载和后续长期查询有自己的路径。因此，刚刚发生的故障应先使用当前搜索，隔几个月的追查则要接受归档读取与处理的工作。永久归档

生成时间和接收时间值得一起保留。某台机器断网后补发日志，消息进入平台的时刻可能比事件晚很多。跨机器排查时，用错时间会把本来相关的记录分到不同窗口。旧数据还在文件中，只证明有原始材料，尚未证明它能在需要的时限内完成检索与解释。

New Relic 同样需要按数据类型与实际保留配置检查。日志保存得比 Span 更久时，历史日志可能仍可查询，但相关执行已不存在。把一个保留天数写给整个 APM 平台，会掩盖这种差异。New Relic 保留管理

Papertrail 告警不止“出现一条就通知”

Papertrail 可以为保存的搜索设置周期通知与最小匹配数量，也有检查没有匹配事件的 inactivity alerts。备份任务应每天输出成功记录，超过预期时间仍没有记录，就可以按无活动逻辑处理；并非所有这类需求都要另买复杂平台。Papertrail 告警

搜索告警仍有边界。文档列出每次调用最多包含 25,000 条日志和 10 MB 的 JSON 编码消息；高吞吐时，不应把通知中的消息列表当成完整事件台账。日志级告警也依赖应用确实输出了相应记录，采集停止和任务未执行可能表现相同，需要结合采集健康判断。

如果想问的是“付款请求中失败的比例”，而日志只记录失败、不记录请求总量，仅靠匹配数无法得出错误率。此时需要请求指标、完整事件口径或应用追踪。需求从“这个消息是否出现”变成“一个服务如何运行”，平台比较才开始进入 APM 的范围。

New Relic 增加的是请求上下文

New Relic APM 的 logs in context 使用实体、trace 和 span 元数据，把日志带入应用调查。既有采集器可以继续负责转发，由 Agent 只添加关联信息。这样既能沿用日志管道，也能避免重复发送。New Relic logs in context

应用插桩仍是前提。单独把 Papertrail 的消息转发到另一个平台，不会生成缺失的子 span，更不会还原过去没有采集的数据库等待。若日志里只有自由文本，先整理服务名、时间与请求标识，通常比直接迁移全部历史更有帮助。

观测云的日志查看器与日志关联链路提供另一种托管路径：保留集中日志工作，再加入已经采集的请求上下文。日志和链路必须使用一致标识，并在同一调查窗口内仍然可用。选择托管后端能减少运行工作，业务字段仍由团队定义。

费用随你保留的工作而变

Papertrail 的传输量口径是实际消息长度再加每条 50 字节元数据。大量短消息会让这部分占比更明显；例如平均消息只有 50 字节，按这一口径每条就是 100 字节。这个例子只解释计量，不包含网络协议开销或压缩效果。Papertrail 计量定义

New Relic 要同时看摄入、适用的用户或计算方案、保留和附加项。其 GB Ingested 也不是简单等于采集器发出的原始字节，而是按平台处理后的计量定义计算，不能直接把两家的 GB 单价相除。New Relic 计费

如果日常问题仍然可以由消息、时间与来源解释，Papertrail 是值得保留的集中日志工具。经常需要串起服务调用、性能趋势和相关日志时，New Relic 的 APM 上下文才有明确用途。不要为了“全栈”增加未使用的采集，也不要为了保持工具简单，让每次调查都依靠人手复制标识到几个系统里搜索。