Apache Pulsar Schema服务测试中的Prometheus指标隔离问题分析

在Apache Pulsar项目中，SchemaServiceTest测试类中的testSchemaRegistryMetrics方法近期被发现存在不稳定的测试行为（flaky test）。这个问题的根源在于Prometheus指标收集机制与测试隔离性之间的冲突。

问题背景

测试方法testSchemaRegistryMetrics原本设计用于验证Schema服务的各项指标是否正确记录和暴露。测试会创建Schema、获取Schema，然后删除Schema，最后检查这些操作是否生成了正确的Prometheus指标数据。然而，由于Prometheus客户端库使用静态字段存储指标数据，导致不同测试运行之间的状态会相互干扰。

问题具体表现

当测试运行时，预期会检查特定命名空间（tenant/ns）下的指标数据。但实际上，测试有时会捕获到其他测试运行产生的公共命名空间（public/ns_随机ID）的指标数据，导致断言失败。这种跨测试污染现象在JVM重用测试实例时尤为明显。

技术分析

Prometheus客户端库的设计采用了静态注册表模式，这意味着：

1. 指标数据在JVM生命周期内是持久化的
2. 不同测试类或测试方法共享同一个指标存储空间
3. 前一个测试留下的指标数据会影响后续测试

在SchemaServiceTest的具体场景中，测试没有正确清理或隔离这些全局状态，导致断言时捕获到了不相关的指标数据。

解决方案

针对这个问题，可以采用以下几种改进方案：

1. 指标数据过滤：在断言前，先过滤出属于当前测试命名空间的指标数据。可以使用AssertJ的流式断言来优雅地处理这种情况。

2. 测试隔离增强：在每个测试方法执行前后，显式地清理相关的Prometheus指标数据。这需要深入了解Prometheus客户端库的内部机制。

3. 断言逻辑改进：将硬性断言改为存在性检查，确保至少有一个符合预期的指标数据存在，而不是要求所有数据都必须匹配。

最佳实践建议

对于类似的指标测试场景，建议：

• 为每个测试使用唯一的命名空间或标签值
• 在@Before或@After方法中清理测试产生的指标数据
• 使用更灵活的断言方式处理可能存在的干扰数据
• 考虑使用测试专用的指标注册表实例

这个案例提醒我们，在编写涉及全局状态（如静态变量、单例实例）的测试时，需要特别注意测试隔离性问题，确保每个测试都能在干净的环境中运行。