スタックトレース始めてみた

社内のLT会で使用した資料です。

URL
p.8 比較・検討
https://pkg.go.dev/github.com/pkg/errors
https://pkg.go.dev/golang.org/x/xerrors
https://github.com/juju/errors
https://github.com/go-errors/errors
https://github.com/morikuni/failure
https://github.com/hashicorp/go-multierror
https://github.com/rotisserie/eris
https://github.com/cockroachdb/errors

p.17 参考
https://www.datadoghq.com/ja/product/error-tracking/
https://docs.datadoghq.com/ja/logs/error_tracking/backend/?tab=serilog
https://zenn.dev/nhiguchi/articles/5465d1de39b7fb
https://speakerdeck.com/syumai/godesutatukutoresuwoxi-ufang-fa-gayayakosiijian-nituite
https://methane.hatenablog.jp/entry/2024/04/02/Go%E3%81%AEerror%E3%81%8C%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B9%E3%82%92%E5%90%AB%E3%81%BE%E3%81%AA%E3%81%84%E7%90%86%E7%94%B1
https://zenn.dev/furon/articles/b7275043eb7dcb
https://kaminashi-developer.hatenablog.jp/entry/2022/12/15/093000

Transcript

1. スタックトレース始めてみた 2024/05/15 Monthly LT Go プリズムパートナーカンパニー kuro
2. みなさんはGoのスタックトレース使って ますか？
3. なぜ欲しいのか •DataDogのError Trackingを使いたい！⇦比重大 •エラーデバッグをもっと簡単にしたい。
4. DataDog ErrorTrackingとは 1. エラーをいい感じにグループ化してくれる。 2. 通知もエラーごとにいい感じに制御してくれる →以下の2種類のモニターを使える。 Count: エラーのグループごとに一定の値を超 　　　　　 えたら通知してくれる。 
 　　　 New Issue: 新しいエラーが発生したら通知し 　　　　　　　 てくれる。
 →ある一定の値を超えるエラーが出た場合のみ対 応したいみたいなニーズにあう。 参照 https://www.datadoghq.com/ja/product/error-tracking/
5. DataDog ErrorTracking導入 当初 ErrorTrackingをONにするだけか😍 実際 あれ、ONにして待てど暮らせど何も出てこない。。。 👇 ログの構造を変える必要がある。 参照：https://docs.datadoghq.com/ja/logs/error_tracking/backend/?tab=serilog 属性 説明 error.stack 実際のスタックトレース error.message スタックトレースに含まれるエラーメッセージ error.kind エラーのタイプまたは「種類」 ("Exception" や "OSError" など)
6. ほな、スタックトレース入れてみますか
7. 懸念点・考慮すべき点 - パフォーマンスが下がる可能性あるかも。 - 参照：はてなブログ Goのerrorがスタックトレースを含まない理由 - やっぱやめようとなったときに剥がしやすい仕組みにしたい。 - エラーをラップする部分を忘れないようにしたい。 - 大きな修正はしたくない。 - slog（https://pkg.go.dev/golang.org/x/exp/slog）との相性も考えたい。
8. 比較・検討 1. pkg errors or xerrorsをそのまま使う。→メンテされてないのが🥺 a. https://pkg.go.dev/github.com/pkg/errors b. https://pkg.go.dev/golang.org/x/xerrors 2. その他の色々OSSを使う→要件に対してtoo muchなのと大体全てのエラーをラップするのが必要 a. https://github.com/juju/errors b. https://github.com/go-errors/errors c. https://github.com/morikuni/failure d. https://github.com/hashicorp/go-multierror e. https://github.com/rotisserie/eris f. https://github.com/cockroachdb/errors 3. 自前 a. pkg errors or xerrorsあたりの実装を引っ張ってくる b. debug.Stack(https://pkg.go.dev/runtime/debug#Stack)や、 runtime.Callers(https://pkg.go.dev/runtime#Callers)のメソッドを使う
9. runtimeパッケージでスタックトレース - func Stack() []byte - スタックトレースをバイト列にして返してくれる。 - func Callers(skip int, pc []uintptr) int　＋　func CallersFrames(callers []uintptr) *Frames - Callersが返すプログラムカウンタをCallersFramesに渡すと関数/ファイル/行の情報を返してくれ る。 →ちょっとだけ*Framesの加工がめんどい
10. スタックトレースを作成 - runtime.Stackでスタックトレース を作成して、StackError構造体 を返す。
11. ラップする方法 - pkgsite/internal/derrors 参考に。 (https://cs.opensource.google/go/x/pkgsite/+/master:internal/derrors/derrors.go) - deferで、関数を抜ける時に WrapStackを呼び出す。
12. ラップする方法 - WrapStackでは、エラーが - StackError型の場合→errをwrap する。 - StackError型でない場合→errを 新しくStackError構造体に。 - ダブルポインタを使うことでdeferで関数 を抜ける際にエラーを直接更新する。 - ただ、名前付き戻り値にする必要あり。
13. ラップする方法 - 全てのエラーごとにWrapを追加せずに済む →関数ごとにdeferを入れてwrapするだけ。 →静的解析もしやすいのではないか（展望） - ただ、エラーを更新するために、名前付き戻り値に書き換えるのがちょっと大 変。。
14. slogとの組み合わせ - LogValuer(https://pkg.go.dev/golang.org/x/exp/slog#LogValuer)インターフェースを満たすようにしてロギングの際 にstack,message,kindを出力できるようにログを整形する。 - 以下のようにして、StackError型のエラーをslogで出力すると意図通りの構造化ログになる。
15. 試している方法 - 自前エラーパッケージを追加する。 - 一部のコンポーネントでdefer＋名前付き戻り値に置き換える。 - Datadog Error Trackingが役に立ちそうか検証中。
16. これから - DataDog Error Trackingが良さそうなら、エラーがよく出る部分からさらに追加して いく。 - スタックトレースを始めて、パフォーマンスがどう変わったのかDataDogで計測し たい。 - deferのWrap忘れを検知できるようなlinterを何かしら導入したい。
17. 参考 - Error Tracking | Datadog - バックエンドエラーの追跡 - Datadog Error Tracking for Logsを使って日々のエラーログ監視を省力化する - Goでスタックトレースを扱う方法がややこしい件について - Speaker Deck - Goのerrorがスタックトレースを含まない理由 - methaneのブログ - pkgsite/internal/derrors を使ったGoのエラーラッピング - Goでスタイリッシュにエラーをラップする方法を学んだ - カミナシ エンジニアブログ
18. ご清聴ありがとうございました