[FEATURE] allow passing custom logger to "server" component

[asynxc]

Is your feature request related to a problem? Please describe.

in a context where we instantiate multiple server in same process, we may need to assign specific fields to each instance.
So that it's easier to distinguish their logs.

Describe the solution you'd like

add new option server.WithLogger(logger log.Logger) to server options

If this's ok with you, i can create a PR in both go-micro and plugins projects ?

[Davincible]

Thanks for the feature request, PRs are definitely most welcome.

In this case, however, the service uses go-micro.dev/v4/logger.DefaultLogger as a logger, which is the same for the entire runtime. To use a different logger per service quite a bit would need to be changed.

The easy solution here would be to separate your services out in one per runtime.

Edit: you can ofcourse specify the logger by manually overriding that value

[asynxc]

Thanks for your feedback

The easy solution here would be to separate your services out in one per runtime.

The thing is about logger, is that we need to customize them even in the same runtime/microservice, usage example, when filtering logs of the broker client component, i may need to use a specific field (ex: broker) or for the store component or any other component use in microservice.

To use a different logger per service quite a bit would need to be changed.

i have read the codebase, DefaultLogger seems to be used everywere. but i'm still willing to create a PR that provide the option to override that and fallback to DefaultLogger in case no option logger provided, so that it stay backward compatible.

What do you think ?

[Davincible]

Your use case makes sense.

Definitely open to better implementations.

Well written PR is welcome. Looking forward to see your implementation :)

@xpunch thoughs on this ?

Edit: one note here, is that to use custom loggers per interface (store, registry, broker etc.) All plugins need to be rewritten alongside of the new options to use them. Perhaps we can by default auto derive an extra field to denote the interface type as you suggested

[asynxc]

@Davincible the fallback to DefaultLogger if no logger option provided allow us to handle plugins afterword without breaking anything...

in order for me to introduce this feature, i'll create two PRs, one for go-micro, second for plugins after go-micro release.

[xpunch]

The logger can be abstracted as a configurable component like registry, store, broker etc.
I think it can have a default implementation, and user can also have its own implementations, and replace it by import custom plugins.
https://github.com/go-micro/go-micro/blob/master/util/cmd/cmd.go#L49

[jochumdev]

Still there's a global containing the Logger for the current runtime? I believe @asynxc want's to replace the global with a Logger per instance.

[Davincible]

@pcdummy global logger won't be removed, see the PR for details. It's only used as a fall back

[Davincible]

@xpunch if you make the logger only one configurable component it's still global, just not in a global variable.

By allowing to pass in loggers through options you can set a different logger for different components (broker, registry etc.), so you can add custom fields to each logger, which what asynxc is looking for

[xpunch]

@Davincible I got your point, logging is very important in micro service systems. Different component or plugins may need different logger, maybe we need to re-design the whole logging modules in go micro.