-
Notifications
You must be signed in to change notification settings - Fork 667
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
chore: log if metrics_endpoint but no feature flag #5279
base: develop
Are you sure you want to change the base?
Conversation
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.
Lgtm
Nice, now that @wileyj updated the test runner to use the |
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.
LGTM!
simple_neon_integration test seems to be broken and I think by this...it is complaining I think about a metrics response not existing as expected. |
@@ -1500,19 +1500,16 @@ fn simple_neon_integration() { | |||
// query for prometheus metrics | |||
#[cfg(feature = "monitoring_prom")] | |||
{ | |||
wait_for(10, || { |
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.
Pretty sure this wait_for
was there for a reason. Maybe it's because the thread that runs the metrics hasn't started by the time this function is called?
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.
This applies to all the other wait_for
s below, 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.
Yeah, I don't remember my exact thought process, but Jacinta recently had added the wait_for
s when fixing these in a different PR. I may have just removed them from a bad merge. I've added them back.
It's not that the metrics server hasn't started, but the metric itself isn't updated until somewhere down the relayer stack, and I believe that's why the metric isn't updated "immediately".
When calling
start_server_monitoring_metrics
, there is an inverse feature flag (not(features = "monitoring_prom")
) and log if you've setmetrics_endpoint
but don't have--feature monitoring_prom
. This is helpful in the case that you're trying to setup monitoring, and added the config field, but didn't add the feature flag.This log wasn't getting shown because
start_server_monitoring_metrics
was itself behind a feature flag, so the log never showed up. This PR changes this to always callstart_server_monitoring_metrics
- it's still a no-op (with just the log mentioned) if the feature flag isn't provided.