无法直连Sentry.io时Sentry Relay与自托管方案选型咨询

完全可以基于客户端-中转服务器-Sentry.io的架构搭建代理隧道，实现Sentry数据上报连通。该模式下客户端所有Sentry上报请求先发送到网络可达的中转节点，由中转节点完成跨网请求转发至sentry.io服务端，再将响应回传客户端，不存在架构层面的实现障碍。

Sentry Relay #

Sentry Relay是Sentry官方推出的专用流量转发组件，原生定位就是部署在业务客户端与Sentry服务端（含Sentry SaaS即sentry.io、自托管Sentry实例）之间做上报代理，对应该场景的适配性极强：

• 部署成本极低：单二进制文件即可启动运行，无额外强依赖组件，1核1G配置的中转服务器即可稳定承载中小规模业务的上报流量
• 接入成本极低：仅需在Relay配置中填写对应sentry.io项目的认证信息，客户端将原sentry.io DSN替换为中转Relay的服务地址即可完成接入，官方所有Sentry SDK全兼容，无需修改业务侧上报逻辑
• 原生能力无损耗：支持Sentry原生的事件过滤、动态采样、PII数据擦除、事件预处理等能力，上报数据格式与直连完全一致，无兼容性问题
• 运维成本极低：无需配置额外数据持久化存储，日常仅需保证Relay进程存活、中转服务器到sentry.io网络连通即可，几乎无额外运维工作量

Sentry自托管 #

Sentry自托管是包含前端界面、API网关、数据库、消息队列、事件处理引擎等十余个组件的完整Sentry服务栈，原生定位是满足数据全本地留存的私有化部署需求，完全不适配当前纯中转的场景：

• 部署运维成本极高：官方最低要求4核16G以上服务器才能启动基础服务，流量上涨后还需要拆分组件做集群扩容，部署涉及容器编排、存储调优、链路排障等复杂操作，运维工作量是Sentry Relay的数十倍
• 链路冗余故障点多：如果用自托管Sentry做中转，需要额外配置跨实例事件同步规则将数据转发到sentry.io，链路长、环节多，很容易出现数据丢失、上报延迟过高的问题；如果不配置转发直接使用自托管实例，数据会全部存在本地，和你需要使用sentry.io SaaS服务的核心诉求不符
• 资源浪费严重：该场景仅需要一层流量转发能力，自托管Sentry自带的事件处理、数据存储、用户管理等全套组件完全无法发挥作用，会占用大量不必要的服务器资源

针对sentry.io访问受限、仅需通过中转节点将上报流量转发至sentry.io的场景，优先选择Sentry Relay方案。如果业务规模极小、不想额外部署Relay组件，也可以使用Nginx、Caddy等通用反向代理做简单请求转发，但通用代理不支持Sentry事件预处理能力，兼容性和稳定性弱于官方Relay。

内容的提问来源于stack exchange，提问作者Mahan