Skip to content
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

Refactor the collectors/outputs #1075

Closed
na-- opened this issue Jul 9, 2019 · 2 comments · Fixed by #1869
Closed

Refactor the collectors/outputs #1075

na-- opened this issue Jul 9, 2019 · 2 comments · Fixed by #1869
Assignees
Labels
enhancement evaluation needed proposal needs to be validated or tested before fully implementing it in k6 refactor
Milestone

Comments

@na--
Copy link
Member

na-- commented Jul 9, 2019

It's becoming clear that the current Collector interface isn't very fit for purpose. It is a poor fit for a lot of the outputs ([1], [2], [3.1], [3.2], [4], [5]), it leads to some code duplication and makes correctly writing new thread-safe outputs relatively difficult, and it also doesn't offer enough functionality for more complicated outputs (#1074). The same thing even has multiple names - what we call Collectors in the code live in the stats folder and are presented as "outputs" to users...

Additionally, the thresholds and the end-of-test summary are basically somewhat special-purpose outputs... They ingest metrics and do some calculations on them - the summary just spews the aggregated results at the end of the test, while thresholds do some calculations and potentially abort the test execution... They are enabled by default, but can be disabled by users. I'm not sure if it makes sense to refactor them into outputs for just a marginal improvement of code quality, but it should at least be investigated...

I think that when we're investigating the telegraf integration (#1064), we should also investigate their output pipeline architecture. Since their main job is dealing with metrics, there are probably things we can learn from them...

Other somewhat related issues: #917, #570, #587, #1001, #743, #572, #355, #351

@na--
Copy link
Member Author

na-- commented Aug 25, 2020

For completeness' sake, other reasons to refactor the current interface and architecture of outputss: #1606 and #1423

@na--
Copy link
Member Author

na-- commented Nov 26, 2020

Another reason to refactor the output interface is that the k6 outputs currently don't whether the test run finished successfully, and if not, what was the error. This is preventing us from being able to send the error (e.g. an exception in setup() or teardown()) to outputs that will be able to understand and record it (e.g. the cloud).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement evaluation needed proposal needs to be validated or tested before fully implementing it in k6 refactor
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant