CompositeMeterRegistry filters are ignored if they are the child of another CompositeMeterRegistry

[gatlee]

Describe the bug

• CompositeMeterRegistry A contains CompositeMeterRegistry B contains some MeterRegistry C
• If there is a filter on B and a meter is added to A, B's filter will be ignored and the meter will still be added to C

Environment

• Micrometer version 1.7.3 & 1.82
• Micrometer registry any
• OS: macOS, Linux and Windows (CI)
• Java version:
  openjdk version "1.8.0_292"
  OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_292-b10)
  OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.292-b10, mixed mode)

To Reproduce
How to reproduce the bug:

@Test 
void childCompositeMeterRegistryShouldApplyFilter {
        final CompositeMeterRegistry rootComposite = new CompositeMeterRegistry();
        final CompositeMeterRegistry childComposite = new CompositeMeterRegistry();
        final SimpleMeterRegistry simpleMeterRegistry = new SimpleMeterRegistry(SimpleConfig.DEFAULT, mockClock);

        rootComposite.add(childComposite);

        childComposite.add(simpleMeterRegistry);
        childComposite.config().meterFilter(MeterFilter.denyNameStartsWith("deny"));

        rootComposite.counter("deny.item");

        assertThat(simpleMeterRegistry.getMeters(), empty());
}

Expected behavior
I would expect that the filters of the child CompositeMeterRegistry would be applied

[marcingrzejszczak]

Is this still a problem using the latest Micrometer versions?

[github-actions]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[github-actions]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open.

[izeye]

I can reproduce the reported behavior with the provided test.

See https://github.com/izeye/hello-micrometer/blob/micrometer-gh-3020/src/test/java/learningtest/io/micrometer/core/instrument/composite/CompositeMeterRegistryTests.java#L34-L54

[lenin-jaganathan]

I don't think adding meter filters of the child registry to the composite registry is a good thing. If there are multiple child registries added to a composite meter registry and each has a filter to allow only certain data for the registry, then adding all the meter filters to the composite will prevent from adding any meters.

E.g: Assume global has two registry implementations A and B. There is one-meter filter in each which does this,

1. A has a meter filter that will say only allow meters with prefix "A".
2. B has a meter filter that will say only allow meters with prefix "B".

If both of these are added to global, no meter will be registered since both cases cannot be true.

[marcingrzejszczak]

I understand but why would you want to add both to global? If someone adds a meter filter on the composite then it seems to make sense to pass these filters to child registries?

[lenin-jaganathan]

why would you want to add both to global?

Lof of open-source libraries (like reactor netty, resilience4j, etc.) add the metrics to global registries and users just wire up a registry implementation to export these metrics. So, you would need to add the registries to get these metrics. One more good use-case is to segregate the user code from registry-specific things. In case, ceratin data needs to be sent to a different back-end, we would just add a registry with the required filters.

If someone adds a meter filter on the composite then it seems to make sense to pass these filters to child registries?

This can be true but haven't given a lot of thought to this.