go-metrics for metrics handling

[ivoreis]

Have you considered using go-metrics for metrics handling?
I've noticed you have a bespoke sink implementation and that's cool but go-metrics provide that, a simple way to query those metrics and would enable an easier integration with other collectors.

[liclac]

If it can be done without sacrificing performance, I'd most certainly consider a switch to it.

The reason we're using our own statistics pipeline right now is that k6 was started almost two years ago; there wasn't a mature metrics processing library available that offered the functionality we needed, and rather than being beholden to an external project for something so essential to our functionality, it made more sense to write our own with intent to extract it into a general-purpose library... which never ended up happening, as metrics processing became more and more ingrained into the "spine" of k6.

k6' stats library was actually heavily inspired by both Prometheus and go-metrics' Java predecessor, so slotting in something that uses similar concepts wouldn't be too hard (and mean a lot of code we wouldn't have to maintain in-tree anymore!).

[ivoreis]

Yeah performance is my only con and concern as well. But IMOH I think the pros outweigh the con and having less code to maintain is always a win. How do you measure performance btw?

[liclac]

It's difficult. You'd almost have to implement it, run two tests on different branches, and see if the number of iterations performed is about the same. If we lose a few % in exchange for cleaner code and an external project we can contribute to instead, then that'd be totally worth it. But if the performance impact is ~10% or higher or the measurements look skewed, then we may have to start profiling stuff and figure out why.

I really want this to work, but we can't sacrifice our ability to be competitive as a load generator even for the sake of cleaner code.

[ivoreis]

Sure, completely understandable. Thanks for the explanation.