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.
Possible Options
Always start metric with the 0 value
One 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.
What?
k6's
Ratemetric tracks how frequently a non-zero value occurs.So from the k6's metrics engine, we get either the
0or1, and inside the open telemetry output extension, we split this into two metrics:metric_name.occurredmetric_name.totalwhere the
metric_name.occurredregisters only under the condition that the value was non-zeroThis approach has an obvious downside: it could produce a case where
metric_name.occurredcould not be produced at all.For instance, if we run an example script with a demo dashboard after navigation to the
Checks listpanel, we quickly spot thatprotocol is HTTP/2is missing.So we need to think about how we can handle this more efficiently.
Possible Options
Always start metric with the
0valueOne 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.