Sentry自托管服务中Snuba连接错误的排查与解决

问题背景

在使用Sentry自托管服务时，用户登录后遇到"加载数据错误"的提示。通过检查日志发现，系统尝试连接Snuba服务时出现了连接被拒绝的错误。这个问题发生在从23.12.0版本升级到24.9.0版本后，环境配置包括Azure虚拟机、Ubuntu 20.04系统、Docker引擎和Nginx前端代理。

错误现象分析

系统日志显示以下关键错误信息：

1. Web容器尝试通过HTTP连接到127.0.0.1:1218端口时失败
2. 错误表明连接被拒绝(ConnectionRefusedError)
3. 最终导致SnubaError，无法完成数据查询操作

同时，Kafka和Clickhouse日志中也出现了相关错误：

• Kafka报告了关于topic ID的元数据发布错误
• Clickhouse记录了Socket未连接的错误

根本原因

经过深入分析，问题的根本原因在于环境变量配置不当。虽然docker-compose.yml中正确设置了Snuba服务的连接地址为"http://snuba-api:1218"，但在web容器的环境变量中单独设置了SENTRY_LOG_LEVEL，这导致web容器没有继承sentry_defaults中定义的关键环境变量，特别是SNUBA相关配置。

解决方案

解决此问题需要确保所有必要的环境变量都被正确传递到web容器：

1. 检查并确保web容器继承了所有必要的环境变量配置
2. 特别注意SNUBA相关的环境变量：
   • SNUBA: "http://snuba-api:1218"
   • SENTRY_SNUBA_HOST: "http://snuba-api:1218"
3. 如果确实需要单独设置某些环境变量(如日志级别)，应该确保不会覆盖其他关键配置

经验总结

1. 在升级Sentry自托管服务时，环境变量配置需要特别关注
2. 容器间的服务发现依赖于正确的环境变量配置
3. 日志中的连接被拒绝错误往往指示服务发现或网络配置问题
4. 部分覆盖环境变量可能导致意外的配置丢失
5. 对于复杂的分布式系统，确保所有组件使用一致的服务发现机制至关重要

最佳实践建议

1. 使用统一的环境变量管理方式，避免部分覆盖
2. 升级前备份关键配置
3. 实施变更时进行逐步验证
4. 建立完善的日志监控机制，及时发现类似连接问题
5. 理解Sentry各组件间的依赖关系，特别是Snuba服务的关键作用

通过这次问题排查，我们不仅解决了具体的连接错误，更重要的是加深了对Sentry自托管架构中服务发现机制的理解，为今后的运维工作积累了宝贵经验。