I'm using zapp to log error messages on a service hosted on google cloud, and am seeing that while errors are logged successfully, the text stored in the "message" field of the google cloud log is the stack trace, and not the error message I have logged.
Example code:
var log *zap.Logger
if err := doStuff(); err != nil {
log.Error(<error message I want to log>, zap.Error(err))
}
This works well except google cloud logging and stackdriver will use the stack-trace caught by the call to zap.Error in the message field of the structured log. The message I've defined appears in the msg field, but the former appears to be the one displayed predominantly in the logging console and used by stackdriver for indexing errors.
This means that when navigating logs and errors via the console, I only see stacktraces, and no indication of the associated error string.
The tricky thing is I have no idea if this "issue" is cloud-side or zapp-side. I've spent some time digging around in Zapp to no avail, and am out of ideas.
zap by default puts the message under the msg key, the stacktrace under stacktrace, and prints log lines as json to stdout. You should be able to see this in action by just running your binary locally.
Your logging system presumably processes these log lines as they're printed. It will read them, parse them, and maybe do some restructuring or add some metadata, and then send them off somewhere else to be saved or processed more.
Since zap is in all likeliness working as intended, you need to look at the system that processes your logs. How does it expect them to look? Does it have special rules for any particular keys? Will it inject any keys of its own?
Note that you can configure zap to use different keys for all of its standard fields.