Sentryのデータ保持とエスカレーション通知の仕組みを完全理解する

はじめに

Sentryを運用していると、「3ヶ月前に通知が来たエラーが再度通知された」「数年前のFirst Seenが表示されているのに、古いイベントが見られない」といった疑問に遭遇することがあります。

本記事では、Sentryのデータ保持期間、エスカレーション通知、IssueとEventの関係について、実際の運用で役立つ知識を体系的に解説します。

目次

1. EventとIssueの違い
2. データ保持期間の仕組み
3. エスカレーション通知のタイミング
4. 90日ルールの具体例
5. よくある疑問と回答

EventとIssueの違い

基本概念

Sentryでは、エラーデータを2つの階層で管理しています:

Issue (集約・グループ)
  ├─ Event 1 (個別の発生)
  ├─ Event 2 (個別の発生)
  ├─ Event 3 (個別の発生)
  └─ Event 4 (個別の発生)

Event (イベント)

• 1回1回の実際のエラー発生
• スタックトレース、発生時刻、コンテキスト情報などの詳細データを含む
• 各Eventは個別に記録される

Issue (イシュー)

• 同じ種類のエラーの集約・グループ
• 同じフィンガープリント(fingerprint)を持つEventをまとめたもの
• First Seen、Last Seen、Events総数などのメタデータを保持

具体例

# 同じエラーが4回発生した場合

# 10月1日 10:00
raise ValueError("ユーザーIDが見つかりません")  # Event 1

# 10月1日 14:30  
raise ValueError("ユーザーIDが見つかりません")  # Event 2

# 10月2日 09:15
raise ValueError("ユーザーIDが見つかりません")  # Event 3

# 10月3日 11:00
raise ValueError("ユーザーIDが見つかりません")  # Event 4

Sentryの処理:

• 4つのEvent(個別のエラー発生)を検出
• 同じフィンガープリントに基づいて1つのIssueにグループ化
• 結果: 1つのIssueが生成され、Events (total): 4 と表示される

IssueとEventの比較表

項目	Issue (集約)	Event (個別)
何か	同じ種類のエラーのグループ	1回1回の実際のエラー発生
数	1つ	複数
保持期間	90日間活動がなければ削除	90日で削除
表示内容	First Seen, Last Seen, Events総数	スタックトレース、発生時刻、詳細情報
URL例	/issues/6920823465/	/issues/6920823465/events/

データ保持期間の仕組み

Sentryのデータ保持には2種類の異なるルールがあります。

1. 個別Eventデータの保持期間

プラン	保持期間
Free	30日
Team/Business	90日
Enterprise	カスタマイズ可能

削除される内容:

• スタックトレース
• コンテキスト情報
• 個別のエラー発生記録
• イベントの詳細データ

2. Issue(集約)の保持期間

ルール: 90日間新しいEventが発生しない場合、Issue全体が削除される

削除される内容:

• Issue自体
• First Seen / Last Seen などのメタデータ
• 関連する全てのEvent

データ保持の実態

例: 有料プラン(90日保持)の場合

タイムライン:
├─ 2022年1月: エラーAが初めて発生
│   → Issue作成 (First Seen: 2022/01/01)
│
├─ 2022年4月: 90日経過
│   → 2022年1月のEvent詳細は削除される
│   → しかしIssue自体は残る (First Seen: 2022/01/01 のまま)
│
├─ 2022年〜2025年: 定期的にエラーが発生
│   → Last Seenが更新され続ける
│   → Issue自体は削除されない
│
└─ 2025年10月: 現在
    → First Seen: 2022/01/01 と表示される
    → ただし、2025年7月以前のEvent詳細は見られない

保持されるもの・削除されるもの

90日後も保持される (Issueが生き続ける限り)

✅ First Seen (初回検出日時)
✅ Last Seen (最終検出日時)
✅ Events総数 (累計)
✅ 影響を受けたユーザー数
✅ Issue IDとURL

90日後に削除される

❌ 個別Eventのスタックトレース
❌ 個別Eventの詳細情報
❌ 90日以上前のEventレコード

Issue全体が削除される条件

❌ 90日間、新しいEventが1回も発生しない
→ Issue自体が完全に削除される
→ 次に同じエラーが発生すると「新しいIssue」として扱われる

エスカレーション通知のタイミング

1. Alert Ruleの「Action Interval」(再通知間隔)

同じIssueに対してアラートが再度トリガーされるまでの時間を設定できます。

設定可能な値:

• 最短: 5分
• 最長: 30日

選択肢:

• 1分、5分、15分
• 1時間
• 1日、1週間、30日

動作:

• 一度アラートを受信すると、同じIssueについては設定した時間が経過するまで再度アラートが送信されない
• 複数の異なるIssueが同時にトリガー条件を満たした場合は、全てのIssueについてアラートが送信される

2. Escalating Issues(エスカレーティングissue)

概要:
Archived(アーカイブ)されたIssueについて、前週のイベント数と比較して大幅にイベント数が増加した場合、自動的に「Escalating」状態になり、「Unresolved」タブに再表示されます。

エスカレーション判定:

• Issueが7日以上経過している場合、エスカレーション判定は日次で行われる
• スパイクリミットまたはバースト制限のいずれか高い方が適用される

3. Regressed Issues(回帰issue)

動作:

• Resolveしたissueで新しいエラーが発生すると「Regressed」状態になる
• 回帰を検出してから7日後に「Ongoing」状態に移行する

「3ヶ月後に再通知が来る」現象の正体

多くのユーザーが体験する「3ヶ月(約90日)後に再度通知が来る」現象は、以下のメカニズムによるものです:

シナリオ:
1. エラーAが発生 → Issue作成
2. 何もアクションを取らない(Resolve/Archiveしない)
3. 90日間、エラーAが発生しない
4. 90日経過 → Issue自体が削除される
5. 91日目にエラーAが再発生
6. Sentryが「新しいIssue」として検出
7. 「A new issue is created」トリガーで通知が送られる

重要なポイント:

• これは再通知ではなく、新しいIssueとしての初回通知
• 過去のFirst Seenやイベント履歴は引き継がれない
• Issue IDも新しくなる

90日ルールの具体例

ケース1: 定期的に発生するエラー

Issue A: 20日毎にEventが発生

2022年1月: Event発生 (First Seen記録)
2022年1月下旬: Event発生
2022年2月中旬: Event発生
2022年3月上旬: Event発生
...
2025年10月: Event発生 (Last Seen更新)

結果:
✅ Issue A自体は存在し続ける (90日間空かないため)
✅ First Seen: 2022年1月 と表示される
✅ Events (total): 数百件 (全期間の累計)
❌ ただし、2025年7月以前のEvent詳細は閲覧不可

ケース2: 散発的に発生するエラー

Issue B: 不定期に発生

2024年1月: Event発生 (First Seen記録)
2024年5月: 100日以上経過、Issue削除される
2024年6月: 再びEvent発生
         → 新しいIssueとして検出
         → First Seen: 2024年6月 となる
         → 過去のデータは引き継がれない

ケース3: Activityの更新では延長されない

Issue C: 手動操作を行った場合

2024年1月: Event発生
2024年3月: コメントを追加
2024年4月: Assigneeを変更
2024年5月: 90日経過 → Issue削除される

重要: 
❌ コメント追加では延長されない
❌ Assignment変更では延長されない
❌ Bookmarkでは延長されない
✅ 新しいEventの発生のみが「活動」としてカウントされる

よくある疑問と回答

Q1: 「First Seen: 3年前」なのに、古いEventが見られないのはなぜ?

A: これは正常な動作です。

• Issueのメタデータ(First Seen, Last Seen, Events総数)は、Issueが存在する限り保持される
• 個別Eventの詳細は90日で削除される
• そのため、数年前から存在するIssueでも、閲覧できるEventは最近90日分のみ

Q2: Action Intervalを設定すれば、定期的に通知を受け取れる?

A: いいえ、Action Intervalは「再通知の最小間隔」であり、自動的に定期通知を送る機能ではありません。

• Action Intervalは、同じIssueで条件が満たされた場合の通知間隔を制御する
• 定期的に通知を受け取りたい場合は、別途Metric Alertを設定する必要がある

Q3: 90日間発生しなかったエラーが再発した場合、過去のデータは引き継がれる?

A: いいえ、引き継がれません。

• 90日間Eventが発生しないと、Issue自体が削除される
• 再発時は完全に新しいIssueとして扱われる
• First Seen、Events総数なども全てリセットされる

Q4: Issueを手動でResolveやArchiveすると、90日ルールはどうなる?

A: どのStatusでも90日間Eventが発生しなければIssueは削除されます。

重要なポイント:

• Resolve、Archive、Archive Foreverのいずれも、90日ルールからは逃れられません
• これらのStatusは「通知の制御」や「表示の整理」が目的であり、「Issue保持期間の延長」ではありません

各Statusの動作:

Resolve:

• 新しいEventが発生すると「Regressed」状態になる(通知あり)
• 90日間Eventが発生しなければ → Issue削除

Archive (until escalating):

• 新しいEventが大量に発生すると「Escalating」状態になる(通知あり)
• 90日間Eventが発生しなければ → Issue削除

Archive Forever:

• 新しいEventが発生しても、Escalatingにならない(通知なし)
• Eventは記録され続ける
• 90日間Eventが発生しなければ → Issue削除

まとめ:

全てのStatusに共通: 90日間Event無し = Issue削除

Unresolved → 90日間Event無し → 削除
Resolved   → 90日間Event無し → 削除
Archived   → 90日間Event無し → 削除

Q5: Events (total)の数と、All Eventsタブの数が一致しないのはなぜ?

A: Events (total)は全期間の累計、All Eventsタブは現在閲覧可能なEventの数です。

例:
Events (total): 1,000件 (全期間の累計)
All Events tab: 50件 (最近90日分のみ)

90日より古いEventは削除されているため、全てのEventを閲覧することはできません。

Q6: データ保持期間を90日より長くできる?

A: Enterpriseプランであれば可能です。

• Free: 30日(固定)
• Team/Business: 90日(固定)
• Enterprise: カスタマイズ可能(要契約)

セルフホスト版では、SENTRY_EVENT_RETENTION_DAYS環境変数で変更可能ですが、データベース容量に注意が必要です。

まとめ

重要なポイント

1. EventとIssueは別物

   • Event = 個別の発生
   • Issue = 同じエラーの集約

2. 2つの90日ルール

   • 個別Eventの詳細: 90日で削除
   • Issue全体: 90日間Eventが発生しないと削除

3. Issueの保持条件

   • 全てのStatus(Unresolved/Resolved/Archived)で共通: 90日間Eventが発生しないとIssue削除
   • Issue Statusの変更では90日ルールを回避できない
   • コメントやAssignment変更でも延長されない
   • 唯一の延命方法: 90日以内に1回でもEventが発生すること

4. 「数年前のFirst Seen」が表示される理由

   • 定期的にEventが発生している(90日間空かない)
   • Issueのメタデータは保持される
   • ただし古いEventの詳細は見られない

5. エスカレーション通知

   • Action Interval: 5分〜30日で設定可能
   • 90日ルールとは別の概念
   • 90日後の再通知は、Issue削除→再作成による「新規Issue通知」

運用上の推奨事項

1. 90日ルールの理解

   • 重要: Unresolved、Resolved、Archivedに関わらず、90日間Eventが発生しないIssueは削除される
   • Issue Statusの変更では、90日ルールは回避できない
   • 長期保管が必要な場合は、必ずデータをエクスポートする

2. Alert Ruleの適切な設定

   • Action Intervalを業務に合わせて設定
   • 頻度の高いエラーは閾値を設定して通知を制御
   • 散発的なエラーは90日後に新規Issueとして通知される可能性がある

3. Issue Statusの活用目的

   • Archive: 通知を停止するが、Eventは記録し続ける(escalatingにならない限り)
   • Resolve: 修正済みとマーク(再発時にRegressionとして通知)
   • Archive Forever: 通知を完全に停止するが、Eventは記録し続ける
   • 注意: いずれのStatusでも90日間Eventが発生しないとIssue削除

4. データのエクスポート

   • 長期保管が必要な重要なエラー情報は、定期的にエクスポート
   • Sentry APIを使った自動化も検討
   • 90日以上Eventが発生しない可能性があるIssueは、特に注意してエクスポート

参考資料

• Sentry Documentation - Data Retention Periods
• Sentry Documentation - Issue Alert Configuration
• Sentry Documentation - Escalating Issues Algorithm
• Sentry Documentation - Issue Status

おわりに

Sentryのデータ保持とエスカレーション通知の仕組みを理解することで、より効果的なエラー監視が可能になります。特に90日ルールは、運用において重要な要素ですので、ぜひ本記事を参考にしてください。

ご質問やフィードバックがあれば、コメント欄でお知らせください!