Add UI for altering logging log levels

[josh-griffin]

Is your feature request related to a problem? Please describe.

Added a feature in #4189 for logging. Would be good to have a way to change log levels during runtime on a device.

Describe the solution you'd like

• A UI somewhere in the SettingsPage to change the log levels of different loggers
• A way to persistently store the current log levels

Implementation

• I am not sure I need to think about it 🙃

Describe alternatives you've considered

Do nothing, see how it goes

Additional context

Add any other context or screenshots about the feature request here.

[wlthomson]

Might be using different terminology, but how I conceptualise it!

Have multiple log levels, e.g. error, debug, info etc.

A Logger is an interface which exposes these methods, e.g. logger.info("some info"), for example you may want to log to console or upstream to bugsnag (so you'll have two different classes for this, both which implement Logger).

Since all loggers expose all log levels as methods, I'm not sure what it means to change their log levels at run time?

It sounds like maybe the idea is to adjust the verbosity of the logging at runtime, e.g. by default in production you might only log error, but sometimes you may want to log debug or info while trying to hunt down a bug? I can see that being useful, but more in terms of the app environment rather than specific loggers? I guess I'm not sure how different loggers can have different levels if the level is defined by the method that is called in the code (e.g. info vs. debug)?

[wlthomson]

Following up from above, maybe a stupid question: could we always log the maximum verbosity and filter/prune as needed? E.g. if logging to console, can redirect stdout to dev/null if only want to see stderr. If logging to a file, the file would get big pretty quick, but maybe could redirect stdout and stderr to different files, and have a set parameter of how big the file can get before it starts writing over old logs?

This admittedly doesn't give you as much flexibility as filtering on log level directly, but I think that could be done with pattern matching/grepping (either on the file or on the output stream in the console)?

[josh-griffin]

It sounds like maybe the idea is to adjust the verbosity of the logging at runtime, e.g. by default in production you might only log error, but sometimes you may want to log debug or info while trying to hunt down a bug?

Yup.

I guess I'm not sure how different loggers can have different levels if the level is defined by the method that is called in the code (e.g. info vs. debug)?

Each logger has a log level. I.e. info. If any invocations on that logger are below that level [i.e. a call like logger.trace()] there is no log actually created, it is essentially ignored. the idea being that we can have a logger which has many debug calls and fewer info calls, and adjust the log level if required.

Following up from above, maybe a stupid question: could we always log the maximum verbosity and filter/prune as needed?

I would be interested in exploring this if we were logging on a server. However on a users device (and generally, pretty low-specced device) I don't think this is practical.

[wlthomson]

Each logger has a log level. I.e. info. If any invocations on that logger are below that level [i.e. a call like logger.trace()] there is no log actually created, it is essentially ignored. the idea being that we can have a logger which has many debug calls and fewer info calls, and adjust the log level if required.

Yup, that makes sense and I think is the same as what I was saying with

It sounds like maybe the idea is to adjust the verbosity of the logging at runtime, e.g. by default in production you might only log error, but sometimes you may want to log debug or info while trying to hunt down a bug? I can see that being useful, but more in terms of the app environment rather than specific loggers?

I think I can see the answer to this question now, e.g. maybe you want to log verbosely to file but not to bugsnag?

I guess my only 2c re the UI would be to make sure that its not solving a problem that doesnt exist, e.g. is the problem specific to having low memory space and in some circumstances wanting to increase your log verbosity to file (e.g. would a switch for "debug mode" or something suffice), or are there other use-cases where you'll need to change logging verbosity per logger at run time?

[kat-ms]

Just chiming in with my thoughts (1c?) - I think separate levels per logger could be useful if you knew where a problem was (e.g. Bluetooth being super flakey) and wanted to collect in-depth debug logs in a particular area only without having to trawl through lots of unrelated noise.

I guess another way around it for file logging would be to have separate files for the different loggers so unrelated areas didn't clog up a single file 🤷 but I dunnooo this is only 1 cent, need more 💰