Skip to content

DataSource metrics are not auto-configured when using lazy initialization #30282

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
bellatoris opened this issue Mar 18, 2022 · 5 comments
Closed
Assignees
Labels
type: bug A general bug
Milestone

Comments

@bellatoris
Copy link

spring boot version: 2.6.4

After setting spring.main.lazy-initialization=true, hikari related metric disappeared from metric list. Although HikariDataSource is created during application context initialization, it was confirmed that HikariDataSourceMetricsConfiguration is not set. I have confirmed that HikariDataSourceMetricsConfiguration is the target of autoconfiguration as follows.

   DataSourcePoolMetadataProvidersConfiguration.HikariPoolDataSourceMetadataProviderConfiguration matched:
      - @ConditionalOnClass found required class 'com.zaxxer.hikari.HikariDataSource' (OnClassCondition)

   DataSourcePoolMetricsAutoConfiguration matched:
      - @ConditionalOnClass found required classes 'javax.sql.DataSource', 'io.micrometer.core.instrument.MeterRegistry' (OnClassCondition)
      - @ConditionalOnBean (types: javax.sql.DataSource,io.micrometer.core.instrument.MeterRegistry; SearchStrategy: all) found beans 'prometheusMeterRegistry', 'dataSource' (OnBeanCondition)
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Mar 18, 2022
@wilkinsona
Copy link
Member

Thanks for the report. I think this affects all DataSource metrics, not just when using Hikari. You can work around the Hikari metrics problem with the following exclude filter:

@Bean
static LazyInitializationExcludeFilter hikariMetricsLazyInitializationExcludeFilter() {
    return (name, definition, type) -> name.equals(
        "org.springframework.boot.actuate.autoconfigure.metrics.jdbc.DataSourcePoolMetricsAutoConfiguration$HikariDataSourceMetricsConfiguration");
}

@wilkinsona
Copy link
Member

wilkinsona commented Mar 18, 2022

DataSource metrics are currently bound via some slightly unusual @Autowired methods and it's been that way since the code was introduced.

If MeterBinder implementations were used instead, I think this would work correctly with lazy initialization. Perhaps there's a reason why a MeterBinder couldn't be used? EachMeterBinder is called as part of post-processing of the MeterRegistry bean which is earlier than the @Autowired approach which will happen sometime after the registry has been fully initialized. Flagging for team attention to see if anyone can recall if there was a reason for the current approach.

@wilkinsona wilkinsona added the for: team-attention An issue we'd like other members of the team to review label Mar 18, 2022
@wilkinsona wilkinsona changed the title HikariDataSourceMetricsConfiguration is not autoconfigured when lazy-initialization is enabled. DataSource metrics are not auto-configured when using lazy initialization Mar 18, 2022
@wilkinsona wilkinsona added type: bug A general bug and removed status: waiting-for-triage An issue we've not yet triaged labels Mar 18, 2022
@wilkinsona wilkinsona added this to the 2.5.x milestone Mar 18, 2022
@snicoll
Copy link
Member

snicoll commented Mar 19, 2022

In the current arrangement we have a @Configuration class with no hook-point to do something so we chose to add @Autowired for the lack of a better option. I agree it is unusual.

We considered switching those to implement SmartInitializingSingletonat some point but I can't find back the issue where this was discussed (if any). IMO, anything that gets rid of those and better use Micrometer's infrastructure is an improvement.

@wilkinsona
Copy link
Member

wilkinsona commented Mar 21, 2022

Thanks, @snicoll. A MeterBinder-based approach seems to work fine. These changes build cleanly at least. I am quite tempted to merge them.

@philwebb philwebb modified the milestones: 2.5.x, 2.7.x Apr 13, 2022
@philwebb philwebb removed the for: team-attention An issue we'd like other members of the team to review label Apr 13, 2022
@philwebb
Copy link
Member

philwebb commented Apr 13, 2022

We're going to merge the above fix, but only in 2.7 since there's some risk involved. For 2.5 and 2.6, please use the workaround above.

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

No branches or pull requests

5 participants