こんにちは。エンジニアのすずまさです。

弊社では、エラー監視ツールとしてSentryを利用しています。

私のチームではSentryをうまく活用できていない状態が続いていましたが、最近は運用負荷を軽減しつつ障害を早期発見するなど、以前よりも運用が改善されてきたので今回はその紹介をします。

当時の課題「とにかくエラーが多すぎる」

トリアージがほとんどされておらず、S/N比が低くなっていました。そのため、ノイズが多く重要なエラーを判別するのが難しい状況でした。

具体的には以下のようなエラーがノイズとなっていました。

ユーザに悪影響はないが、ハンドリング漏れで大量に発生しているエラー
- ex. API通信で status code 0 が返ってきた場合¹ のハンドリング漏れによるエラー
原因がはっきりせず、ユーザ影響の有無を判断できないエラー
- ex. Stack Traceに情報がなかったり、Source Mapsの導入ができていないなどの理由で発生箇所が特定できないエラー

当時、毎日24時間以内に発生したエラーを確認するようにしていましたが、数が多すぎて想定以上に時間をかけてしまうことも多く、ひとつひとつ確認するだけで疲弊していっていました。

ノイズを減らす

まずは以下を行い、ノイズを減らそうと努めました。

順番に解説していきます。

ArchiveはSentryのアラートを一時停止する機能です。

(Google翻訳) アーカイブは、緊急性が低い、または自分やチームに関係のない、ノイズの多い問題に適しています。アーカイブすると、issueのステータスがアーカイブ済みに変更され、issueが「未解決」から「アーカイブ済み」タブに移動します

Archiveを使うと、エラー自体は確認できるものの、普段は目に入らないようにできます。

また、Archiveには永久的なものだけでなく、期間や回数の条件をつけることもできます。例えば「今から100回発生するまで」「1時間のうちに10回発生するまで」「今からさらに1ユーザに影響が出るまで」のような条件の指定が可能です。

この機能を使い、先ほど例に挙げたノイズとなっていたエラーは次のようにトリアージしました。

こうしたトリアージについては以下の記事でも紹介しています。

同じようなエラーでも、発生要因が微妙に異なると別のエラーとして検知されてしまうことがあります。手動でマージすれば一つのエラーとして扱うことができますが、別エラーとして検知されるたびに毎回マージするのは面倒です。

こうした手間を削減するため、見覚えのあるエラーが通知されたらIssue Groupingを設定するようにしました。

エラー内容や、スタックトレースの発生箇所をもとにグループ化するよう設定できます。詳しくは以下をご覧ください。

上述した取り組みにより、少しずつノイズは減っていきました。しかし、頑張ってトリアージを続けても中々すべてのエラーを処理しきれず、運用負荷は高いままでした。そこで、既存のエラーをすべて確認するのではなく、重要なエラーだけピックアップして確認するようにしました。

重要なエラーとしては、以下のようなものが挙げられるかと思います。

上記の2つを検知する仕組みをSentry Alertsで設定し、検知したらSlackに通知するようにしました。特に、急増エラーは障害の可能性があるため、エンジニアにメンションするよう設定してすぐ対応できるようにしました。

これにより、エラーを確認する範囲が以前より絞られ、最低限Slackの通知だけチェックすれば良くなったため、運用負荷が大幅に軽減しました。また、急増エラーの通知により、実際に障害を早期発見できたこともありました。

こういった取り組みを経て、現在私のチームでのSentryの運用は次のようになっています。

日ごとの当番制を導入し、ランダムで指名された人がエラーを確認する
当番は以下を行う
- その日Slackに通知されたエラーを全て確認し、SlackのスレッドおよびSentryのActivityに調査ログを残す
- 一週間のエラー一覧を確認し、エラー数の推移を見て気になるものがあればそれも確認する
急増エラーは、当番に限らず気づいた人が即時対応する