Sentry自托管版中ClickHouse数据保留策略失效问题分析

问题背景

在Sentry自托管环境中，当使用ClickHouse作为事件存储后端时，用户发现配置的SENTRY_EVENT_RETENTION_DAYS参数未能生效。尽管设置了7天的事件保留期，但ClickHouse中仍然保存着30天的历史数据，这导致了存储空间的异常增长。

问题表现

通过检查ClickHouse数据库，可以观察到以下现象：

1. 主要大表如spans_local、generic_metric_distributions_aggregated_local等仍然保留着30天的数据
2. 查询结果显示所有记录的retention_days字段值均为30，与配置不符
3. 新创建的分区仍然沿用30天的保留策略

技术分析

数据保留机制原理

Sentry的数据保留机制通过以下方式工作：

1. 环境变量SENTRY_EVENT_RETENTION_DAYS设置期望的保留天数
2. 事件写入时，系统会为每条记录标记retention_days字段
3. ClickHouse的TTL(Time-To-Live)机制根据该字段自动清理过期数据

问题根源

经过分析，问题主要出现在以下几个方面：

1. spans_local表的保留策略硬编码为30天，未遵循全局配置
2. 事件流处理过程中，span数据的retention_days字段未被正确设置
3. 分区策略与保留策略之间存在不一致性

解决方案

临时解决方案

对于急需释放存储空间的用户，可以手动管理ClickHouse分区：

1. 识别占用空间最大的表

SELECT t.database, t.name AS table_name, 
       sum(p.bytes_on_disk) AS table_size_bytes
FROM system.tables t
JOIN system.parts p ON t.database = p.database AND t.name = p.table
WHERE t.database = 'default'
GROUP BY t.database, t.name
ORDER BY table_size_bytes DESC;

2. 查看特定表的分区情况

SELECT partition, sum(bytes_on_disk) AS partition_size_bytes
FROM system.parts
WHERE database = 'default' AND table = 'spans_local' AND active = 1
GROUP BY partition;

3. 删除旧分区(每周数据存储在一个分区中)

ALTER TABLE spans_local DROP PARTITION (30,'2024-11-18');

永久解决方案

Sentry团队在25.1.0版本中修复了此问题，主要变更包括：

1. 修正了span数据的保留策略设置逻辑
2. 确保所有事件类型都遵循统一的保留配置
3. 优化了分区创建策略

升级到25.1.0或更高版本后，新创建的分区将正确反映配置的保留天数。

最佳实践

1. 定期监控ClickHouse存储使用情况
2. 在修改保留策略后，重启snuba容器使配置生效
3. 对于大型部署，考虑设置自动化监控和告警机制
4. 升级前评估存储需求，预留足够的缓冲空间

总结

Sentry自托管版中的ClickHouse数据保留问题源于特定表保留策略的硬编码实现。通过升级到修复版本或手动管理分区，用户可以解决存储空间异常增长的问题。建议用户定期检查系统配置与实际存储情况的匹配度，确保数据保留策略按预期工作。