K6: Tag metrics from different stages

[na--]

Reading through this issue, I liked the idea of automatically tagging the metrics from different stages, I think it could be useful when analyzing the results later.

Also, instead (or in addition) of those system tags, we might want to add the option of users to add their own key=value tags to the stages, like they currently can do whole test runs or with individual metrics. Though this option would probably have to be part of the new configuration mechanism that would be required for the arrival-rate based executor

[ppcano]

@na-- I had today the same idea when observing different ramp-up configurations and thinking how to analyze their test results.

The API could look like:

stages: [
    { duration: "30s", target: 200, tag: 'ramp-up' },
    { duration: "5m", target: 200, tag: 'baseline' },
    { duration: "30s", target: 0,  tag: 'ramp-down' }
  ],

Metrics/Data would be tagged as: stages:ramp-up, stages:baseline, stages:ramp-down.
Today, the same problem can be solved by filtering by time.

cc @robingustafsson

[na--]

Something like this would have to wait for #1007, but it shouldn't be too difficult...

[na--]

Cross-posting to note another use case for this feature, related to setting thresholds only for specific stages: https://github.com/loadimpact/k6/issues/1136#issuecomment-557488687

[joseray]

@ppcano this is already implemented?

[na--]

@joseray, no, it's not yet implemented. You can watch this issue, since we'll close it when we implemet the feature.

[na--]

This issue would be useful, though I think it's best if we focus our energies on other similar ones that are more flexible. If we had https://github.com/loadimpact/k6/issues/1320, i.e. be able to get the number of the current stage for ramping-vus and ramping-arrival-rate, we'd be able to manually tag metrics we care about or use a group() with the stage name.

And, depending on how we choose to implement https://github.com/loadimpact/k6/issues/884, https://github.com/loadimpact/k6/issues/1724 and https://github.com/loadimpact/k6/issues/1321, we'd get much more flexible tagging as well... I'm not going to close this issue, but I'll tag it as evaluation needed, since at this point it seems unlikely we'll implement it as is. And even if we implement it (a name for each stage seems a good idea to have in the config from a UX perspective), the implementation is likely to just be a shortcut based on the code for the issues I listed above.