fix: pprof debug endpoints not working with --web.route-prefix#4698
Merged
SuperQ merged 5 commits intoprometheus:mainfrom Dec 3, 2025
Merged
Conversation
ea08ffa to
c77837c
Compare
siavashs
reviewed
Nov 5, 2025
c77837c to
fba85a3
Compare
When using --web.route-prefix or --web.external-url with a path component, the pprof debug endpoints were not accessible. The handlers were directly passing requests to http.DefaultServeMux without adjusting the URL path to match what the pprof handlers expect. For example, with --web.route-prefix=/prometheus/alertmanager, a request to /prometheus/alertmanager/debug/pprof/ was being forwarded with the full path intact, but http.DefaultServeMux only has handlers registered for paths starting with /debug/pprof/. This fix reconstructs the request path by extracting the subpath parameter from the route and prepending /debug to it, ensuring the path matches what http.DefaultServeMux expects. The fix also preserves trailing slashes which are required by some pprof handlers. Added unit tests to verify pprof endpoints work correctly both with and without route prefix configuration. Co-authored-by: Claude <noreply@anthropic.com> Signed-off-by: Will Hegedus <whegedus@akamai.com>
fba85a3 to
45851d9
Compare
siavashs
reviewed
Nov 13, 2025
Co-authored-by: Siavash Safi <git@hosted.run> Signed-off-by: Will Hegedus <whegedus@akamai.com>
Signed-off-by: Will Hegedus <whegedus@akamai.com>
e50f8a3 to
81053db
Compare
siavashs
reviewed
Nov 13, 2025
Updated based on PR comments to conform with existing testing patterns Signed-off-by: Will Hegedus <whegedus@akamai.com>
6e16897 to
b1f68ca
Compare
siavashs
reviewed
Nov 17, 2025
ui/web_test.go
Outdated
| router.ServeHTTP(w, req) | ||
|
|
||
| require.Equal(t, http.StatusOK, w.Code) | ||
| require.NotEqual(t, 0, w.Body.Len()) |
Contributor
There was a problem hiding this comment.
Suggested change
| require.NotEqual(t, 0, w.Body.Len()) | |
| require.Positive(t, w.Body.Len(), "body should not be empty") |
Alternatively we could replace the checks with https://pkg.go.dev/github.com/stretchr/testify/require#Assertions.HTTPBodyContains
but feel free to skip it.
Contributor
There was a problem hiding this comment.
But I think HTTPBodyContains might not be suitable here, it is best for custom handlers and not a router.
Contributor
Author
There was a problem hiding this comment.
Updated in 7317f2d to use require.Contains() for checking the body, since -- as you said -- HTTPBodyContains would've required having access to the handlerFunc to pass to the test case.
Signed-off-by: Will Hegedus <will@wbhegedus.me>
8e7f650 to
7317f2d
Compare
siavashs
approved these changes
Nov 27, 2025
Contributor
siavashs
left a comment
There was a problem hiding this comment.
LGTM, Thank you for your contribution!
Contributor
|
@SuperQ we can merge this one. |
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When using
--web.route-prefixor--web.external-urlwith a path component, the pprof debug endpoints were not accessible. The handlers were directly passing requests to http.DefaultServeMux without adjusting the URL path to match what the automatic pprof handlers expect.For example, with
--web.route-prefix=/prometheus/alertmanager, a request to/prometheus/alertmanager/debug/pprof/was being forwarded with the full path intact, but http.DefaultServeMux only has handlers registered for paths starting with/debug/pprof/.This fix reconstructs the request path by extracting the subpath parameter from the route and prepending /debug to it, ensuring the path matches what http.DefaultServeMux expects. The fix also preserves trailing slashes, which are required by some pprof handlers.
Added tests to verify pprof endpoints work correctly both with and without route prefix configuration.