Instrumenting follow-up: metrics labelling w/ finer granularity#1171
Conversation
|
I don't think we want to remove the overall histogram for request latencies, given the fine grained histograms it's impossible to re-assemble the broader histograms. Likewise, it's a little weird to write a query like rate(k8s_java_resource_request_latency_seconds_count{code="500"}) to get the rate of errors. I get that we might not want to have extra Counter metrics, but I feel like it makes more sense than overloading the histogram metrics. So I would retain both of the Counters and also the all-up Histogram. The rest of the additional labels LGTM. |
@brendandburns if i understand correctly, we can always aggregate finer-grained histogram/counter to overall histogram/counter by promQL functions --- generally the fine-grained metrics is a superset of overall metrics:
am i missing anything? |
|
a) I believe that the first calculation is a histogram of the average latency, not the actual latency, so it's lossy. b) The second calculation is valid, but I think it's hard for a person to understand, since why would I sum latency count to get # of requests. So while the calculation works, I think it adds complexity. |
oh oversight! i was referring to
yeah i agree the aggregation is complex and not intuitive enough, even tho they're overlapping mathematically. will keep counter and all-up histogram |
f3cf9a9 to
b2cf0a0
Compare
|
@brendandburns i added the request-counter and response-code-counter back, PTAL |
| this.name = name; | ||
| } | ||
|
|
||
| private final String apiGroup; |
There was a problem hiding this comment.
TODO: update to group/version/kind object.
There was a problem hiding this comment.
i did the TODO right now
| } | ||
|
|
||
| codes.labels(Integer.toString(response.code())).inc(); | ||
| ; |
|
One TODO for the future (unless you feel like doing it now) and one typo, then LGTM. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: brendandburns, yue9944882 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
the new classes are picked from open-telemetry/opentelemetry-java-instrumentation#651, except for those groovy unit tests..
a sample output from the prometheus example will be: