Investigate possible adoption of new "structured logging" package in Go stdlib about alvarium-sdk-go HOT 5 CLOSED

I took a look into our custom provider-logging and slog, and got a sense of how we can carry this out, the only issue is that slog.Info has 3 default key values
{"time":"2009-11-10T23:00:00Z","level":"INFO","msg":"Test message with no args"}
opposed to ours
{"timestamp":"2023-11-27T09:27:17Z","hostname":"DESKTOP0","application":"/tmp/go-build1311042308/b001/exe/test","line-number":"test.go:12","log-level":"info","message":"Test message with no args"}
Different naming for same att are: time vs timestamp, level vs log-level and msg vs message.
So I am searching for a workaround to match our current error format exactly and match the level to our own log-levels.

from alvarium-sdk-go.

I created a JsonHandler with a HandlerOptions that renames the default keys to match ours, also lowercase the log-level and formats the time as our format.

handler := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
ReplaceAttr: func(groups []string, a slog.Attr) slog.Attr {
	if a.Key == slog.TimeKey {
		a.Key = "timestamp"
		inputTime:= a.Value.Any().(time.Time)
		outputTime:= inputTime.Format("2006-01-02T15:04:05Z")
		a.Value = slog.StringValue(outputTime)
	} else if a.Key == slog.MessageKey {
		a.Key = "message"
	} else if a.Key == slog.LevelKey {
		a.Key = "log-level"
		level := a.Value.Any().(slog.Level)
		a.Value = slog.StringValue(strings.ToLower(level.String()))
	}
	return a
},
})
logger := slog.New(handler)
logger.Info("Test message with no args")

will output the following log
{"timestamp":"2023-11-28T12:19:24Z","log-level":"info","message":"Test message with no args"}
We'll just need to extend the logger to add the hostname, application and line-number attrs in each log entry.
I'll add a custom logger class in the sdk that extends the slog logger to accommodate our custom attributes, is this the implementation expected?

from alvarium-sdk-go.

This is a good start. Some comments:

• Change the if/else to switch
• For hostname and application it looks like you can use .With() after initially creating the logger with your JsonHandler to specify those common values
• The HandlerOptions type has an AddSource flag on it which will supposedly capture the line number

Integrate those parameters and let's see what a log entry looks like.

I looked at the Scoring and Example App's dependencies. If we were to go this route, we would eliminate provider-logging and obtain the slog.Logger type instance from the SDK. This will change all of the methods that currently require logger logInterface.Logger. Any thoughts on that? I'm undecided on whether or not to put the slog.Logger behind an interface of some kind.

from alvarium-sdk-go.

Yes I've tried the AddSource but its output was a little different
{"timestamp":"2023-11-30T08:26:15Z","log-level":"info","source":{"function":"main.main","file":"/home/admin/alvarium/alvarium-sdk-go/test.go","line":57},"message":"Test message with no args"}
We can reformat it somehow to match ours, but it's missing the "application":"/tmp/go-build1714900388/b001/exe/test" attribute.

For the refactoring, Since we may have some added functionality and customization, I wanted to wrap the logger with a decorator to add our customizations but the slog.Logger doesn't implement any interface. We can just extend the slog logger or embed it in a new struct. I thought either way it would be better to put it behind a new custom interface. Are any of the 2 solutions optimized enough to proceed with?

Also in that case will that customized Logger interface and logic lie in the go-sdk?

from alvarium-sdk-go.

We can reformat it somehow to match ours, but it's missing the "application":"/tmp/go-build1714900388/b001/exe/test" attribute.

Since we aren't constrained by long term support, remember that we could also make the Java/Python logging conform to whatever changes we make here. Don't feel like you have to fight with the slog.Logger to mash its content into a pre-conceived format. As long as all the information is included we can just change the other SDKs to match. Once you decide on a format/approach, you may want to take a few minutes and think through the changes you'd need to make over there.

For the refactoring, Since we may have some added functionality and customization, I wanted to wrap the logger with a decorator to add our customizations but the slog.Logger doesn't implement any interface. We can just extend the slog logger or embed it in a new struct. I thought either way it would be better to put it behind a new custom interface.

OK, sounds reasonable -- This might afford you a way to introduce the missing application property through the constructor when the logger instance is initialized. The output could be something like

{
    "application":"/tmp/go-build1714900388/b001/exe/test",
    "entry": {
        "timestamp":"2023-11-30T08:26:15Z","log-level":"info","source": 
           {"function":"main.main","file":"/home/admin/alvarium/alvarium-sdk-go/test.go","line":57},
        "message":"Test message with no args"
    }
}

Also in that case will that customized Logger interface and logic lie in the go-sdk?

Yes

from alvarium-sdk-go.