Logging Levels - pd93/plog GitHub Wiki

On this page, you will find a list of all the available logging levels and their intended usage. These levels are listed in order of significance, starting with the most significant. When a LogLevel is applied to a logger, any logs of an equal or higher significance are reported to that logger.

Fatal

Fatal logging should be used to report errors that cause the execution of your program to stop. A fatal function should only ever be called once; usually in the main function. For example:

func main() {
    if err := doStuff(); err != nil {
        log.Fatal(err)
    }
}

If you need to log fatal errors to a specific logger, you can return this logger to your main function and use it there. For example:

func main() {
    if logger, err := doStuff(); err != nil {
        logger.Fatal(err)
    }
}

func doStuff() (logger *log.Logger, err error) { ... }

Error

Error logging should be used to report non-fatal error messages. Generally speaking, Go programs should return errors to the main function and report them there. However, there are occasions when this is not possible or desireable, such as in an HTTP API endpoint. If you want to report an error, but need your program to continue execution, you should call an error function.

Warn

Warn logging is similar to info logging, but should be used far less often. It should only be used when something important, but non-breaking needs highlighting to the user. It should also be used to report anything that might cause an error at a later date.

Info

Info logging should be used to log basic events or information. The primary goal of info logging is to provide the user with an idea of what the program is doing. This includes stating when a new process starts, printing progress bars and standard output.

Debug

Debug logging should be used to print anything that may help a developer to diagnose an issue or bug. Usually this is the contents of a variable or structure. Debug logging should not be used excessively (e.g. printing the value of every variable). You should only log key events/variables that are useful to a developer.

• Pro-tip: Use Debugf() where possible to label the variables you're printing. This will help manage the build-up of confusing and out of context debug messages.

Trace

Trace logging is an extreme version of debug logging. If you find yourself printing hundreds of debug logs, most of which get ignored when debugging, try using Trace() instead. Trace logging should not be used as an alternative to a debugger. Debuggers are far superior! However, trace logs are useful when you need an audit of what went wrong on a UAT/Production system. You can and should print as many variables here as you like.

• My pro-tip for debug logs also applies here.