Investigate log verbosity and suggest a solution

[sublibra]

Investigate how we can balance log output from different tools against cluttering the cli output.

[peol]

Logging

This is a suggestion how we should implement logging in command line tools.

Note that the commands and their output here might be fictional.

Configuration

We should be using our service logging level conventions as a base, using the same terminology as well as their definitions:
https://core.qlik.com/conventions/logging/#logging-level-definitions

One additional level could be added if we seem fit: SILENT.

The numeric mapping would be:

Level	Numeric
TRACE	6
DEBUG	5
INFO	4 (default)
WARN	3
ERROR	2
FATAL	1
SILENT	0

corectl --log-level 6 reload --app foo.qvf
LOG_LEVEL=TRACE corectl --app foo.qvf

The environment variable is useful in e.g. Circle CI to avoid modifying scripts that already runs corectl commands.

Output

The output should, at minimum, be designed for humans. This means plain english and no too cryptic log formats.

In addition, it would be useful to support logging in different formats:

Human readable

corectl reload --app foo.qvf
[06:34:35] WARN: No --app defined, will use an session app instead.
[06:34:35] INFO: Reload started.
[06:34:38] INFO: Reload successful.

JSON

This format could (with benefit) use the logging conventions JSON output, but perhaps defined as an JSON array.

corectl reload --app foo.qvf
[
  {
    "timestamp": "2018-09-27T06:34:35.455Z",
    "logseverity": "WARN",
    "message": "No --app defined, will use an session app instead."
  },
  {
    "timestamp": "2018-09-27T06:34:35.715Z",
    "logseverity": "INFO",
    "message": "Reload started."
  },
  {
    "timestamp": "2018-09-27T06:34:38.119Z",
    "logseverity": "INFO",
    "message": "Reload successful."
  }
]

[wennmo]

I have looked into adding a logging framework in corectl for logging in either plain text and json.

Since we are aiming for being able to customize the output e.g. log keys, format of timestamps and log levels there are atleast two suitable options:

• logrus
• kit/log

Switching to using either of these framework for logging standard messages (INFO, DEBUG, FATAL etc.) or json traffic from our modules seems doable in a small timeframe. I have a branch where I have started the work on using logrus here.

As I see it there is two bigger tasks that needs to be resolved/discussed before we choose either of these options:

• How should we handle Table printouts for e.g. an app list in plain text. Should this be printed direcly to stdout, through the logger or be removed? Passing it through the logger seems quite tricky with either of the options above.
• Currently we are using golden files for integration tests which means that we assert on the printouts from the tool. With a logger adding timestamps this approach can no longer be used, unless we make it the timestamp optional on e.g. a test env variable. We can also change all the test cases to only assert on specific strings in the output, but that will lead to less verification.

[wennmo]

Removing the v1 label on this issue since it is no longer in the scope of the first release.

[glooms]

I think we should revisit this issue!