Make log statements part of the public API

[timbussmann]

We have users which rely with their logging configuration on our internal implementations. E.g. if you want to log something which is by default logged in a log level you don't want to have across the whole application. Concrete scenario as discussed here: https://github.com/Particular/NServiceBus/issues/2074: Immediate retries are logged with level INFO, delayed retries with WARN. If you want to log immediate retries, it doesn't make sense to change the log level for the full application to info, so you have to configure that explicit logger (e.g. NServiceBus.Unicast.Transport.TransportReceive ) to INFO instead.

There is absolutely no guarantee on the logging between versions. With v6, it will change the logger name from NServiceBus.Unicast.Transport.TransportReceive to RecoverabilityExecutor. As this is no part of our official public API, there is no upgrade guide and no way to ensure the stability of those log statements.

Let's make the log statements above DEBUG level part of the public API. This means

• We need acceptance tests to verify the logger name, log level and (part of?) the log message.
• We need to properly handle upgrade paths for users using these log entries (e.g. "deprecating" old/moved loggers)
• Document changes to the logs.

This would add value for operations to ensure logs and log handling is consistent across versions. Also it enforces us to give more attention to log statements above DEBUG.

[danielmarbach]

Since we discussed it already together I can only add a self-biased: I like it

[andreasohlund]

Would there be value in starting to align the loggers around our folder(capability) structure.

Eg. things around recoverability would be using the NServiceBus.Recoverability logger?

Would that be to coarse grained?

[danielmarbach]

I think component based logging is much more valuable than class based logging.

[timbussmann]

I think component based logging is much more valuable than class based logging.

fully agree. This would decouple logging from internal implementations and makes the logs much more readable.