Logging questions

[mattfarina]

While working on sudo nerdctl port forwarding I found myself in need of capturing logs. This is when I noticed the guest agents logs were not easy to work with. I wanted to do a PR to make some more of the logging useful but I wasn't sure what was supposed to happen and I have some opinions on what I'd like to do. So, here are my questions...

• The guest agent logs are directly through the logrus package which the host agent uses an instance of logrus. Is the different methods of using logrus intentional? See next question for more detail.
• The guest agent logs go to stderr. It's run as a daemon so there is no logging. Is this intentional or should the logs be moved to a file? If they are a file I would set most output to debug level and then run the guest agent with info level so most data would not be logged by default. This would be to not fill up VM disk space.
• logrus is in maintenance mode (see the README). The project recommends other logging packages. I was wondering if you would be open to a logging API and then logrus as the implementation being used. This would make it easier to change later if needed. I would go with https://github.com/masterminds/log-go. Note, I wrote that so this is a shameless plug.

[AkihiroSuda]

• The guest agent logs are directly through the logrus package which the host agent uses an instance of logrus. Is the different methods of using logrus intentional? See next question for more detail.

Intentional.
The host agent uses an instance of logrus to make sure that the output is always JSON-formatted.
The JSON is parsed by the limactl start CLI.
https://github.com/lima-vm/lima/blob/v0.6.3/pkg/logrusutil/logrusutil.go#L16

• The guest agent logs go to stderr. It's run as a daemon so there is no logging. Is this intentional or should the logs be moved to a file? If they are a file I would set most output to debug level and then run the guest agent with info level so most data would not be logged by default. This would be to not fill up VM disk space.

Intentional.
You can use journalctl --user -u lima-guestagent.service to see the logs in the guest.

• logrus is in maintenance mode (see the README). The project recommends other logging packages.

Yes, but still alive and actively used by a bunch of projects including containerd, runc, Moby, BuildKit, ....

I was wondering if you would be open to a logging API and then logrus as the implementation being used. This would make it easier to change later if needed. I would go with https://github.com/masterminds/log-go. Note, I wrote that so this is a shameless plug.

What are pros and cons of masterminds/log-go?

[mattfarina]

@AkihiroSuda Thanks for providing details on your intent and reminding me to use journalctl.

What are pros and cons of masterminds/log-go?

There are two pros...

First, Go packages often include a specific logging library. These packages used in one place are regularly imported into other applications. When different packages using different logging libraries are imported into one main application we can run into some problems:

1. There can be binary bloat as more than one logging implementation is imported.
2. If one of the loggers is not configured than logging information (especially debugging or trace levels) can be missed.
3. An application needs more complex setup logic to instantiate all of the logging implementations.

Kubernetes is a great example of this. If I read the dependencies right, it is including 8 different logging implementations. Many of these are due to dependencies.

log-go provides an interface that can be used all over. Both at the package level and as an interface passed around. Then, the application itself (main) can setup the logger to use everywhere. When a package is imported by someone they can setup the logger of their choice.

Second, changing loggers can be a pain. It means modifying the entire application. If a logger becomes deprecated or it doesn't implement a feature you need it's hard to change. Using an interface and being able to change out the logger in just one place make this much easier.

There are two cons...

1. Using an interface means you end up just using the subset of features in the interface. Some loggers have features not in log-go. It was built to satisfy the major loggers at the time it was written but I'm sure some features are missing.
2. log-go does not have major usage at this point. It's newer.

I'm ok with using it or not. I'm happy to do the work in transitioning if you are open to it. Thanks for reading through this.

[mattfarina]

Using an interface and configuring it would also solve issues like #112