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
Add http active requests gauge metric #29242
Add http active requests gauge metric #29242
Conversation
/cc @ebullient |
bd33397
to
a6f42c6
Compare
This comment has been minimized.
This comment has been minimized.
Thanks @cescoffier . Not sure why these tests failed.
|
On the fence about this as a gauge or as a long task timer (which includes a count of active requests): https://github.com/micrometer-metrics/micrometer-docs/blob/main/src/docs/concepts/long-task-timers.adoc |
A long task time wouldn't work for my use case. Long Task Timer aren't really Open Metrics compatible. It's why the vertx binder works well, it's a simple gauge. |
I was originally replacing this binder with the original one but this PR broke that on 4.3.4 I'd rather not keep hacking Quarkus to get those metrics. Also, it's my understanding that the current metrics are timers already. I'm not sure what making active requests as timers would add to what we have now. The question I'd like to answer is: How many active requests are open right now? |
Quarkus uses Vert.x, but is not Vert.x. For a lot of reasons, Quarkus does not use the vertx micrometer instrumentation (from Vert.x 3.0). So "hacking Quarkus to get those metrics" is what you need to do if you want those metrics from Quarkus. They are not the same thing.
The current metrics (http.server.requests.* and http.client.requests.*) are timers. A long task timer is something else, and it does answer your question, but provides some additional information as well. I'm not sure if that extra information is also interesting. |
To expand on the sticking point for me. The long task timer's aren't openmetrics compliant. One of my providers is strict on openmetrics. It ignores |
What could be interesting is adding tags for url and method. What do you think? |
Is it because it ends with If we use a long task timer, we would use a second sample, and thread the needle identically to the Timer Sample. Note that the exact URI of the request (with templates replaced) is not known until the request is complete outside of use of a regex (deferred URI template resolution by REST containers). Existing HTTP configuration contains URI regex for constraining cardinality.. so this isn't a problem, just explaining a complication to using that information for requests in flight, rather than requests that have been completed. |
I don't believe I'm still unsure what the benefit for long task timer would be here given that the current timer metric already publish timing information. I do understand the a long timer is something else, but I'm not sure what the benefit would be here. If we were to thread the needle as you say wouldn't it end up timing the same thing that the current timer times? |
The hooks are roughly in the same place.. but what happens at start/stop is different. Long task timer is active requests, duration of longest running active request. You're right about Splitting the gauge (active requests) by URI and Method requires storing a separate LongAdder for each (I know this is what 3.x Vert.x does.. but it does it for known routes with known methods). The metric hook (request begin) is called before the request route has been completely resolved from a Resteasy perspective. While we may know the method, we won't know the templated URI w/o involvement of regex (as mentioned above) |
I see what your saying. We wouldn't be able to get path information during the Looking at the API for |
Correct. The LongAddr and the LongTaskTimer have the same constraint with regard to tags. As a funny aside.. you can get a LongTaskTimer with what you want by adding a |
How do we proceed from here? |
@@ -96,6 +103,7 @@ public void requestRouted(HttpRequestMetric requestMetric, String route) { | |||
public HttpRequestMetric requestBegin(Map<String, Object> socketMetric, HttpRequest request) { | |||
HttpRequestMetric requestMetric = new HttpRequestMetric(request); | |||
requestMetric.setSample(Timer.start(registry)); | |||
requestMetric.requestStarted(activeRequests); |
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.
activeRequests is a member variable. Can be passed to HttpRequestMetric ctor (and never be null).
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.
The idea behind making it null is to make sure we never decrement more than once. But if we're willing to trust the framework, that's fine.
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.
@ebullient added a commit adding this change.
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.
if you're worried about this case.. a simple boolean in the HttpRequest can make sure requestEnd isn't called twice.
...runtime/src/main/java/io/quarkus/micrometer/runtime/binder/vertx/VertxHttpServerMetrics.java
Show resolved
Hide resolved
4723ce1
to
c779ca7
Compare
Will let CI run .. can you squash down to one commit before merge? |
c779ca7
to
030702b
Compare
done |
This comment has been minimized.
This comment has been minimized.
Failing Jobs - Building 030702b
Full information is available in the Build summary check run. Failures⚙️ JVM Tests - JDK 11 #- Failing: integration-tests/oidc-code-flow
📦 integration-tests/oidc-code-flow✖
⚙️ JVM Tests - JDK 17 #- Failing: integration-tests/oidc-code-flow
📦 integration-tests/oidc-code-flow✖
⚙️ JVM Tests - JDK 18 #- Failing: integration-tests/oidc-code-flow
📦 integration-tests/oidc-code-flow✖
⚙️ Native Tests - Security2 #- Failing: integration-tests/oidc-code-flow
📦 integration-tests/oidc-code-flow✖
|
Thanks! |
The original Vertx micrometer metric include the gauge
vertx_http_server_active_requests
which is pretty handy. I was hoping we could add a similar gauge here.