Allow developer to pass his/her logging framework of choice

[Tochemey]

The current implementation forces the developer to pass in the golang standard logger which is not bad. However, most production application makes use of structured logger libraries. The current implementation does not allow that.

I recommend to expose a logging interface that the developer can implement by hooking his/her own logging framework. cc @buraksezer

[Tochemey]

@buraksezer Thank you for monitoring this. I really do appreciate it. If you don't mind I can open a PR in that regard. Before then this is logging interface I am suggesting:

// Logger represents an active logging object that generates lines of
// output to an io.Writer.
type Logger interface {
	// Info starts a new message with info level.
	Info(...any)
	// Infof starts a new message with info level.
	Infof(string, ...any)
	// Warn starts a new message with warn level.
	Warn(...any)
	// Warnf starts a new message with warn level.
	Warnf(string, ...any)
	// Error starts a new message with error level.
	Error(...any)
	// Errorf starts a new message with error level.
	Errorf(string, ...any)
	// Fatal starts a new message with fatal level. The os.Exit(1) function
	// is called which terminates the program immediately.
	Fatal(...any)
	// Fatalf starts a new message with fatal level. The os.Exit(1) function
	// is called which terminates the program immediately.
	Fatalf(string, ...any)
	// Panic starts a new message with panic level. The panic() function
	// is called which stops the ordinary flow of a goroutine.
	Panic(...any)
	// Panicf starts a new message with panic level. The panic() function
	// is called which stops the ordinary flow of a goroutine.
	Panicf(string, ...any)
	// Debug starts a new message with debug level.
	Debug(...any)
	// Debugf starts a new message with debug level.
	Debugf(string, ...any)
	// LogOutput returns the log output that is set
	LogOutput() []io.Writer
	// StdLogger returns the standard logger associated to the logger
	StdLogger() *golog.Logger
	// WithContext returns the logger with the given context
	WithContext(ctx context.Context) Logger
}

where golog is an alias to the standard log. We can then add a default logger that implements such an interface.

[buraksezer]

Hello @Tochemey,

This topic has been discussed before. You can find the previous issue here: #128 (comment)

Currently, the logging in Olric works like the following:

dm.s.log.V(3).Printf("[ERROR] Failed to synchronize replica %s: %v", version.host, err)

log is a flog instance. https://github.com/buraksezer/olric/blob/master/pkg/flog/flog.go

We might discuss a logging interface but the log format will not be changed. It's too costly and would be a waste of precious development time.

A hacky solution has been discussed here: #117. It's hacky but it definitely works.

If you don't mind I can open a PR in that regard.

Thank you for offering help but I only accept minor contributions.

[Tochemey]

#128 (comment)

@buraksezer Thanks for the link.

[Tochemey]

@buraksezer By the way, I cannot really see the solution from the list. Maybe I am not reading well. Currently my use case is to incorporate uber.zap

[buraksezer]

The solution is passing a custom LogOutput implementation via the config struct. LogOutput is an io.Writer. A sample: #117 (comment)

loggerWriter implements io.Writer.

fluxninja/aperture uses the same approach. https://github.com/fluxninja/aperture/blob/main/pkg/dist-cache/logwriter.go

By the way, would you like to explain how you use Olric? What is your use case?

[Tochemey]

@buraksezer I am using Olric to help build a clustered distributed system. This is the project https://github.com/Tochemey/goakt.

Basically I am using it as a distributed key/value stores

[Tochemey]

@buraksezer Earlier on I was using etcd but when I discovered Olric with its sharding concept, I just jumped on it as my cluster engine

[Tochemey]

@buraksezer closing the issue.

[Tochemey]

@buraksezer this is how I got it working: Tochemey/goakt@f7bb961