-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Cumulative gauge/counter metric #1340
Comments
Because this "new" metric will behave exactly like a Also, given the current real-time metrics architecture of k6, either option is going to be somewhat complicated to implement. We currently output metrics to external outputs before k6 itself has processed them internally, so we'd need to seriously refactor things if we ever want this (i.e. #1075 becomes even more complicated). |
Hm... how would this work with distributed execution ? |
Exactly in the same way that a |
This aligns with the definition of cumulative Sums from otels' spec. Whcih we will need to match with our current Counters it either way ... it seems. Relevant for #2557 |
Following the discussion in https://community.k6.io/t/is-it-possible-to-create-bespoke-metrics-to-track-system-state/446, I think a new metric deserves consideration.
We should do some research on how other metrics libraries handle this, and as I said in the community forum, there are workarounds, but I can see the value of having something like a cumulative gauge metric. It will behave like a gauge/counter, keeping only the last value, but adding values to it won't replace the previous value, rather it will add to it, like a
Counter
. However, most importantly, when it's emitted to external outputs, k6 will emit the new cumulative value, not just the delta, very much unlike aCounter
.For example, if I run this script with
k6 run --out json
:we should get something like this:
and the
cumulative_guage
value in the end-of-test summary should be6
The text was updated successfully, but these errors were encountered: