More granular logging support for plugins

[johnharris85]

Describe the problem/challenge you have When debugging a plugin (or just for general plugin use to be honest) it's hard to sift through all of the very verbose -v output to find the specific plugin logs I care about.

Describe the solution you'd like A way of specifying log levels to plugin logs (so we could have plugin logs at INFO for example).

There may already be a way of doing this? If so I haven't found it yet :)

Environment:

• Octant version (use octant version): 0.11.1
• Kubernetes version (use kubectl version): 1.17.3
• OS (macOS 10.15, Windows 10, Ubuntu 19.10 etc): Ubuntu 16.04

[lenriquez]

I wonder if is possible to create a file for each plugins to save the logs information or if is just better to attach the plugin name on the log so it will be easy to search for it using grep

[liamrathke]

I ran into this exact issue recently, even searching with grep was somewhat of a pain, since I wanted to track the logs in real time and didn't want to have to pipe output through another program.

Similar to how we have a verbose option, maybe we could introduce an Octant flag specifically to enable verbose logging, but only for plugins?

[wwitzel3]

Ideally we'd have some way for the log level to be enabled on a per-plugin basis. So we don't have to introduce a lot of noise in to the system to get the output from just a single plugin. Though I'm not sure how that would look in practice.

Initially I think just allowing the debug level to be set somewhere in the plugin code and using that level for logging no matter what the Octant level is set to.

A plugin should be able to set DEBUG, WARN, INFO, ERROR level and log output independently of the Octant process.

[lenriquez]

I was checking grep but it was not working for me but I found this "The underlying code behind log.Println() uses fmt.Sprintln() while fmt.Println() uses Fprintln() function. The difference is that Fprintln() writes to io.Writer, while Sprintln() does not. io.Writer will pipe text output to grep command via the Unix/Linux's |." The solutions that I can think

1. (Very complicated) We could create a map with log struts for every plugin but we will have to select the log on every place we want to print something
2. (Very Simple) Print everything into a log file, the old way, to allow the user to user tail -f /var/log/file.log | grep search_term or use any other tool making sure the plugin name is on the output, which by the way I think it already is

3. Do second solution but with JSON Format?

[lenriquez]

By the way we use Uber's go zap https://github.com/uber-go/zap/blob/c8e813efff7b3d6f791ee71b3f76b9a175d2a9d8/sugar.go#L137

[wwitzel3]

potentially related if we go with 3. - #1078