-
Notifications
You must be signed in to change notification settings - Fork 40
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
The path
tag on HTTP server request metrics moved from using path()
to uri()
(from the HTTP request).
#225
Comments
I have a feeling ... I see that in the same commit you moved from |
Hi @ppatierno cc @vietj if you have anything to add |
Hi @jotak, first of all thanks for your fast reply.
Yeah I saw that change, and tbh I didn't understand the purpose of moving from
Well tbh it could be considered ok in terms of breaking API but here we are breaking the meaning of a tag referring to an HTTP concept which is the path. It's the resource path, it should not contain host or query string. So even if breaking changes were allowed, this one has more bad implications than just breaking API. Also can you imagine the magnitude of metrics generated this way? The same calls to the same resource path but having different values for query parameters are accumulated as separated metrics. Usually query parameters don't make any good difference, most of the times you are interested in the called resource path as it was working well in Vert.x 3.x. I am interested to know what @vietj thinks about that, but right now I see a bad outcome for the Vert.x users leveraging the HTTP server metrics. On our side we made a mistake not noticing that since long time :-( |
@ppatierno I'm not involved in vert.x metrics anymore and I might be off / but as far as I remember, this label is not enabled by default, or is it? If it's enabled by default, it should certainly be changed. cf doc here: https://vertx.tk/docs/vertx-micrometer-metrics/js/#_labels_and_matchers :
So what you say about cardinality is true, but is clearly stated in the doc, and I hope that risky path is disabled by default. It makes sense to turn this label on in non-public facing api if you know that values will be bounded. In the opposite case, iirc the custom tag provider would be the way to go, like you mentioned above. There's also an example in the doc (look under "Using Micrometer’s MeterFilter") that might be what you want. I agree that this particular point was handled in a more straightforward way in vert.x 3, and unfortunately I don't remember all the context, probably @vietj could, but I'm pretty sure there was a good rationale for doing that API change which made the trade-off worth it. |
Yes
Well this makes the label almost useless if restrict to some specific use cases. The bigger problem of the high cardinality now is related to the query string, how many parameters you can have and how many possible values for them. As said, it makes the My gut feeling is that the first implementation was right by using the Let's wait for @vietj, maybe something is still possible to revert the original meaning back. |
I'm pretty sure you can keep using |
Right now our workaround was applying a custom tags provider overriding the path this way .setServerRequestTagsProvider(req -> {
String path = null;
if (req instanceof Http1xServerRequest) {
path = ((Http1xServerRequest) req).path();
} else if (req instanceof Http2ServerRequest) {
path = ((Http2ServerRequest) req).path();
}
return path != null ? List.of(Tag.of(Label.HTTP_PATH.toString(), path)) : List.of();
}); but maybe |
I guess something around using |
@vietj any news? We should move forward on our Strimzi bridge project and make a decision related to ... your decision here :-) If it's not going to be fixed in Vert.x we need to apply a workaround on our side. |
@ppatierno I'ill have a loop asap |
I think vertx-micrometer-metrics should extract the path from the value returned by |
Just to be sure, it sounds to me that vertx-micrometer-metrics needs a fix then. Does this component have a maintainer to ask for it? |
@ppatierno yes it needs a fix indeed, there is no official maintainer atm, @tsegismont and myself are taking care of it |
I scoped this issue to the next 4.5.x release @ppatierno |
@vietj @tsegismont thank you very much for taking care of this! |
See vert-x3#225 Signed-off-by: Thomas Segismont <[email protected]>
@vietj @ppatierno I've sent #240 @vietj if we backport this to I believe it's acceptable given this tag is disabled by default and there's a workaround for users who want the current behavior (which, again, is not consistent). |
in 4.x can't we have both tags @tsegismont |
It's just one tag: Are you suggesting to create a separate tag in |
I would agree on just documenting it as a breaking change. In the end, it's a fix on a bug because the |
Hey @ppatierno @vietj has approved the PR for |
See #225 Signed-off-by: Thomas Segismont <[email protected]>
@tsegismont that's a great news! Thank you very much for fixing this! When 4.5.11 is out I will let you know if our part will come back work again :-) |
See vert-x3#225 Signed-off-by: Thomas Segismont <[email protected]>
See #225 Signed-off-by: Thomas Segismont <[email protected]>
Fixed by #242 |
Hi,
we use the Vert.x micrometer metrics component with our Strimzi HTTP bridge in order to get (out of box) metrics around HTTP server related metrics.
We noticed this issue strimzi/strimzi-kafka-bridge#921 and as you can see from my last comment there, it seems that it was a change in Vert.x long time ago we didn't notice.
The current
path
tag on the HTTP server request metrics is using therequest.uri()
since Vert.x 4.0.0, while it was usingrequest.path()
before. This implies that the tag contains the full URI with the host address and also the query string while what we expect is just the HTTP path as it was before.Is there any specific reasons why it was changed this way (because it's also broken our dashboards).
I could already have a workaround by using a custom tag provider to set the
path
tag as we expect to revert back the old behaviour but I am curious about the rationale behind that change.The text was updated successfully, but these errors were encountered: