单机自部署 Sentry 最有效的省资源手段不是锁老版本，而是切到 errors-only profile。
这套东西的资源占用跟事件量基本无关，大头是一堆为「性能/可观测性」功能空转的 consumer 进程——用不到就全砍掉。
它保留了什么
凡是「报错」需要的，一个都没少。
产品功能层面：Issues、Alerts、Integrations、Dashboards（基础看板）、Releases、Discover。
底层链路层面，完整的错误处理管道都在：
- Relay（事件 / 崩溃接收网关，minidump 端点也由它暴露）
- ingest-events、ingest-attachments 两个 consumer
- ClickHouse 的 errors 存储、web / nginx
- 关键的 symbolicator 符号化服务 和 attachments-consumer
也就是说原生崩溃上报全都能用——macOS Cocoa、Windows .NET 与 C++ minidump、Electron 的 JS 错误 + 原生 minidump，服务端符号化也照常。
它舍弃了什么
砍掉的全是性能 / 可观测性这一类，以及它们各自的一大批 consumer：
- Traces（分布式追踪）
- Profiles（性能剖析，连带 Vroom 服务）
- Session Replay（会话回放）
- 性能 Dashboards
- User Feedback（用户反馈）
- Crons（定时任务监控）
- Uptime（可用性监控，连带 uptime-checker）
- Application Metrics（应用指标）
对应移除的是 Snuba 的 transactions / replays / metrics / profiles / EAP 等 consumer、Sentry 侧一系列 consumer、Vroom、uptime-checker。省下来的资源就来自这里。
资源差距
| feature-complete | errors-only | |
|---|---|---|
| 容器数 | ~30+ | ~10 |
| 强制最低 CPU | 4 核 | 2 核 |
| 强制最低内存 | ~14 GB（部分版本抬到 ~16 GB） | 7 GB |
怎么选
切 errors-only，如果：
- 只需要错误 / 异常 / 崩溃追踪 + 告警（绝大多数自部署场景）
- 服务器资源吃紧（资源受限的 ECS 就属于这种）
- 做的是 Web / 后端 / 桌面应用的报错收集，不需要 APM 级别的性能洞察
留在 / 切回 feature-complete，如果：
- 需要分布式追踪、性能剖析、会话回放、性能看板、Crons、用户反馈中的任何一项
- 并且机器能配上 14 GB 内存 / 4 核以上
两条落地铁律
1. 干净搭建，别原地切。
首装前就在 .env.custom 设 COMPOSE_PROFILES=errors-only；已有实例迁移则彻底拆容器重建。
否则会踩两个坑：#3572（profile 没被正确应用，服务全起来了）和 #4299（残留容器搞乱 Kafka）。
2. 崩溃栈要可读，上传调试符号是硬前提（跟 profile 无关）。
CI 里接 sentry-cli debug-files upload，处理 dSYM（macOS）/ PDB（Windows）/ Electron 原生插件。
结论
资源受限 ECS + 桌面 / Web 报错的场景 → 用较新版本 + errors-only，再配合削减 Kafka 保留、限制 Redis 内存、调低事件保留天数。
要锁版本可锁 23.11.0（一个检查点），但更推荐用新版跑 errors-only——安全补丁照拿。
如果连 7 GB 都嫌重，再退到 GlitchTip。