Logging

[KenxinKun]

What's the immediate issue?

There's a few instances around testcontainers-go (notably, the wait package) were debug logs are being sent directly to STDOUT, causing unnecessary noise in some situations (e.g. a wait strategy for a mapped port may print multiple times a message such as 2025/02/06 15:25:55 mapped port: retries: 1, port: "", err: port "4317/tcp" not found).

An initial PR (#2912) attempted to control these logs using an optional logger. We tried using the global logger defined on the primary package but there is a circular dependency with the wait package making the import impossible.

What's the context?

There are on-going efforts to create a client to centralise common functionality such as logging. Ideally the final solution would follow that pattern, but we may want to offer a quicker solution with a clear (deprecated) marker that it is temporary.

Proposed (short term) solution

Create a default logger, global to the wait package with an associated SetLogger method to override it, replacing all direct calls to fmt.Printf and fmt.Println in the package with this logger. This new elements would be marked as deprecated immediately, since they are just intended as a quick solution.

Proposed (long term) solution

It's important to analyse first what the purpose for logging different elements is from a user's perspective:

• Is a container slow to start because a wait strategy is taking a long time?
• Are there errors inside a running container that could be useful in examining why a test is failing?
• Is the user interested on logs specific to a part of the system (e.g. a new container added to a complex test)

In general we cannot make the determination of what would be the most important for a particular use case, but it seems more obvious that a structured, filterable log would add value.

For that reason, we'd like to propose the introduction of slog as standard logging, including multiple levels (DEBUG, INFO, WARN, ERROR...) and additional tags that can help identify the source of the error (e.g. a container name, a framework component such as a wait strategy, whether it's stdout/stderr from the container logs themselves etc).

Centrally controlling this within the future client feels like the natural place to locate this logic, allowing all parts of the framework to use this centralised piece of logging infrastructure.

[KenxinKun]

Here's a first attempt to implementing this, with the logger being moved under log/logger: #2979

[mdelapenya]

I'm closing this discussion as it was implemented in #2979, thanks everybody for your work during the process 🙇