Skip to content

Don't apply MeterFilter to auto-configured composite registry #23381

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jkschneider opened this issue Sep 17, 2020 · 3 comments
Closed

Don't apply MeterFilter to auto-configured composite registry #23381

jkschneider opened this issue Sep 17, 2020 · 3 comments
Labels
type: enhancement A general enhancement
Milestone

Comments

@jkschneider
Copy link
Contributor

jkschneider commented Sep 17, 2020

Met with a team today that is configuring two PrometheusMeterRegistry instances, one for platform metrics and the other for application metrics. They expose two different scrape endpoints from the application. The platform metrics should include framework-level metrics like CPU, GC, http request timings, etc. The application metrics endpoint is reserved for teams to record business metrics.

Both of these registries wind up under the CompositeMeterRegistry Spring Boot creates. (I hope you enjoy my senseless ascii art ;) ).

                             Composite
                     ----------/    \
                   /                 \
        Prometheus (platform)     Prometheus (app)

The problem is that PropertiesMeterFilter is added to the composite in addition to both sub-registries. So if an app team adds a property like management.metrics.enable.tomcat=false the composite denies Tomcat metrics before it ever reaches the platform registry.

I suggest we weaken PropertiesMeterFilter and only apply it to sub-registries. In this way, a user-crafted registry could add meter filters that take precedence over PropertiesMeterFilter, like this:

@Bean
PrometheusMeterRegistry platformRegistry() {
    PrometheusMeterRegistry prometheusMeterRegistry = new PrometheusMeterRegistry(PrometheusConfig.DEFAULT);
    prometheusMeterRegistry
            .config()
            .meterFilter(MeterFilter.acceptNameStartsWith("tomcat"))
            .meterFilter(MeterFilter.acceptNameStartsWith("jvm"));
    return prometheusMeterRegistry;
}

cc / @wangyf2010
cc / @shakuzen

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Sep 17, 2020
@philwebb philwebb added the for: team-attention An issue we'd like other members of the team to review label Sep 17, 2020
@philwebb
Copy link
Member

I'm a little worried that MeterRegistryConfigurer can make the assumption that a CompositeMeterRegistry can be skipped because it is only composed of other beans. The user could register their own CompositeMeterRegistry which is composed of instance that we have no visibility on.

Perhaps we need a AutoConfiguredCompositeMeterRegistry class so that we know it's the one that we auto-configured and it only contains beans?

@philwebb philwebb added status: waiting-for-feedback We need additional information before we can continue and removed for: team-attention An issue we'd like other members of the team to review labels Sep 18, 2020
@jkschneider
Copy link
Contributor Author

I agree @philwebb, I think that makes sense.

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Sep 18, 2020
@philwebb philwebb added type: enhancement A general enhancement and removed status: feedback-provided Feedback has been provided status: waiting-for-triage An issue we've not yet triaged labels Sep 18, 2020
@philwebb philwebb added this to the 2.4.x milestone Sep 18, 2020
@philwebb philwebb changed the title Weakening PropertiesMeterFilter precedence Don't apply MeterFilter to auto-configured composite registry Sep 18, 2020
@wilkinsona wilkinsona modified the milestones: 2.4.x, 2.4.0-RC1 Sep 21, 2020
@jkschneider
Copy link
Contributor Author

Thanks for the quick action @wilkinsona. Could you try this out @wangyf2010?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

4 participants