-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
.*: Apply webrouteprefix on debug and metric endpoints #4471
Conversation
e1990ff
to
41f9805
Compare
I've rerun the failed e2e test |
Thank you @wbh1 for fixing 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.
It LGTM, but I also have that feeling about "can't we do this smarter?". Still, looks good and thank you!
CHANGELOG.md
Outdated
@@ -14,6 +14,8 @@ We use *breaking :warning:* to mark changes that are not backward compatible (re | |||
|
|||
### Fixed | |||
|
|||
[#4471](https://github.com/thanos-io/thanos/pull/4471) **breaking:** Query/Rule/Compact/Store: Serve `/debug/*`, `/-/ready`, `/-/healthy`, and `/metrics` routes under the prefix from `--web.route-prefix`, if set. |
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.
Just to clarify it, let's start with **breaking** if --web.route-prefix is set: serves endpoints x,y,z now actually under the route-prefix.
WDYT?
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.
That makes sense to me. I'll update it!
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.
@wiardvanrij - updated ✅ . Thanks!
I agree that there's likely a better way to do it that involves more refactoring -- maybe with including a Lines 156 to 161 in 83419bc
|
2a4788b
to
a2fed5b
Compare
Hey @wiardvanrij - anything else that you need for this? |
No, still LGTM. I will ping others to get this reviewed/merged :) Thanks for picking this up! |
I think this makes sense. Would you be interested to write an issue for it and then perhaps implement it? I'm asking for an issue so that it can be (re)viewed before you work a lot on it. |
The code change looks good. But this is really a breaking change and might impact our users. cc @thanos-io/thanos-maintainers for review. |
Resurfacing this discussion @yeya24 😄 Could you ping again? |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Still relevant. Needs review. |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Still relevant. Needs review. |
Will take a look soon, sorry for the delay. Could you please rebase this? |
Signed-off-by: Will Hegedus <whegedus@linode.com>
Signed-off-by: Will Hegedus <whegedus@linode.com>
Signed-off-by: Will Hegedus <whegedus@linode.com>
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.
Thank you for your work! However, historically we've had many "broken" implementations of the prefix functionality. So, could you please add some test cases to TestQueryExternalPrefixWithoutReverseProxy
or some similar test that would test out these changes? Namely, we are looking to automatically test whether /metrics and /debug endpoints are successfully accessible with these changes just like we would expect.
This adds additional endpoints that were not previously behind the routePrefix to the testing suite and improves documentation of those tests. Signed-off-by: Will Hegedus <whegedus@linode.com>
This will now return errors if an HTTP error (status >= 400) is returned by the chrome driver. Additionally, the Chrome context is now modified to inherit the deadline from the running test suite. Signed-off-by: Will Hegedus <whegedus@linode.com>
Validate that the --web.route-prefix flag adjusts expected routes. Signed-off-by: Will Hegedus <whegedus@linode.com>
Thanos Compact supports the flags for webconf, but previously was not actually doing anything with them. Signed-off-by: Will Hegedus <whegedus@linode.com>
Refactors Thanos Store to use the registerFlag function to ensure it receives all flags that are applicable to webConfig. Previously, only 3/4 were manually defined. Signed-off-by: Will Hegedus <whegedus@linode.com>
Previously, routes were not getting the value of the --web.*-prefix flags applied. Signed-off-by: Will Hegedus <whegedus@linode.com>
e03c279
to
e9e8bf0
Compare
Signed-off-by: Will Hegedus <whegedus@linode.com>
Signed-off-by: Will Hegedus <whegedus@linode.com>
Signed-off-by: Will Hegedus <whegedus@linode.com>
Alright, @GiedriusS -- this should be ready for review now. I've added additional e2e testing for the components that actually support the prefix (Compact, Query, Rule, and Store), which helped catch bugs in how Store and Compact were handling route prefixes so thank you for that 😁. Unrelated to the merging of this PR, but related to the topic of it: In working on this PR, I've realized how each component largely handles the setting up of its routing configuration which makes changes like this difficult. Which leads me to want to make an effort in the future to consolidate the HTTP server/routing configuration for all components to ensure they're all consistent with the way they serve their routes. Part of this work is already done in how some components use the webConfig struct, and also the prometheus/common/route package (example in Store). This leads to a lot of repeated code (see the similarities in Rule and Query). Is this an idea that should go through the proposal process? Looking for next steps before starting any effort towards it. |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Not stale. Just need to get around to rebasing it again. |
Sorry for the delay, I was on vacation. Will take a look in a bit & respond to you |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Fixes #2727
Changes
This is a continuation of the work started by @ranjithkumar007 in #2524.
I've completed the rebase, fixed prefix handling in Thanos Store, added prefix handling logic to Thanos Compact (the flags were there but ignored, previously), and added additional testing around prefix behaviors in e2e tests.
Related issues:
Essentially, it prefixes the debug and metrics endpoints with the value of
--web.route-prefix
if available.For those like me who have Thanos components behind a reverse proxy (e.g.
https://example.com/thanos/query
) then this will break their access to some endpoints (e.g./metrics
,/-/ready
and/-/healthy
) if they hard coded around it like we did (see below).Bad:
Good:
Verification
Verified with local tests and deployment of a build to our own servers to verify that the endpoints are served as expected both with and without
--web.external-prefix
(and thereby--web.route-prefix
) being set.Additionally, added more e2e tests to verify this works as expected on the components that support setting a prefix.