Sentry自托管部署中的登录循环问题分析与解决方案

问题背景

在Sentry自托管部署过程中，用户遇到了一个典型的登录循环问题。当部署在AWS EC2实例上的Sentry服务通过ALB负载均衡器访问时，如果后端有多个EC2实例，就会出现登录后立即跳转回登录页面的循环现象。而当只有一个EC2实例时，系统则能正常工作。

技术分析

会话管理机制

Sentry的会话管理采用Memcached+PostgreSQL的组合方式。Web容器本身是无状态的，所有会话信息都存储在外部服务中。这种设计理论上应该支持水平扩展，但实际部署中却出现了会话保持问题。

负载均衡配置

问题根源在于负载均衡器的会话保持配置。虽然用户后来启用了ALB的粘性会话功能，但初始配置存在问题：

1. 粘性会话最初配置在监听器级别而非目标组级别，导致不生效
2. 即使后来配置正确，持续时间设置(5分钟)可能不足以覆盖完整的用户会话

架构设计考量

用户部署的是一个分布式架构：

• 主Sentry服务部署在多个EC2实例上
• 外部组件包括：Kafka、Redis、RDS PostgreSQL、ClickHouse和Memcached
• 通过ALB进行负载均衡，配合ASG实现自动扩展

解决方案

正确的负载均衡配置

1. 确保粘性会话配置在目标组级别而非监听器级别
2. 将会话持续时间延长至1小时或更长时间
3. 验证Cookie-based的会话保持是否正常工作

存储优化建议

1. 外部存储配置：建议配置S3作为外部存储，用于处理附件、会话回放和配置文件等

   • 需要三个独立的S3存储桶：文件存储、符号存储和节点存储
   • 这可以减轻主EC2实例的存储压力

2. 数据库优化：

   • 对于PostgreSQL，建议将节点存储(nodestore)迁移到S3而非使用PostgreSQL表
   • 大容量数据会导致PostgreSQL的VACUUM操作失效

3. 消息队列优化：考虑使用Redpanda替代Kafka，在相同资源配置下可获得更好的吞吐量

生产环境建议配置

针对每月2000万事件的预期流量，建议的资源配置：

1. Sentry主EC2：

   • 实例类型：c5.4xlarge
   • 存储：60GB GP3(不再需要500GB，通过外部存储减轻负担)
   • 操作系统：推荐Debian/Ubuntu

2. ClickHouse服务器：

   • 实例类型：c5a.2xlarge
   • 存储：50GB GP3

3. 消息队列服务器：

   • 实例类型：t3.xlarge
   • 存储：8GB GP2(如使用Redpanda可考虑更高配置)

总结

Sentry自托管部署在多实例环境下的登录循环问题，主要源于会话保持配置不当。通过正确配置负载均衡器的粘性会话，并结合外部存储解决方案，可以构建一个稳定、可扩展的Sentry监控平台。对于生产环境，还需要特别注意各组件的资源配置和优化，特别是数据库和存储组件的合理规划。