Include source in StreamLogHandler output

[slashmo]

Include source in StreamLogHandler output.

Motivation:

When using the same Logger across an application in combination with the default StreamLogHandler, it may be difficult to differentiate between logs produced by different modules. ServiceLifecycle works around this by prepending the log message with [Lifecycle], which is what I'd like to do StreamLogHandler by default, leveraging the source log parameter.

Modifications:

StreamLogHandler will include the source in brackets right before the log message when writing a log.

Result:

Logs from different modules are easily differentiable when produced using the same Logger instance.

[swift-server-bot]

Can one of the admins verify this patch?

[swift-server-bot]

Can one of the admins verify this patch?

[swift-server-bot]

Can one of the admins verify this patch?

[swift-server-bot]

Can one of the admins verify this patch?

[swift-server-bot]

Can one of the admins verify this patch?

[swift-server-bot]

Can one of the admins verify this patch?

[swift-server-bot]

Can one of the admins verify this patch?

[swift-server-bot]

Can one of the admins verify this patch?

[swift-server-bot]

Can one of the admins verify this patch?

[slashmo]

I added this PR as a starting point for a discussion around whether we should be including the source parameter in log output produced by StreamLogHandler. CC @ktoso, @weissi

[weissi]

I am personally happy with this PR, so good to go from my side :).

Said that, we kinda intentionally made StreamLogHandler "not good" because we want people to use real logging backends instead of relying on this "toy implementation". But given that we probably shouldn't omit too much information, I'd say let's take adding "source".

[weissi]

@swift-server-bot test this please

[weissi]

@swift-server-bot add to allowlist

[slashmo]

Said that, we kinda intentionally made StreamLogHandler "not good" because we want people to use real logging backends instead of relying on this "toy implementation".
@weissi

Good point! Although one could also argument that having it as a reference point for "better" implementations would also be beneficial, so including it could motivate other impls to do the same.

[weissi]

I like this and to @slashmo's point: We should educate logging backend builders to include source in their logs. One of the most effective ways is likely to just include it in the StreamLogger. So deffo +1 here

[ktoso]

Yeah, LGTM from my end as well.

Our backend is known to try to be intentionally not great, but it should not drop data is has already. I was surprised we didn't log the source, so definitely +1.

Thanks a lot for noticing @slashmo !