Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can we support pluggable interface based logger? #76

Open
gl-works opened this issue Mar 25, 2016 · 9 comments
Open

Can we support pluggable interface based logger? #76

gl-works opened this issue Mar 25, 2016 · 9 comments

Comments

@gl-works
Copy link

It would be nice to use a interface based logger option with multi-level output support. The current log implementation produces too many debug logs which are rarely useful.

@slackpad
Copy link
Contributor

Hi @gl-works it should be possible to support multiple levels, but there's a lot at the DEBUG level that we could probably make better use of a TRACE level for (things that are proportional to the traffic being handled).

@mofirouz
Copy link

Hi @slackpad - I'd like to bump this up as well.

We use https://github.com/uber-go/zap to take care of the application level logging and there is sadly no-way to interface with this given the current implementation.

Could you give quick yes/no on your thoughts on this, as I'm thinking of nominating myself for a PR?

@slackpad
Copy link
Contributor

slackpad commented Feb 8, 2017

We are still working on standardizing the logger across our different tools so we should hold off until we figure out the direction for that. I'll update this once I have more info.

@htdvisser
Copy link

htdvisser commented Jan 4, 2018

With a couple of changes it's already fine for me. The changes are compatible with the current logging, so existing code that uses memberlist does not have to be modified. I can submit a pull request if that would be appreciated.

Edit: I did remove the memberlist: prefix from log messages. If I'd put that back, it would be exactly the same as it is now.

@slackpad
Copy link
Contributor

Hi @htdvisser we've now got https://github.com/hashicorp/go-hclog so we plan to port to that interface.

@htdvisser
Copy link

Ok, thanks, I'll keep an eye on that

@egourlao
Copy link

Hi, any news about the port to https://github.com/hashicorp/go-hclog? Would be happy to work on it if it's not a priority!

@etiennedi
Copy link

Here's a very dirty workaround I'm using until we get a pluggable interface logger. It's meant to work with logrus.FieldLogger, but could also be adjusted to any other logger. Maybe it'll help someone else:

type logParser struct {
	logrus logrus.FieldLogger
	regexp *regexp.Regexp
}

func newLogParser(logrus logrus.FieldLogger) *logParser {
	return &logParser{
		logrus: logrus,
		regexp: regexp.MustCompile(`(.*)\[(DEBUG|ERR|ERROR|INFO|WARNING|WARN)](.*)`),
	}
}

func (l *logParser) Write(in []byte) (int, error) {
	res := l.regexp.FindSubmatch(in)
	if len(res) != 4 {
		l.logrus.Warnf("unable to parse memberlist log message: %s", in)
	}

	switch string(res[2]) {
	case "ERR", "ERROR":
		l.logrus.Error(string(res[3]))
	case "WARN", "WARNING":
		l.logrus.Warn(string(res[3]))
	case "DEBUG":
		l.logrus.Debug(string(res[3]))
	case "INFO":
		l.logrus.Info(string(res[3]))
	default:
		l.logrus.Warnf("unable to parse memberlist log level from message: %s", in)
	}

	return len(in), nil
}

you can insert in the config using

cfg.LogOutput = newLogParser(logrus)

@kcmvp
Copy link

kcmvp commented Apr 22, 2023

any update?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants