-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Feature: Expose a request path label in the http_request_*
metric by default
#491
Comments
Yeah, this would be pretty straight-forward to add. IIRC, when implementing the middlewares, we were concerned that it's very easy to create cardinality explosions. @stuartnelson3 do you remember any of such concerns? |
That was our concern. Some users could be putting user IDs or some other non-bounded set of data in the path, so we decided to avoid potentially destroying our users' prometheus servers. |
@stuartnelson3 and i discussed this over lunch. Most importantly, my memory served my right: Back then, we deliberately did not include this feature. We indeed had the concerns mentioned above. In particular, the requested feature only makes sense with handlers that handle multiple paths. (If a handler only handles one path, you can curry the metric vector with a Or in yet other words: The convenience middlewares in Thus, I'm on the fence if that feature would be a net gain. |
Agree with the potential behaviour of having URLs - URL fuzzing by some common pentesting tools might cause this too. However, (correct me if i'm wrong, but) I believe this can be mitigated during the metrics extraction from Prometheus to a dashboard (Grafana in our case) via promql? For example in our setup, we are monitoring the duration and status codes by endpoints which we've identified as critical for the business front-end. The exact endpoints tend to change based on business direction and it's useful for us to have a path label so that the monitoring and code is de-coupled. But to summarise, I think you might be recommending that this be a third party instrumentation package instead of being in the core code? I noticed that such functionality is also not included in the core of the NodeJS but as a |
Prometheus itself would suffer. The TSDB of Prometheus has a very low price per sample (usually between one and two bytes) but a much much higher price per serios (kilobytes). Thus, your server would explode. I'm not suggesting to use a 3rd party package. All the tools you need are included in client_golang. You should just not use the convenience-middlewares but the usual instrumentation primitives as described in the linked video. |
cool, thanks for the advice on the potential effects on tsdb @beorn7! I gave it a watch and have managed to get up my own middleware to do something like what I was requesting for, am closing this- but if anyone else is looking for such a convenience middleware despite the above warnings, I've published it at https://github.com/zephinzer/ezpromhttp! |
**What this PR does / why we need it**: This PR aims to expose two metrics about HTTP handler: - `pipecd_http_requests_total` - `pipecd_http_request_duration_milliseconds` To do that, it mainly does these two: - add an HTTP middleware to track metrics - make a new package `httpapi` to put all HTTP handlers on the same package so that they can be wrapped by the middleware easily Notes: - As mentioned in the file, `pkg/app/api/httpapi/metricsmiddleware/delegator.go` is entirely borrowed from `prometheus/client_golang`. - The most core part in this PR is `pkg/app/api/httpapi/httpapi.go` - I've carefully checked the HTTP handlers work well as before and all metrics we expect got exposed. (Supplement) `client_golang/promhttp` doesn't add a label for HTTP path to prevent Prometheus's TSDB from high-cardinarity. See prometheus/client_golang#491 for more details. **Which issue(s) this PR fixes**: Fixes # **Does this PR introduce a user-facing change?**: <!-- If no, just write "NONE" in the release-note block below. --> ```release-note NONE ``` This PR was merged by Kapetanios.
I have a case, when to provide request path as a label is enough useful: gRPC Gateway server which is registered by |
Currently, metrics are exposed as:
I would like to add on to this by also allowing for a
path
label to be added so that each route does not need to be manually instrumented with a handler name. I'm proposing that the default collection should result in:This could be done by adding
r.URL.Path
to the labels creation as apath
label.I'm new to Golang but would be happy to attempt this with some guidance!
Any opinions?
The text was updated successfully, but these errors were encountered: