Skip to content
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

Add auto-configuration for Micrometer DiskSpaceMetrics #26001

Closed
wants to merge 4 commits into from
Closed

Add auto-configuration for Micrometer DiskSpaceMetrics #26001

wants to merge 4 commits into from

Conversation

onobc
Copy link
Contributor

@onobc onobc commented Apr 11, 2021

@philwebb this one is a bit interesting as to where the "home" for the auto-configuration should go for "DiskSpaceMetrics". It is in the Micrometer JVM package but feels a bit more like "System" metrics.

2 reasons I landed it in the JvmMetricsAutoConfiguration:

  • I rooted it to user.dir which is the current working directory the JVM was launched from
  • the metrics implementation uses methods on File that are from the viewpoint of the VM. For example, from File.getUsableSpace :

    Returns the number of bytes available to this virtual machine on the partition named by this abstract pathname

Fixes gh-25996

@Bean
@ConditionalOnMissingBean
public DiskSpaceMetrics diskSpaceMetrics() {
return new DiskSpaceMetrics(new File(System.getProperty("user.dir")));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would we want to make this configurable? That could easily move it out of the "JVM" category if it was just some random path.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given how easy it is to expose it, I am not sure I would make it configurable (at least for a first version). However the disk space health indicator uses the current path (i.e. new File(".")) so I'd rather use that.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Apr 11, 2021
Copy link

@cuspymd cuspymd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the validateBaseJvmMetricsBeansArePresent() function returns the ContextConsumer interface, it seems that the calling method needs to be changed.

@snicoll snicoll added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Apr 19, 2021
@snicoll snicoll added this to the 2.6.x milestone Apr 19, 2021
Copy link
Member

@snicoll snicoll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR @bono007. I've scheduled it for our next feature release.

}

private ContextConsumer<AssertableApplicationContext> validateBaseJvmMetricsBeansArePresentWithCustomBean(
String customBean) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't overuse ContextConsumer like this. The essence of the assertion is to show that a single bean of a given type is present, and the one with the custom name we've added there as well (hence it's used). By moving this to a method that takes "a bean name", the link between the two is less obvious so I don't think this abstraction improves readability.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough. I will update sometime today.

@Bean
@ConditionalOnMissingBean
public DiskSpaceMetrics diskSpaceMetrics() {
return new DiskSpaceMetrics(new File(System.getProperty("user.dir")));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given how easy it is to expose it, I am not sure I would make it configurable (at least for a first version). However the disk space health indicator uses the current path (i.e. new File(".")) so I'd rather use that.

@snicoll snicoll self-assigned this Apr 21, 2021
@snicoll snicoll modified the milestones: 2.6.x, 2.6.0-M1 Jun 1, 2021
snicoll pushed a commit to snicoll/spring-boot that referenced this pull request Jun 1, 2021
snicoll added a commit to snicoll/spring-boot that referenced this pull request Jun 1, 2021
snicoll pushed a commit that referenced this pull request Jun 11, 2021
snicoll added a commit that referenced this pull request Jun 11, 2021
@snicoll snicoll closed this in a2e6fbf Jun 11, 2021
@snicoll
Copy link
Member

snicoll commented Jun 11, 2021

Thanks again @bono007.

@onobc
Copy link
Contributor Author

onobc commented Jun 11, 2021

Thanks again @bono007.

My pleasure @snicoll

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

Successfully merging this pull request may close these issues.

Auto-configure micrometer DiskSpaceMetrics
4 participants