OpenTelemetry规范中Exemplar过滤器与Reservoir的合并探讨

在OpenTelemetry规范中，Exemplar（样本）机制的设计一直是一个值得深入探讨的技术话题。最近，社区就Exemplar过滤器(ExemplarFilter)和Exemplar水库(ExemplarReservoir)这两个组件是否需要合并展开了讨论，这涉及到指标采集系统的核心设计理念。

背景与现状

Exemplar是OpenTelemetry指标系统中用于关联指标值与追踪数据的机制。当前规范中设计了两个主要组件：

1. Exemplar过滤器：作为SDK全局配置，对所有指标测量进行预过滤
2. Exemplar水库：负责存储和管理Exemplar样本

这两个组件在功能上存在重叠，都涉及对测量数据的筛选决策。过滤器执行"预过滤"，而水库也会对接收到的测量进行采样。

设计考量

全局开关与细粒度控制

当前Exemplar过滤器作为SDK全局配置存在，这带来了两个方面的考量：

1. 优势：可以作为全局开关，统一控制所有指标的Exemplar采集行为
2. 局限：无法针对不同指标管道(metric pipeline)进行细粒度控制

功能重复与实现复杂度

由于过滤器是全局性的，每个水库不需要重复实现过滤逻辑。如果将两者合并：

1. 每个水库都需要实现所有过滤策略
2. 或者需要为每种过滤策略组合创建专门的Reservoir实现

技术实现方案

经过社区讨论，提出了一个优雅的解决方案：

1. 移除AlwaysOn过滤器：直接由水库处理所有样本
2. 替换AlwaysOff过滤器：使用专门的"drop"水库实现
3. 引入装饰器模式：
   • 将TraceBased过滤器转换为装饰器水库
   • 装饰器水库可以包装其他水库实现
   • 在将测量传递给被包装水库前执行过滤逻辑
4. 默认实现优化：所有默认水库都使用TraceBased装饰器

规范演进建议

基于讨论，规范可以做出以下调整：

1. 将ExemplarFilter简化为SDK配置参数而非接口
2. 保留三种预定义行为(AlwaysOn/AlwaysOff/TraceBased)
3. 允许SDK自由选择实现方式，包括装饰器模式
4. 移除显式的ExemplarFilter接口定义

这种调整既保持了功能的完整性，又为SDK实现提供了更大的灵活性，同时简化了规范的定义。

总结

OpenTelemetry规范通过这次讨论，明确了Exemplar机制的设计方向。将过滤器概念简化为配置参数，同时利用装饰器模式实现功能组合，既满足了全局控制的需求，又保持了实现的灵活性。这种设计体现了OpenTelemetry在规范严谨性和实现自由度之间的平衡考量，为指标与追踪的关联提供了可靠的基础设施。