Sentryで始めるエラー監視

38259 ワード

はじめに

そもそもSentryとはエラーの可視化、監視ツールです。ダッシュボード上でエラー発生時のスタックトレースや、リクエストデータなどを確認することができます。

こんな感じでエラーが可視化されます。


マスク多くて申し訳ないですが、Issue画面です

パフォーマンス監視ツールとしての機能も持ちますが、今回の導入目的からは逸れるので言及しません。

以下で紹介するSentryの機能を利用するためには、有償プランを契約する必要があります。監視ツールを利用していない場合や、自前でエラー通知だけ行っていると、有償ツールの利用に抵抗があるかもしれません。しっかりと使いこなせばコスト以上に十分なリターンがあると感じているため、本記事により、Sentryの利用体験が少しでも向上すれば幸いです。※特にSentryの回し者ではありません。

導入目的

エラーの発生をSlack経由で検知し、その時の状況を分かりやすい形で確認できること、そしてエラーへの対応ワークフローを定めることが目的です。
また、エラー通知地獄に陥り、重要なエラーを見逃したり、エラー対応がおざなりになってしまうというような経験があるかもしれません。これに対し、必要十分なエラー通知を設定できるという点も重要なポイントです。
Sentryの利用体験をより良いものにするために、簡単なガイドラインも設けます。

用語

  • Projects...エラーイベントのトラッキング対象となる個別のアプリケーション単位です。1つのサービスが複数の異なる言語やフレームワーク、リポジトリなどで管理されている場合、それぞれを別のプロジェクトとして用意することが推奨されています。
  • Issues...同じエラーイベントをグルーピングしたものです。発生タイミングが異なるエラーであっても、同じエラーであれば、それが1つのIssueとして扱われます。「同じエラー」の定義はエラーイベントのfingerprintが一致しているかどうからしく、この辺りはSentry側がうまく扱っているようです(カスタマイズも可能)。異なるIssueと分類されたエラーイベントを手動で同じIssueにまとめることも可能です。
  • Quota...プランの課金体系に関係する月間のエラーイベント発生数。

設定方法

SDKのインストールはLaravelアプリケーションを前提としますが、他アプリケーションへの導入についてもドキュメントは充実しているようです。