output/influxdb: Counter aggregation

[michaelgrahamevans]

Brief summary

When using the InfluxDB output back end, the value added to custom counter metrics is sent to InfluxDB instead of the current, accumulated value of the counter. This behaviour makes the counter metric type the same as the gauge metric type in InfluxDB (see steps and graph below) which makes me think this is a bug.

k6 version

0.35.0

OS

Linux

Docker version and image (if applicable)

loadimpact/k6:0.35.0

Steps to reproduce the problem

1. Start an InfluxDB server

2. Run the following script with k6 run --iterations=10 --out=influxdb=http://localhost:8086 count.js

   import { sleep } from "k6";
   import { Counter, Gauge } from "k6/metrics";
   
   const counter = new Counter("my_counter");
   const gauge = new Gauge("my_gauge");
   
   export default () => {
     for (let i = 0; i < 10; i++) {
       counter.add(i);
       gauge.add(i);
       sleep(1);
     }
   }

3. Query the data with the following queries

   SELECT "value" FROM "k6"."autogen"."my_counter" WHERE time > now() - 5m
   SELECT "value" FROM "k6"."autogen"."my_gauge" WHERE time > now() - 5m
   

Expected behaviour

The database should contain the values 1, 3, 6, 10, 15, ... for the counter metric.

Actual behaviour

The database contains the values 1, 2, 3, 4, 5, ... for the counter metric, which is the same as the gauge metric.

[michaelgrahamevans]

This together with values sometimes not being written to InfluxDB, as described by #636, means that it is difficult to get an accurate value of the counter this way even when summing the values recorded in the database. Sending the accumulated value to InfluxDB instead could mitigate this.

[codebien]

Hi @michaelgrahamevans,
unfortunately, at the moment, this is not expected to be supported. I see that something could be misleading so I opened an issue in our documentation's repo for adding some clarification about it.
As you can see running the same script using the JSON output (k6 run -i 10 -o json count.js), it just gets a stream with raw samples.
Doing it efficiently without adding too much complexity is not possible with the current metrics system. #1831 will improve the situation then this and other features will be easier to do.

Once we will have it, we could consider adding an option for emitting aggregated metrics from the InfluxDB output.

[na--]

Somewhat related old issue: #1340