英文:
Zap stack traces vs. error messages on google cloud
问题
我正在使用Google Cloud上托管的服务来记录错误消息,并且发现尽管错误成功记录,但存储在Google Cloud日志的"message"字段中的文本是堆栈跟踪,而不是我记录的错误消息。
示例代码:
var log *zap.Logger
if err := doStuff(); err != nil {
log.Error(<我想要记录的错误消息>, zap.Error(err))
}
这个方法很有效,但是Google Cloud日志和Stackdriver将使用通过调用zap.Error
捕获的堆栈跟踪在结构化日志的"message"字段中。我定义的消息出现在"msg"字段中,但前者似乎是在日志控制台中主要显示的消息,并且被Stackdriver用于索引错误。
这意味着在通过控制台导航日志和错误时,我只能看到堆栈跟踪,而没有相关错误字符串的指示。
棘手的问题是我不知道这个"问题"是云端的还是Zapp端的。我已经在Zapp中花了一些时间进行挖掘,但没有任何结果,现在我已经没有主意了。
英文:
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.
答案1
得分: 1
默认情况下,zap将消息放在msg
键下,堆栈跟踪放在stacktrace
下,并将日志行以JSON格式打印到标准输出。通过在本地运行二进制文件,您应该能够看到这一点。
您的日志系统可能会在打印时处理这些日志行。它会读取它们,解析它们,可能进行一些重组或添加一些元数据,然后将它们发送到其他地方进行保存或进一步处理。
由于zap很可能按预期工作,您需要查看处理日志的系统。它希望日志看起来是什么样子?它是否对任何特定键有特殊规则?它会注入自己的键吗?
请注意,您可以配置zap使用不同的键来存储其所有标准字段。
英文:
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.
答案2
得分: 0
在GCP上正确有效地记录日志,首先,您需要使用Logging的LogEntry设置适当的Zap密钥。
如果您正在寻找一个可行的示例,我在这里写了一个简单的Zap配置:
https://github.com/uber-go/zap/discussions/1110#discussioncomment-2955566
英文:
To log correctly and effectively on GCP, first, you have to set appropriate Zap keys with the Logging's LogEntry
In case you are looking for a working example, I write a simple Zap config here:
https://github.com/uber-go/zap/discussions/1110#discussioncomment-2955566
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论