Sentryのissueトリアージとデバッグ知見の共有

概要

エラーモニタリングツールであるSentryにまつわる課題とその課題を解決するために試しているSentryの利用法や運用プロセスを紹介します。

Sentryは、エラーに関するタグベースのメタ情報やスタックトレースなどを用いてエラーを分析、通知、一元管理するのに便利な機能やSDKを提供します。また、パフォーマンスモニタリングやプロファイリングなど、運用にまつわる機能提供もスコープに入っています。しかし、Sentry自体の運用にも投資しなければ、つぎのような課題が生じ、良さを活かしきれません。

課題

自分が現在所属している組織に限らず、エラーモニタリングツールの運用課題として以下のようなものが挙げられます。

• 増えていくエラー通知をさばききれず対応しなくなる
• 重要なエラーが大量のエラー通知に埋もれて気づけない
• 何が重要なエラーなのか特定の人しか判断できず負荷が偏る

Sentryを利用する場合もこれらはあてはまります。これらの課題を根本的に解決するためには、エラーモニタリングツールだけでなく開発・運用フロー、組織、文化などさまざまな部分に働きかける必要があるでしょう。この記事では、Sentry自体の利用方法や運用に絞って取り組みを紹介します。

取り組み

Sentryの力を発揮させるためには、Sentryで通知されるエラーの定期的な棚卸し、閾値の適切な設定や必要十分な情報が通知されるための実装が大事と考えます。

定期的な棚卸し

エラーが通知されたとき、即座に対応する必要があるものもあれば、一時的なものや短期的には許容したいものがあります。いずれにしても、定期的にトリアージしなければSentry上にissueとしてたまり続ける一方です。自分が所属しているチームでは、週に一度30分、スクラムのレトロスペクティブ・プランニングをやる前にissueのトリアージを行うことにしました。

次のようなフローで行っています。

1. For Reviewセクションでissueトリアージ
   1. 修正対応すべきものは Mark Reviewed (All Unresolvedセクションに移動される)
   2. 許容できるものは1時間10回を基準に Ignore (Inogredセクションに移動される)
   3. 直近の修正で直る予定のものは Resolve (Issuedからはいったん消える)
2. エラー調査とチケット作成
3. All Unresolvedセクションの推移観察

1のFor Reviewセクションでissueトリアージでは、一貫した基準でissueの分類し、各issueに対するアクションをチームで判断します。対応しないにしても、チームとしての態度を明確にするのが重要です。サービス知識が豊富な一部のメンバーが対応不要と認識できていたとしても、そうでないメンバー含め通知による認知的負荷は増していく一方です。

このとき、実質同じissueをMergeしたり、スタックトレースベースで近いissueを探すSimilar Issues（ベータ機能で、期待した挙動でないときもある）を使うと便利です。Similar Issuesでは、スタックトレース同士のdiffを表示する機能も利用できます。

2のエラー調査とチケット作成では、For ReviewセクションでIssueトリアージで対応すべきと判断したIssueの一次調査とスプリントバックログのチケット起票を行います。ここでエラー調査を行う目的は2つです。

一つは、バックログチケット作成用の情報を得るためです。トリアージの後に行うスプリントプランニングで、チケットにストーリーポイントを振るためにざっくりとした調査を行い、チームで会話します。

もう一つは、デバッグやサービスに関する知見の共有です。詳しいメンバーがスタックトレースを基にソースコードを追ったり、トレースIDなどリクエストコンテキスト情報をキーにログサービスを検索したりすることで、後からサービス開発に参加した他のメンバー（自分）が実践的な題材で運用知見を得ることができます。トリアージを何週か繰り返すうちに、モブプログラミングでドライバーを交代するようにデバッグ主体を交代できるようになりました。

デバッグを見ているメンバーは、調査内容をチケットに記入します。文書化もまた知見の定着を促進します。このとき、作成したチケットをIssueのActivityに貼っておくと状況がより追いやすいです。

3のAll Unresolvedセクションの推移観察では、All Unresolvedセクションに移動させたIssueの数が極端に増えたり、修正以外の対応で解消したりしていないか確認します。極端に増えているようであればプランニング時の優先度を上げたり、解消した場合は原因を軽く追って Resolveします。

アラートの設定

アラートを実行する条件は、定期的なトリアージや調査への移行を下支えします。

どのタイミングで通知を行うか（ WHEN ）は、どんな選択肢があるのかを知る必要があります。

現在はサービス特性上 A new issue is created と The issue changes state from resolved to unresolved で十分運用できていますが、閾値設定なしには重要なエラーを追ったり、インパクトの評価が難しかったりします。

条件を満たしたときに実行される通知（ THEN ）では、Slackの場合タグをカスタマイズできることを知っておくと便利です。たとえば、リクエストを識別するためのIDなどログサービスを検索するキーを設定しておくと、通知後即座に調査に移れます。

アプリケーションの実装

Sentry関連のアプリケーション実装において大事に感じたのは、過剰に通知しないことと、必要な情報を追加することです。

現状すべてのエラーを通知する必要がないため、アプリケーション側でフィルタリングしています。原則アプリケーションサーバーへのリクエストが共通して通過する部分で、ステータスコードが500系の場合のみ通知されるように実装しています。

リクエストコンテキストの情報を追加するために、通知時にタグを付与しています。アラートの設定で紹介したリクエストを識別するためのIDなどは、タグとして実装しています。

まとめ

以上の運用上の工夫で、毎週IssuesのFor Reviewがなくなる状態を保っています。

プロセスを回していく上では、特に以下の3つが大事なように思います。

• 一定の判断基準・フローでやる
• 週次でやる
• チームでやる

一方で、冒頭の課題でも触れたように、エラーに対する運用を行うにはエラーモニタリングツールの活用だけではうまくいきません。運用上の工夫はできでも、運用単独でカバーしきるものではないです。今回紹介した運用も、場合によってはうまくいかない可能性があります。SREのプラクティスの実践や、ソフトウェアとしてよいアーキテクチャ・実装、プロダクトへのオーナーシップなど、ユーザーへの価値を絶え間なく届けるべく総合的によい状態にしていけたらと思います。