错误监控回答“代码哪里坏了”。它应该聚合异常、保留堆栈和请求上下文、关联发布版本并通知负责人；它不替代原始日志、指标或完整 APM。
| 工具 | 主要定位 | 适合场景 | 主要代价 |
|---|---|---|---|
| Sentry | 错误、性能和发布回归 | 前端、后端、移动端和全栈团队 | 事件量、采样和保留周期需要控制 |
| Rollbar | 错误聚合与告警 | 快速收集错误、版本和通知 | 范围主要集中在错误监控 |
| Bugsnag | 稳定性与用户影响分析 | 发布稳定性、错误趋势和受影响用户 | 日志和基础设施能力需要外接 |
| Airbrake | 异常监控与性能概览 | Rails、Ruby 和 Web 应用 | 深度可观测性需搭配其他平台 |
Sentry：异常上下文和发布回归
Sentry 适合捕获前端、后端和移动应用错误，并保留堆栈、用户、请求、版本和 Breadcrumb。发布流程应接入 Release 信息，以判断错误是否由新版本引入。
常见接入点包括前端未捕获异常、API 5xx、超时、数据库异常、队列和定时任务失败。敏感输入、Token、支付信息和密码必须在上报前脱敏。
Rollbar、Bugsnag 与 Airbrake
Rollbar 更聚焦错误聚合、版本追踪和通知；Bugsnag 更强调发布稳定性和受影响用户；Airbrake 适合快速接入 Web 异常并查看基础性能信号。选型重点是 SDK 覆盖、错误分组、部署标记、采样、用户影响、通知渠道和数据保留。
怎么选
| 需求 | 优先考虑 |
|---|---|
| 前后端异常、发布回归和较完整生态 | Sentry |
| 只需要错误聚合和通知 | Rollbar |
| 重点看发布对用户稳定性的影响 | Bugsnag |
| Rails / Ruby 应用快速接入 | Airbrake |
告警至少要有环境、版本、服务、影响用户数、错误趋势、负责人、通知渠道、恢复通知和升级路径。性能、日志、指标与基础设施见应用性能监控方案对比、日志采集与日志平台对比和指标、链路与基础设施监控对比。