Sentry の運用を改善

はじめに

この記事はYAMAPアドベントカレンダー8日目の記事です。

https://qiita.com/advent-calendar/2023/yamap-engineers

こんにちは。YAMAP STOREというECサイトのフロントエンドエンジニアをやっているKentaroです。YAMAP STOREではエラー監視ツールに Sentry を用いています。今回YAMAP STOREでのSentryの運用について改善したことを紹介します。

課題

エラー監視にSentryを導入しているものの、いくつか課題がありました。

• エラー通知が多く、重大なエラーかどうかわかりづらい（オオカミ少年状態 🐺）
• エラー内容からの調査が難しい

重大なバグにすぐに気付け、エラー内容からの調査しやすいことが理想の状態です。このギャップを埋めるため、いくつか施策に取り組みました。

重大なバグに気付けるようにする

重大なバグに気付くには、未解決のエラーをできるだけ少なくしノイズを小さくすることが大事かと考えています。
以下の3点を取り組みました。

トリアージ

ノイズの改善にはトリアージ作業が重要になります。確立していなかったトリアージのワークフローを整備しました。
ステータスが Unresolved: ONGOING を0にすることは難しいですが、Unresolved: NEW のものを可能な限り0に保てる運用を考えました。
以前は for-review や unresolved、ignore といったステータス名でしたが、数ヶ月前に名前と仕組みが変更されました。
公式のIssue Status

トリアージの内容は以下になります。

• 対応する
  • Ongoing
  • issue化し、担当者をアサイン
• 先送り
  • 制限付きArchived
• 対応しない
  • Archived

制限付きArchivedは一定期間や一定回数到達といった条件が満たされるまでエラーを除外できます。重大な影響は与えていない、かつ、すぐには判断が難しいものにはこの先送りを適用します。また、SentryのEscalating機能により、短期間でエラーイベントが大幅に増加した場合には自動的にUnresolved: Escalatingに変更されます。

上記のトリアージを平日1回、担当者が行い、悩むものはチームで決めるという方針で進めています。
この運用により、ノイズとなるエラーを大幅に減らすことができ、NEWのエラーの見通しが良くなりました。

不要な通知はignoreする

通知されていたエラーにはそもそも不要なものが多々ありました。
ブラウザの拡張機能から発生するエラーやユーザーに影響ないと判断できるエラーは通知が来ないようにし、ノイズを減らしました。

Sentryには ignoreErrors というオプションがあります。文字列や正規表現を用いて不要なエラーをフィルタリングできます。

Sentry.init({
  ignoreErrors: [
    // ブラウザの拡張機能といった外的要因のエラーなど
  ]
});

通知数を削減できたことで、ノイズ低減だけでなくコスト面にも良い影響を与えました。

Slack へのアラート通知を制限

当初は発生したすべてのエラーをSlackに通知していましたが、不要なエラーが多い状態では形骸化し、結局誰も見ないような状態になっていました。
Sentryではアラートの通知条件を設定できます。Issue Alerts Best Practicesというドキュメントが用意されています。

多くの影響を与えているエラーのみ抽出できるよう、条件を「1分間に10回以上発生」に変更しました。この設定により、Slackへの通知 ≒ 比較的大きな影響と判断しやすくなり、重大なエラーを素早く気付けるようになりました。

エラー内容からの調査しやすくする

エラーの調査をしやすくするには情報を増やす、範囲を絞ることが大事だと考えています。
以下の3点を取り組みました。

Releases 機能の活用

Sentryにはリリースごとにエラーを確認できるReleasesという機能があります。
https://docs.sentry.io/product/releases/

この機能により、どのリリースのバージョンで起きたか監視しやすくなります。原因のスコープを絞ることができ、調査のしやすさが向上しました。

コンテキストを渡す

エラー調査の手がかりになる情報を増やすため、Sentryにコンテキストを渡すようにしました。
https://docs.sentry.io/platforms/javascript/enriching-events/context/

例えばSentryにエラーを送信する際、以下のように tags に情報を加えることで、エラー発生箇所の手がかりになります。

Sentry.captureException(new Error("something went wrong"), {
  tags: { section: "products" },
});

tags の他にも extra や contexts, user, level, fingerprint を渡すことが可能です。

Sentryのダッシュボード上で付与したコンテキストから絞り検索でき、調査に役立っています。

Session Replayの導入

上記の取り組みをしても、エラー内容から原因の特定・ユーザーへの影響がわからないものは多々あります。そこで、Session Replayを導入しました。

https://docs.sentry.io/product/session-replay/

Session Replayはユーザーの行動をビデオのように再現でき、エラーが発生する前後の様子を視覚的に確認できるツールです。実際は動画が取られている訳ではなく、DOMのスナップショットから作成されています。
DevToolsで見るような以下の情報を確認できるようになります。

• タイムライン
• ユーザの行動リプレイ
• console
• network
• Errors
• DOM Events
• Memory

Session Replayによってそのエラーがユーザーにどの程度影響を与えているのか視覚的に、素早く判断できるようになり、工数削減に繋がりました。
また、視覚的なツールでなければ気づけなかった不具合（例えばエラー時にユーザーに対して適切なアラートを提供できない）を発見できる効果もありました。

まとめ

Sentryの運用改善を進めた結果、以前と比べて重大なエラーに気が付きやすく、また調査も行いやすくなる状態に持っていくことができました。運用を改善しながら感じたことでは、Sentryには知らなかった機能が多くあり、新しい機能も日々増えていることでした。運用が継続できるよう、コスト小で効率の良い方法を今後も模索していきます。

参考

https://tech.classi.jp/entry/2021/03/26/115500

https://blog.studysapuri.jp/entry/2022/10/03/team-sentry-operation