-
Notifications
You must be signed in to change notification settings - Fork 40.8k
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
Replace hierarchical metrics with micrometer-based dimensional metrics #9970
Replace hierarchical metrics with micrometer-based dimensional metrics #9970
Conversation
Dependencies and autoconfigurationThe "quickstart" for Spring Boot is currently:
We could drop the annotation and add a marker interface in each starter module for use in autoconfiguration, but I'm a bit concerned about what happens if more than one starter winds up on the classpath. Open to suggestions on this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think activation was done on a user provided bean.
spring-boot-actuator/pom.xml
Outdated
<!-- Optional --> | ||
<dependency> | ||
<groupId>io.prometheus</groupId> | ||
<artifactId>simpleclient_common</artifactId> | ||
<version>0.0.26</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Versions probably go in spring-boot-dependencies
import org.springframework.boot.actuate.endpoint.RequestMappingEndpoint; | ||
import org.springframework.boot.actuate.endpoint.ShutdownEndpoint; | ||
import org.springframework.boot.actuate.endpoint.TraceEndpoint; | ||
import org.springframework.boot.actuate.endpoint.*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
*
imports :-)
Thanks, @jkschneider. This is great stuff. I'm excited to get it into Boot. It's going to take a while to digest, particularly as half the team are on holiday. In the meantime, here's a few general comments:
You can fix these if you're so inclined, or we can take care of them when we merge this. I just mention them now as I noticed them on a first read through of the changes. |
Will this be part of 2.0.0? |
I've started a more in-depth review and polishing of these changes here. It's still very much a work in progress. The biggest change and potential issue that I've seen thus far is that with the Micrometer-based metrics we lose the metrics endpoint and, I think, the ability for an app to be self-sufficient in terms of storing and "serving" its own metrics. That functionality isn't much use in a serious production environment, but I suspect that people will miss it elsewhere. @jkschneider You've described Micrometer as "think SLF4J, but for metrics". Is there an equivalent of |
@wilkinsona The boot configuration has changed quite a bit in preparation for Micrometer release 0.11.0. Once that release goes out, I'll update this PR. There is a I've talked with a number of folks about the metrics endpoint. My opinion currently is it isn't going to really be possible to create a meaningful information dump in JSON from dimensional metrics. For the single instance self-service route, Netflix uses JMX, and Micrometer packs with a JMX registry that flattens dimensions to a hierarchical name and ships them there. We should talk more about this! |
It may be more productive when reviewing to review the contents of micrometer-spring-legacy and imagine that reactive support is added. |
Cool, thank you. If possible, can you update the PR on top of my branch please? |
My, perhaps naive, reaction to that is that if we can flatten the dimensions to a hierarchical name and ship them over JMX then we should be able to do the same for HTTP/JSON. Failing that, a single endpoint that returns a JSON payload containing all the metrics may be better than nothing. |
Update `MetricsAutoConfiguration` to use an `ObjectProvider` to guard against missing beans. See gh-9970
Update `MetricsClientHttpRequestInterceptor` to use `percentilesTime` rather than `percentiles`. See gh-9970
Update configuration property classes used with micrometer so that they no longer directly implement `Config` interfaces. Properties are now adapted to Config implementations independently. See spring-projectsgh-9970
Update configuration property classes used with micrometer so that they no longer directly implement `Config` interfaces. Properties are now adapted to Config implementations independently. See gh-9970
After this change are the Micrometer metrics reported via the /metrics actuator endpoint? |
@manderson23 Yes, though because of the switch to a dimensional system, the format necessarily changed. There are some inadequacies in the /metrics endpoint that shipped with Boot 2 M4 that will be addressed in the M5 release (micrometer 1.0.0-rc.2) next week. See micrometer-metrics/micrometer#124. |
Is there going to be a migration guide for those of us who have, say, |
@ryonday Please comment on #10313 if there's anything specific that you'd like to see in the documentation on upgrading from 1.x.
I can't find any instances of |
@wilkinsona Thanks for the quick response! For example: https://github.com/spring-projects/spring-boot/blob/master/spring-boot-project/spring-boot-actuator/README.adoc line 41 maintains the It's unclear from the 2.0 documentation the prescribed method of recording one's own metrics (the section was removed from the docs). Is the expectation that we're use Micrometer directly within our applications? the |
Thanks. I forgot about the README when updating the documentation. I've opened #10686.
Yes, that's right. Micrometer's API is a replacement for
Micrometer has the same goal. It's led by a member of the Spring team (@jkschneider) and aims to be SLF4J but for metrics. You can use the |
@ryonday There wasn't much we could do to preserve the original |
Let this be a starting point for discussion. Currently:
@EnableAtlasMetrics
, etc instead of classpath-based autoconfiguration because support for several monitoring systems are based on the same dependency (spectator-api).I expect many changes, but look forward to your feedback!
cc / @philwebb @mbhave