Support for structured logging (using `log/slog`)

[cfiderer]

As of now, the containers/image library uses the sirupsen/logrus package for logging. This has a major drawback: when performing image activities for several images in different goroutines in parallel, it is not possible to mark or tag the log messages such that they an be attributed to the right activity.

Go 1.21 introduced structured logging (see Structured Logging with slog), allowing logger instances to be used as arguments and attributed to specific activities.

Please consider adding structured loggers to the API calls in the containers/image library.

[mtrmac]

Thanks for reaching out.

At this point, c/image only requires Go 1.19, so this is not yet possible (a migration to Go 1.20 could happen pretty soon, but we are probably going to be stuck on 1.20 support for the supported lifetime of Fedora 38).

Longer-term, yes, logrus is in maintenance mode, and migrating to the standard-library API is the most obvious replacement choice.

• I think we are fairly unlikely to do a mass-scale logging migration, but requiring new code to use slog would make sense
• The stable API commitment would make it difficult to add some probably desirable features, like callers submitting non-default Logger value, or even providing a context.Context to every log entry. The API can be extended, but again, that would probably only happen over some time.

[cfiderer]

About the support for older Go versions: the github.com/sagikazarmark/slog-shim package provides a means to migrate to slog before adopting Go 1.21.

[cfiderer]

Looks as if you are at Go 1.21 now... with #2377

[mtrmac]

First the callers need to be able to handle a library that uses both logging frameworks, something vaguely like https://github.com/mtrmac/skopeo/tree/logrus-deprecate .

It’s… tedious work and for interactive use, the output is not particularly pleasant. For non-debug output progress output, manually using fmt.Sprintf() instead of the structured fields is fairly attractive in some cases.

[cfiderer]

For Skopeo (and other interactive programs), using fmt.Sprintf() is surely attractive and a lightweight solution.

We use Logrus hooks to transport logging messages into the log/slog environment, so we are (at least) able to collect all log data.

But we use the c/image library in a Kubernetes operator, and we perform several (up to eight) image operations im parallel. In that environment, it is highly desirable to use context-aware logging to separate the sequential activities for each image operation. Furthermore, logging frameworks (like Fluentd) are already collecting structured logs and make them available for queries.