-
Notifications
You must be signed in to change notification settings - Fork 41.4k
Auto-configure Mongo metrics #23990
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
Auto-configure Mongo metrics #23990
Conversation
...va/org/springframework/boot/actuate/autoconfigure/metrics/MongoMetricsAutoConfiguration.java
Outdated
Show resolved
Hide resolved
@ConditionalOnClass(MongoMetricsCommandListener.class) | ||
@ConditionalOnProperty(name = "management.metrics.mongo.command-listener.enabled", havingValue = "true", | ||
matchIfMissing = true) | ||
static class MongoMetricsCommandListenerConfiguration { |
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 split this out into a nested config in anticipation of adding the metrics connection pool listener I alluded to in the initial description. They would be guarded by different classes and properties.
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.
Perhaps this should be called MongoCommandMetricsConfiguration
?
...g/springframework/boot/actuate/autoconfigure/metrics/MongoMetricsAutoConfigurationTests.java
Show resolved
Hide resolved
spring-boot-project/spring-boot-docs/src/docs/asciidoc/production-ready-features.adoc
Show resolved
Hide resolved
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.
Thanks very much for the PR, @Bono007. On first review, this looks excellent. I've left a few minor comments for your consideration when you have a moment.
Unfortunately, it's too late to add enhancements in 2.4, but we should hopefully be able to merge this for 2.5.
...g/springframework/boot/actuate/autoconfigure/metrics/MongoMetricsAutoConfigurationTests.java
Show resolved
Hide resolved
spring-boot-project/spring-boot-docs/src/docs/asciidoc/production-ready-features.adoc
Outdated
Show resolved
Hide resolved
...va/org/springframework/boot/actuate/autoconfigure/metrics/MongoMetricsAutoConfiguration.java
Outdated
Show resolved
Hide resolved
Thanks @wilkinsona . I am just now getting back to this and will update w/ suggestions shortly.
No worries. |
Perfect timing @jonatan-ivanov. My plan was to add the connection pool metrics listener auto-config this weekend. I will instead happily merge your proposal into this one in the next 12-36hrs. @wilkinsona are you ok w/ me combining #25758 into here? |
The code in #25758 in its current form needs to be reworked as the additions have been made in |
Yep I saw that as well. Sorry for the lack of clarification @wilkinsona - I did not mean literally "merge" - but rather bring the code into this MR. Sounds good. I will do this in the 24-36hrs. |
} | ||
|
||
@ConditionalOnClass(MongoMetricsConnectionPoolListener.class) | ||
@ConditionalOnProperty(name = "management.metrics.mongo.connectionpoollistener.enabled", havingValue = "true", |
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.
@wilkinsona it is a bit hard to not split connectionpoolllistener
with hyphens in this case. I resisted the urge though.
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.
Yeah, that's a pretty painful property name. I think we could improve the situation by keeping the fact that there's a listener involved as a lower-level detail and not exposing it in the property name. How about one of the following:
management.metrics.mongo.connectionpool
management.metrics.mongo.connection
management.metrics.mongo.pool
Given the naming used in Micrometer, I'm leaning towards 1.
* `mongodb.driver.pool.checkedout` that reports the count of connections that are currently in use | ||
* `mongodb.driver.pool.waitqueuesize` that reports the current size of the wait queue for a connection from the pool | ||
|
||
NOTE: The `waitqueuesize` metric was https://github.com/mongodb/specifications/blob/master/source/connection-monitoring-and-pooling/connection-monitoring-and-pooling.rst#why-are-waitqueuesize-and-waitqueuemultiple-deprecated[removed] in MongoDB 4.x |
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.
@jonatan-ivanov I went ahead and added the info about the waitqueuesize
deprecation here as well.
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.
The documentation that's linked to here doesn't seem to be directly related to the metric. The documentation is talking about the removal of a configuration setting rather than a metric for observing the current wait queue size. Given that Micrometer's MongoMetricsConnectionPoolListener
provides the metric without any reliance of Mongo Driver APIs, I don't think there's any need to mention the deprecation here.
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.
Fair enough. Ideally those docs would live in Micrometer anyways and at best this would just point to their docs. I will remove.
@ConditionalOnClass(MongoMetricsConnectionPoolListener.class) | ||
@ConditionalOnProperty(name = "management.metrics.mongo.connectionpoollistener.enabled", havingValue = "true", | ||
matchIfMissing = true) | ||
static class MongoMetricsConnectionPoolListenerConfiguration { |
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.
Basically everything in this nested config class was shift/lift from @jonatan-ivanov MR. Jonatan, I did not carry over the customizers concept as adding all listeners to the client settings is a more general Mongo auto-config feature and not needed specifically for the metric listeners. I could see that we may want to add that later though.
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.
Perhaps this should be called MongoConnectionPoolMetricsConfiguration
?
…ion-metadata.json
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.
Thanks again, @Bono007. I've left a few comments for you consideration.
I've also opened micrometer-metrics/micrometer#2541 which may have an effect on this changes. This is just FYI at the moment. If the Micrometer team adopt my suggestion, we can make any updates in Boot at that time.
* `mongodb.driver.pool.checkedout` that reports the count of connections that are currently in use | ||
* `mongodb.driver.pool.waitqueuesize` that reports the current size of the wait queue for a connection from the pool | ||
|
||
NOTE: The `waitqueuesize` metric was https://github.com/mongodb/specifications/blob/master/source/connection-monitoring-and-pooling/connection-monitoring-and-pooling.rst#why-are-waitqueuesize-and-waitqueuemultiple-deprecated[removed] in MongoDB 4.x |
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.
The documentation that's linked to here doesn't seem to be directly related to the metric. The documentation is talking about the removal of a configuration setting rather than a metric for observing the current wait queue size. Given that Micrometer's MongoMetricsConnectionPoolListener
provides the metric without any reliance of Mongo Driver APIs, I don't think there's any need to mention the deprecation here.
} | ||
|
||
@ConditionalOnClass(MongoMetricsConnectionPoolListener.class) | ||
@ConditionalOnProperty(name = "management.metrics.mongo.connectionpoollistener.enabled", havingValue = "true", |
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.
Yeah, that's a pretty painful property name. I think we could improve the situation by keeping the fact that there's a listener involved as a lower-level detail and not exposing it in the property name. How about one of the following:
management.metrics.mongo.connectionpool
management.metrics.mongo.connection
management.metrics.mongo.pool
Given the naming used in Micrometer, I'm leaning towards 1.
public class MongoMetricsAutoConfiguration { | ||
|
||
@ConditionalOnClass(MongoMetricsCommandListener.class) | ||
@ConditionalOnProperty(name = "management.metrics.mongo.commandlistener.enabled", havingValue = "true", |
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 don't think we need listener
in the name of this property. How about management.metrics.mongo.command.enabled
instead?
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.
[APPLY_THIS_TO_ALL_NAMING_COMMENTS]
@wilkinsona I agree that dropping the "listener" from all the naming things makes it much better and will follow up w/ that sometime today.
@ConditionalOnClass(MongoMetricsCommandListener.class) | ||
@ConditionalOnProperty(name = "management.metrics.mongo.command-listener.enabled", havingValue = "true", | ||
matchIfMissing = true) | ||
static class MongoMetricsCommandListenerConfiguration { |
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.
Perhaps this should be called MongoCommandMetricsConfiguration
?
@ConditionalOnClass(MongoMetricsConnectionPoolListener.class) | ||
@ConditionalOnProperty(name = "management.metrics.mongo.connectionpoollistener.enabled", havingValue = "true", | ||
matchIfMissing = true) | ||
static class MongoMetricsConnectionPoolListenerConfiguration { |
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.
Perhaps this should be called MongoConnectionPoolMetricsConfiguration
?
Oh man, that was me. I created these and while I did see the other tags provider I failed to snap to the naming not containing "Metrics". Uggh, naming. :) I will submit a proposal for these changes in Micrometer. |
I made the suggested naming changes and yanked the link to the Mongo docs @wilkinsona . I like it much better. Please take a scan when you can. Thanks. |
@@ -0,0 +1,108 @@ | |||
/* | |||
* Copyright 2012-2020 the original author or authors. |
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.
* Copyright 2012-2020 the original author or authors. | |
* Copyright 2020-2021 the original author or authors. |
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.
2012-2021
is correct here.
@Configuration(proxyBeanMethods = false) | ||
@AutoConfigureBefore(MongoAutoConfiguration.class) | ||
@AutoConfigureAfter({ MetricsAutoConfiguration.class, CompositeMeterRegistryAutoConfiguration.class }) | ||
@ConditionalOnClass(MongoClientSettings.class) |
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.
Is the MongoClient
available here, so that we could do @ConditionalOnClass(MongoClient.class)
instead?
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.
...va/org/springframework/boot/actuate/autoconfigure/metrics/MongoMetricsAutoConfiguration.java
Show resolved
Hide resolved
@@ -0,0 +1,200 @@ | |||
/* | |||
* Copyright 2012-2020 the original author or authors. |
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.
* Copyright 2012-2020 the original author or authors. | |
* Copyright 2020-2021 the original author or authors. |
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.
2012-2021
is correct here.
fyi: the tags providers were renamed, they are available in the snapshot: https://github.com/micrometer-metrics/micrometer/pull/2548/files |
Thanks again for the PR, @Bono007. I've merged the proposed changes along with a small polishing commit. |
The current mechanism to enable Micrometer metrics for Mongo is to add the MongoMetricsCommandListener to the MongoClientSettings.Builder. This code proposal simply auto-configures in this command listener when appropriate.
ℹ️ There is also a MongoMetricsConnectionPoolListener that would add more Mongo (connection pool) metrics. However, I left it out because it has a dependency on legacy
com.mongodb.MongoClient
as well as some Mongo event classes that were removed in Mongo 4 Java driver. I am planning on submitting a fix to Micrometer to bring it up to speed w/ Mongo 4 driver. Once that is available, I will circle back here and auto-configure it in.