💥

Google Cloud Error Reportingでエラーと上手く付き合う

2022/10/31に公開約1,000字

Error Reportingが最近色々進化していて、通知から記録まで隙のないサービスになっていたので全体像をまとめてみます。

Error Reportingへエラーを送信する

GCPのインフラを利用している場合は自動で拾ってくれます。
ソレ以外の場合もいろいろライブラリがあるので調べてみてください。

エラーのステータスを管理する

Error Reportingでは、エラーのステータスを管理できます。

  • 未解決
  • 確認済み
  • 解決済み

で、確認済みにする場合は、GithubのIssueなどをリンクすることが出来ます。

Slackやメールでエラーを通知する

Error ReportingではデフォルトでSlackやメールでの通知に対応しています。
通知の条件は、

  • 新しいエラーが発生した場合
  • 解決済みのエラーが再発した場合
  • 5回以上通知されたら、6時間はエラーが通知されなくなる

なので、エラーのステータスをきちんと管理すれば、

  • 対応が必要な(未知の/再発した)エラーのみを通知する
  • 対応が必要でない(対応中の/避けられない)エラーの通知を除外する
  • 通知が頻繁に来続けることを避ける

が実現できます。

また、Cloud Logging(自動でエラーの分のログが記録されています)とCloud Monitoringと組み合わせれば、

  • 普段は対応が必要なさそうなエラーが頻発した場合にインシデントとして通知する

も実現できます。
例えば ポリシー "Too meny timeout" など、普段はタイムアウトは仕方ないので無視したいけど、めっちゃ多いと心配になる、という場合にも適切な通知を設定できると思います。

エラーの分析をする

Error Reportingではトレースを見ることが出来ます。ここでいろいろ分析できますね。
ただし、リクエストの状態は見られれないので、そこは別の方法を検討する必要があります。

エラーを記録する

Error Reportingの情報は同時にCloud Loggingに溜まっています。これをCloud Storageにシンクすることで、永続的にエラーの情報を保存することが出来ます。

Discussion

ログインするとコメントできます