应用监控：Sentry 还是 ARMS？

开篇：一个真实的困境

假设你管理着 10 个项目，全部接入 Sentry 做错误监控。每个月看着账单，你心里嘀咕：这笔钱花得值不值？阿里云销售天天推荐 ARMS，说能"前后端一体化"；开源社区又说 GlitchTip 可以零成本替换。到底该信谁？

先说结论：没有完美的单一方案，只有最匹配你场景的"组合拳"。

一、先搞清楚：你真正需要监控什么？

在对比工具之前，我们先定义一个完整的监控体系应该覆盖什么。很多团队选错工具，根源是不知道自己缺什么。

三大监控板块

板块	解决什么问题	典型指标
前端体验监控	页面白屏、卡顿、JS 报错、API 超时	错误率、首屏时间、FPS、请求失败率
后端链路监控	接口慢、数据库拖后腿、微服务调用混乱	响应延迟、QPS、慢 SQL、调用链
业务与用户洞察	用户怎么用、为什么流失、哪里卡住了	会话回放、行为热力图、转化率

关键认知：Sentry 擅长第一块（前端错误追踪），商业 APM（如 ARMS）擅长第二块（后端链路），第三块则需要专门的分析工具。

二、Sentry 的"护城河"：为什么开发者离不开它？

Sentry 能成为行业标准，不是偶然。它有几个真正不可替代的能力：

1. 会话回放（Session Replay）------ 像看监控录像一样调试

这是 Sentry 的杀手锏。当用户报错时，你可以完整回放 他从进入页面到触发错误的全过程：点了哪个按钮、输入了什么、页面怎么变化的。这不是简单的操作日志，而是真正的屏幕录像。

ARMS 也有"用户行为回溯"，但本质上只是记录"点击了A、调用了B API"这样的日志列表，不是录屏。排查复杂交互问题时，差距巨大。

2. 错误直达代码行 + Git 提交人

Sentry 报错时直接显示：

哪一行代码出错了
上次是谁改的这段代码
相关的 Git 提交记录和 PR

这意味着从报错到定位责任人，可能只需要 30 秒。ARMS 只能定位到错误栈，排查效率差距明显。

3. 开源生态与自托管自由

Sentry 可以完全自托管（虽然需要维护 40+ 容器），数据完全自主可控。对于金融、政务等合规敏感场景，这是硬性要求。

三、ARMS 的"碾压区"：Sentry 做不到的事情

阿里云 ARMS 不是来替代 Sentry 的，它是来补足 Sentry 盲区的。

1. 前后端链路追踪：一键从报错跳到慢 SQL

这是 ARMS 最大的卖点。配置 enableLinkTrace: true 后，前端请求会自动在 Header 中注入 EagleEye-TraceID，后端应用监控可以关联这个 ID。

真实场景：用户反馈页面加载慢 → ARMS 前端监控看到某个 API 耗时 3 秒 → 点击"链路追踪" → 自动跳转到后端调用链，发现是某个 SQL 查询耗时 2.8 秒 → 直接定位到慢 SQL 和对应代码行。

Sentry 也能做前后端关联，但需要后端也部署 Sentry SDK，且链路追踪能力较弱（主要靠手动传 trace ID）。

2. API 耗时分解：区分"网络慢"还是"后端慢"

ARMS 会在调用链详情中展示：

请求发送耗时
网络传输耗时
后端处理耗时
响应接收耗时

如果是"网络慢"，说明要优化 CDN 或用户网络；如果是"后端处理慢"，说明要优化代码或数据库。Sentry 无法做这种分解。

3. 与阿里云生态深度集成

SLS 日志服务：所有监控数据存储在 SLS，可以用 SQL 做自定义查询
Grafana：支持接入 ARMS 数据源，自定义仪表盘
云监控：与阿里云告警中心打通，支持电话、短信、钉钉等多渠道

四、成本对比：钱到底花在哪了？

对比项	Sentry（云版）	ARMS 前端监控
免费额度	5k 错误/月（基础版）	2 万次上报/天（15 天试用）
付费模式	按错误事件量	按 PV 上报次数（约 0.007 美元/1000 PV）
典型月成本（假设 100 万 PV）	约 49 美元/月	约 7 美元/月
自托管成本	免费，但需维护（40+ 容器）	不支持自托管

结论：按量付费下，ARMS 前端监控比 Sentry 便宜不少。但如果使用资源包，ARMS 200 万 PV 的资源包约 99 美元，单价约 0.05 美元/1000 PV。

但要注意：ARMS 的便宜是前端监控模块的便宜。如果你需要后端 APM、Prometheus 监控等，那是另外的价钱。

五、Sentry 的"平替"们：不想花钱怎么办？

如果你主要是想降本，而不是替换功能，有几个零代码改动的方案：

方案 A：GlitchTip ------ 最轻量的自托管替代

核心优势 ：完全兼容 Sentry SDK，改个 DSN 地址就能用，零代码改动
架构：4 个容器（Django + Celery + PostgreSQL + Redis），2GB 内存就能跑
价格：自托管免费；托管版 15 美元/月起（100k 事件/月）
缺点：没有会话回放，没有分布式追踪，UI 不如 Sentry 精致

适合谁：想自托管省钱，但不想折腾 Sentry 复杂架构的团队。

方案 B：Bugsink ------ 单容器极简主义

核心优势 ：单个 Docker 容器就能跑，SQLite 起步，可切换到 PostgreSQL/MySQL
特点：只干一件事------告诉你什么时候坏了、为什么坏。没有仪表盘套仪表盘，没有 APM，没有回放
缺点：功能极简，团队规模小，长期路线图不确定

适合谁：个人开发者或极简团队，想要最低运维负担的自托管方案。

方案 C：PostHog ------ 免费层最慷慨

核心优势 ：免费层包含 10 万错误/月 + 5k 会话回放/月，还附赠产品分析和功能开关
价格：免费层之后按量付费
缺点：不兼容 Sentry SDK，需要接入 PostHog SDK

适合谁：初创团队，想一个平台覆盖分析 + 监控，错误量不大（每月 10 万以内）。

六、全链路开源方案：不想被厂商绑定？

如果你希望统一前后端监控栈，避免厂商锁定，可以考虑基于 OpenTelemetry 标准的开源方案：

SigNoz ------ OpenTelemetry 原生

覆盖范围：前端 Web Vitals + 后端追踪 + 日志 + 指标
特点：无 per-seat 费用，完全开源可自托管
接入方式：使用 OpenTelemetry SDK，标准协议，避免厂商锁定

ts 复制代码

// 前端接入示例
import { WebTracerProvider } from '@opentelemetry/sdk-trace-web';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';

const provider = new WebTracerProvider();
provider.addSpanProcessor(new BatchSpanProcessor(
  new OTLPTraceExporter({ url: 'https://your-signoz/api/v1/traces' })
));
provider.register();

OpenReplay ------ 专攻会话回放

覆盖范围：会话回放 + 性能监控 + 错误追踪
特点：免费 1000 会话/月，回放能力接近 Sentry
适合：特别看重会话回放，但不想用 Sentry 的团队

七、2026 年最佳实践：分层策略推荐

结合你的现状（10 个项目用 Sentry，2 个核心项目有自研 Experience SDK），以下是经过验证的分层策略：

复制代码

┌─────────────────────────────────────────────────────────────┐
│  核心 C 端项目（如 shangcheng、welfare-fusion）             │
│  方案：保留 Sentry（会话回放 + Git 集成不可替代）           │
│         + 接入 ARMS 后端应用监控（补足链路盲区）            │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  一般 C 端项目（其余 8 个）                                 │
│  方案：评估迁移到 PostHog 免费层或 GlitchTip 自托管           │
│         释放 Sentry 付费额度，降低成本                       │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  管理后台项目（当前无监控）                                 │
│  方案：部署 GlitchTip 或 Bugsink 自托管（零成本）           │
│         填补监控空白，2GB VPS 足够                          │
└─────────────────────────────────────────────────────────────┘

具体行动清单

优先级	行动	预期收益	工作量
🔥	为核心项目后端接入 ARMS 应用监控	获得前后端链路追踪能力	1-2 天
🔥	试用 ARMS `enableLinkTrace` 验证跨端排查	确认是否能解决实际痛点	半天
🔶	选 1 个非核心项目迁移到 PostHog/GlitchTip 试点	验证替换可行性，对比体验	1-2 天
🟢	为管理后台部署 GlitchTip 自托管	填补监控盲区，零成本	半天
🟢	评估半年 Sentry 账单 vs 替代方案成本	量化降本空间	半天

八、一句话总结

ARMS 不能完全替代 Sentry ，会话回放和 Git 集成是 Sentry 的护城河。但 ARMS 在前后端链路追踪 和 API 耗时分解上碾压 Sentry。

最优方案是"互补"而非"替换"：

核心 C 端：保留 Sentry + 接入 ARMS 后端监控
非核心项目：评估 PostHog 免费层或 GlitchTip 自托管降本
管理后台：用 GlitchTip/Bugsink 补盲区

监控工具不是宗教信仰，是生产力工具。按需分层、组合使用，才是 2026 年最务实的答案。