導入の障壁が低く始めやすいエラー監視の定番ツール

Sentry の導入以前は、基本的にエラーログが Cloud Logging に残る程度で、エラーを能動的に検知できない（ログを見に行かないと発見が難しい)点が状態でした。そのため、エラーログからあとでトラブルシュートしようにも、情報量が少なく使いにくい点が課題でした。

そこで、あまり特別なことをせずに、雑多なエラーをあとで見返して対応できる体制を構築するために、Sentry の導入の検討をしました。

• 実運用上で余分な作業があまり発生しないこと
  
• コストが高すぎないこと
  

Sentry の導入によって、エラー情報を蓄積するという目的は一定達成できました。一方で、蓄積したエラーをうまく対処するか無視するかなど適切にトリアージしたり、システム運用に活用したりという面ではまだ課題が残っている状態です。

また、エラー数が跳ねた時に異常を検知して、具体的にどのようなエラーが起こっているか調査する体制・文化が醸成されました。

参考記事：Sentry と上手く付き合ってエラー監視を改善しよう
(https://zenn.dev/ubie_dev/articles/e7dec1879bfb9c)

一時期発生しているエラーと真面目に向き合おうとしていたが、向き合いすぎるのも困難を伴いました。

特にクライアントサイドから飛んでくるエラーは環境依存のものもあり、原因とインパクトが分かりにくいエラーも一定あり得たため、これらを精査しながら特に対応すべきエラーに立ち向かうトリアージが必要です。

初期導入のハードルは低く、頑張らなくても一定のリターンは得られるのでおすすめできると思います。

一方で、真面目にエラーに立ち向かうとその難易度は上がる感触があるので、やり方を工夫をしたり、エラーハンドリングの体制を考えたりする必要がありそうです。