👮

GCP Error Reportingの運用方法(収集してくれるログの範囲、条件、グループ化の条件)

2023/09/20に公開

GCPのError Reporingは勝手に問題検知してくれて通知もしてくれるので便利なのですが、細かい仕様を把握していなかったのでドキュメント読んで動作確認したので、ここにまとめます
https://cloud.google.com/error-reporting?hl=ja

まとめ

  • Error Reporingを運用するつもりなくても通知は設定しておくべき
    • 意図せずpanicしちゃった時などstack_trace付きのログが出力されたら勝手に収集してくれます
  • Error Reporitngに収集してほしいなら、stack_traceを出すか、構造化ログのjsonPayloadに@type: type.googleapis.com/google.devtools.clouderrorreporting.v1beta1.ReportedErrorEvent を指定すればOK
  • 通知はGCPプロジェクトごとに5回/1時間の制限あるので、通知が来た時はダッシュボードで全体のエラーの確認すべき
    • 通知が来た分 = 対応すべきエラー とは限らない

収集してくれるログの範囲

特に細かい設定をしていないならば、CloudLoggingでみれるログ全部になります。

https://cloud.google.com/error-reporting/docs/grouping-errors?hl=ja
(Error Reporting の概要に詳細の記述があります)

Error Reporting はグローバル サービスであるため、送信元と宛先の Google Cloud プロジェクトが同じで、顧客管理の暗号鍵(CMEK)が無効になっている global リージョンで Cloud Logging バケットに保存されているログエントリのみ分析できます。

正確な条件はこちらです。
ほとんどのケースではやってないと思いますが、CloudLoggingバケットを自分で作成し、CMEKを有効にしてる場合は収集の対象外になります。

Error Repotingに報告されるログの条件

https://cloud.google.com/error-reporting/docs/formatting-error-messages?hl=ja#format-log-entry

以下の2つのパターンのどっちか

1. ERRORレベル + スタックトレースを含むログを出力する

スタックトレースが出力されていればだいたいError Reportingに報告してくれます
ただし、ドキュメントの条件を満たしてない場合は収集されないので注意

収集してほしかったのに収集してくれなかったやらかしパターンの例として、わざわざpanicをハンドリングしてスタックトレース付きのログを出力していたのですが、stack_traceフィールドではなくstacktraceフィールドに出力してしまったため、収集の条件のどれも満たされずError Reportingに収集されなかったです。
ちゃんとstack_traceフィールドになっているか今一度確認しておきましょう。

2. 構造化ログのjsonPayloadに @type: type.googleapis.com/google.devtools.clouderrorreporting.v1beta1.ReportedErrorEvent を指定する

確実にError Reportingに収集してほしければこの方法が良いと思います。

その他方法

今回の目的とは外れますが、Error Reporing APIを利用することでError Reporingにエラーを登録することもできます。

https://cloud.google.com/sdk/gcloud/reference/beta/error-reporting/events/report

グループ化の条件

例外タイプとスタックでよしなにまとめてくれます。
正確なグループ化のルールは動作確認してもつかめなかったですが、同じ箇所でpanicすると同じグループになります。

@type: type.googleapis.com/google.devtools.clouderrorreporting.v1beta1.ReportedErrorEvent を指定した場合は、エラーメッセージごとにグループ化してくれますが、エラーメッセージがめっちゃ似てると同じグループになりました。
(hoge,hoge2だと同じグループになりましたが、hogeとfooは異なるグループになりました)

https://cloud.google.com/error-reporting/docs/grouping-errors?hl=ja#how_errors_are_grouped

通知の設定

ドキュメント通りに進めればOK
簡単でした。

https://cloud.google.com/error-reporting/docs/managing-errors?hl=ja#notifications

エラーのステータス

https://cloud.google.com/error-reporting/docs/managing-errors?hl=ja

ステータスは4種類です。

オープン: すべてのエラーグループのデフォルトの初期状態。他の状態は手動で設定します。エラーグループのステータスは、いつでも [オープン] に戻すことができます。
確認済み: エラーグループのトリアージ ステータス。
解決済み: エラーグループが修正され、今後発生しないことを示すための状態。[解決済み] とマークされたエラーグループで問題が再発した場合、Error Reporting は解決ステータスを [オープン] に戻します。
ミュート: リストからエラーグループを選択できません。詳しくは、ミュートエラーをご覧ください。

確認済みとミュートはほぼ同じですが、多分差分は以下のみです。

ステータスが [Open] または [Acknowledged] のエラーを削除した場合、エラーが再発しても Error Reporting から通知は送信されません。

通知のタイミング

https://cloud.google.com/error-reporting/docs/notifications?hl=ja#when-sent

通知されるのは

  • 新しいエラーの発生時
  • 解決済みのエラーが再発した

また、通知は1時間あたり5回までとなっているので、通知が来た分 = 対応すべきエラー とは限らないです。
通知来るたびにError Reporingで全てのエラーを確認しておくのがよさそうです。

Discussion