You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So from the k6's metrics engine, we get either the 0 or 1, and inside the open telemetry output extension, we split this into two metrics:
metric_name.occurred
metric_name.total
where the metric_name.occurred registers only under the condition that the value was non-zero
This approach has an obvious downside: it could produce a case where metric_name.occurred could not be produced at all.
For instance, if we run an example script with a demo dashboard after navigation to the Checks list panel, we quickly spot that protocol is HTTP/2 is missing.
So we need to think about how we can handle this more efficiently.
What?
k6's
Rate
metric tracks how frequently a non-zero value occurs.So from the k6's metrics engine, we get either the
0
or1
, and inside the open telemetry output extension, we split this into two metrics:metric_name.occurred
metric_name.total
where the
metric_name.occurred
registers only under the condition that the value was non-zeroThis approach has an obvious downside: it could produce a case where
metric_name.occurred
could not be produced at all.For instance, if we run an example script with a demo dashboard after navigation to the
Checks list
panel, we quickly spot thatprotocol is HTTP/2
is missing.So we need to think about how we can handle this more efficiently.
Possible Options
Always start metric with the
0
valueOne of the possible approaches suggested by @joanlopez and was used inside grafana
TBD
Why?
Handling of the Rate metric should be transparent and cover all possible cases.
The text was updated successfully, but these errors were encountered: