别再迷信全量采样了，聊聊我把 SigNoz 存储开销砍掉 95% 的实操经验

很多团队在部署可观测性方案时，最容易陷入的误区就是追求“全量可见”。尤其是使用基于 ClickHouse 存储的 SigNoz 时，如果不对遥测数据进行治理，存储空间的增长速度往往会超过业务增长速度，最终导致存储成本变成一个吞噬预算的黑洞。

我最近针对实际的回放负载进行了一次深度压力测试，为了量化每一条 Trace 的存储价值，我专门构建了一个 telemetry cost profiler（成本分析器）。测试结果非常极端：在确保关键错误链路 100% 保留的前提下，存储量直接从 13,404 降低到了 672，存储成本骤降 95%。这个结果其实揭示了一个残酷的现实：我们在监控系统中存储的大部分数据，其实是毫无意义的冗余。

要实现这种量级的成本优化，不能靠拍脑袋猜测哪个服务在浪费空间，我建议从以下三个具体维度进行治理。

首先是重构 Span 的采样策略。很多工程师习惯于设置 100% 的采样率，认为这样才不会漏掉问题。但实际上，对于一个健康运行的服务，99% 的请求路径是完全重复的。举个例子，一个每秒 10k QPS 的健康接口，如果存储 1 万条完全一样的成功响应记录，这对排查问题的贡献几乎为零。我建议采用动态采样策略，剔除掉那些重复性极高的健康请求，只在请求出现异常波动或延迟增加时提高采样率。

其次需要警惕高基数（High Cardinality）标签的冗余。在 SigNoz 依赖的 ClickHouse 存储引擎中，标签的基数直接影响索引大小和存储开销。很多团队在打 Tag 时随手加入了 user_id 或 request_id 这种唯一值，这会导致存储空间被疯狂刷掉。在优化过程中，建议检查所有自定义标签，将低价值的高基数标签移出核心索引，或者在采集端通过 OpenTelemetry Collector 的 attributes 处理器进行过滤，在数据进入存储之前就完成清洗。

最核心的优化逻辑在于实现“差异化保留”。我们其实不需要所有数据的 100% 可见，而只需要“错误链路”的 100% 可见。在配置采样规则时，必须确保 error=true 的 Trace 强制写入存储，而对于状态码为 200 且响应时间在正常范围内的请求，可以将采样率压低到 1% 甚至更低。这样既能保证在发生故障时有足够的证据链条进行回溯，又能在日常运行中极大地减轻存储压力。

对于需要大规模部署监控的团队来说，这种精细化治理的效率远高于单纯升级硬盘。建立一个能够量化“数据价值 vs 存储成本”的分析模型，通过对回放负载的分析来确定最优采样率，才是解决可观测性成本危机的根本方案。