uber-go/zap

Add an option to override stacktrace collection logic

Open

#514 建立於 2017年10月12日

在 GitHub 查看
 (5 留言) (6 反應) (0 負責人)Go (22,391 star) (1,448 fork)batch import
help wanted

描述

Stacktrace collection

While trying to implement an encoder that is compatible with GCP Stackdriver logging and also for GCP Stackdriver Error Reporting, I suspected that it's not working properly because the generated stacktrace is not compatible with what Error Reporting is expected.

The documentation says (https://cloud.google.com/error-reporting/docs/formatting-error-messages): Go: Must be the return value of runtime.Stack()

The code in go sources (cloud.google.com/go/errors/errors.go) shows that cloud.google.com/go/errors.(*Client).logInternal indeed calls runtime.Stack.

Unfortunately, the stack is grabbed by trackStacktrace in stracktrace.go, and there is apparently no other way around to provide the stracktrace.

Unless I'm missing something, we cannot provide the way the stacktrace is grabbed by zap

貢獻者指南

技術棧
go
領域
backendobservability
議題類型
feature
難度面向新貢獻者的預計實作難度，1 表示很小改動，5 表示專家級工作。
3
預計時間有經驗貢獻者完成調查、實作、測試並準備 pull request 的粗略時間範圍。
1-2 days
活動狀態議題目前的可參與程度：新鮮、活躍、陳舊、阻塞或等待維護者輸入。
stale
清晰度議題是否清楚說明預期改動、驗收標準和下一步。
mostly clear
前置要求
Go basicszap librarystacktrace handling
新手友善度1-100 的估計分數，表示該議題對首次貢獻者的友善程度。
35
研究方向
Investigate the current stacktrace collection in stacktrace.go. Review existing discussions in the issue comments for any suggested approaches. Consider adding an option like `WithStacktraceProvider` to allow custom stacktrace generation. Look at how GCP's runtime.Stack is used and ensure compatibility.