Multiple log outputs

[codebien]

Feature Description

It could be useful to declare multiple log outputs at the same time for k6 run and cloud commands.

k6 run --logformat json \
    --log-output file=./k6run.log \
    --log-output loki=http://127.0.0.1:3100/loki/api/v1/push \
    ./samples/http_get.js

or a more advanced example

k6 run --verbose \
    --log-output "stdout,level=info" \
    --log-output "file=all.log,level=debug" \
    --log-output "loki=http://whatever,level=warn" \
    ./samples/http_get.js

Logformat

It could include the additional features for making more fine-grained logformat configuration considering that at the moment logformat can be only defined at the global layer.

• a per-output logformat option for a fine-grained definition of the format for the specific output

An example with the previous advanced example:

k6 run --verbose \
    --log-output "stdout,level=info,format=raw" \
    --log-output "file=all.log,level=debug,format=json" \
    --log-output "loki=http://whatever,level=warn,format=json" \
    ./samples/http_get.js

Cloud

The cloud supports the log-output option and it shouldn't be confused as did during an internal discussion with show logs option.

k6 has its own debug log messages that are not driven from the script console.log(), just run k6 run --verbose or k6 cloud --verbose with a script without any console.log() calls and you'll see them.

so the following example is still a valid case:

k6 cloud --verbose --log-output "file=debug.log" --show-logs=false script.js

Already existing or connected issues / PRs (optional)

• Add support for local files to --log-output #2249
• Deprecate and/or rename the --show-logs option in k6 cloud #2288
• Log output as xk6 extension #1939
• Switch log library to Zap #216

[na--]

This and #1939 should be much easier to do after #2412 (and its connected PRs). It wasn't all that difficult before, to be fair, but now we should actually be able to test it easily and reliably.

Also, somewhat connected to #2414 (comment), we should slightly refactor how k6 waits for logs to be done... Though a WaitGroup will probably be better than a channel for multiple logs...