Sentry Metric Alerts: 「なんとなくのアラート」を「殺意のある検知」へ変える極意
Sentryを単なる「エラーログの墓場」にしていないか？
「エラーが100件超えたら通知」という設定は、平時のノイズに埋もれ、深夜の緊急呼出を無意味にする。真のオブザーバビリティとは、「ユーザー体験が損なわれる瞬間」を数学的に定義し、システムが悲鳴を上げる前に外科手術のような対応を打つことにある。
本稿では、Sentryの「Metric Alerts」を使い倒し、ノイズを排して「真のインシデント」だけをPagerDutyへ流し込むための、戦術的な設計論を伝授する。
—
1. なぜ「Issue Alert」ではなく「Metric Alert」なのか？
`Issue Alert`は個別のスタックトレースに反応する。これは「事後の解析」には最高だが、「リアルタイムな障害検知」には向かない。Metric Alertsは、Sentryに送られるトランザクションやエラーを「時系列データ」として捉え、統計的に異常を検知する。
守るべき設計思想：
- Apdexの導入: 「エラーがない＝正常」ではない。レイテンシが閾値を超えたら「体験の崩壊」とみなせ。
- Moving Windowの活用: 瞬間的なスパイクでページャーを鳴らすな。5分移動平均（Moving Window）で「傾向」を叩け。
- Filterの徹底: `environment:production` は絶対条件。さらに `transaction.op:http.server` で絞り込み、純粋なAPI性能を監視せよ。
—
2. 現場で震えるほど役立つ「神設定」ベストプラクティス
ここでは、APIレイテンシの急増を検知する設定をJSON（Sentry API経由での設定イメージ）で公開する。
{
“name”: “CRITICAL: API Latency High (p95 > 500ms)”,
“dataset”: “transactions”,
“query”: “transaction.op:http.server p95(transaction.duration):>500”,
“timeWindow”: 5,
“thresholdType”: “above”,
“triggers”: [
{
“label”: “critical”,
“alertThreshold”: 500, // 500msを超えたら
“actions”: [
{ “type”: “pagerduty”, “targetIdentifier”: “your-pd-service-id” }
]
}
]
}
チーム開発における「設定共有化ルール」
SentryのUIでポチポチ設定するのは今日でやめろ。設定の不整合は最大の事故の温床だ。
1. Terraform/Pulumi化: Sentry Providerを使用し、監視設定をコードとしてリポジトリ管理せよ。
2. Naming Convention: アラート名には `[SEVERITY]: [DOMAIN]: [DESCRIPTION]` を強制する。
- 例: `[CRITICAL]: [CHECKOUT]: API Latency High`
3. Owner設定: 各アラートには必ず `CODEOWNERS` に紐づくチームを記述せよ。
—
3. 開発スピードを加速させる「極限のテクニック」
隠れたキーボードショートカット
Sentry画面でこれを使わないのは手足を縛って戦うのと同じだ。
- `Cmd + K` (Mac) / `Ctrl + K` (Win): Command Palette。プロジェクト切り替え、Issue検索、アラート設定への遷移を一瞬で終わらせろ。
- `?`: ショートカット一覧を即座に表示。まずはここから覚えろ。
絶対入れるべき「神プラグイン」
- Sentry GitHub Integration: これを入れずにPRを出してはならない。Issueの自動クローズ、PR内でのスタックトレース表示は開発のコンテキストスイッチを最小化する。
- Slack/PagerDuty Integration: 重要なのは「通知内容のカスタマイズ」。通知テンプレートをいじり、グラフのサムネイルと「誰が直すべきか（IssueOwner）」を直感的に表示させろ。
—
4. エラーレート急増を「論理的に」防ぐ
「エラー件数」で監視してはいけない。「エラー率（Error Rate）」で監視せよ。
トランザクション数が増えればエラー数も増えるのは当たり前だ。以下のクエリをMetric Alertに設定せよ。
/ 過去1時間と比較して、エラーレートが5%を超えたら発火 /
count_if(event.type:error) / count_if(event.type:transaction) :> 0.05
この設定により、「ユーザーは増えたがエラー率は一定」という健全な状態と、「コードデプロイ後にエラー率が急騰した」という異常状態を明確に切り分けられる。
—
5. 最後に：テックリードからの提言
オブザーバビリティとは、ツールを入れることではない。「何が起きれば障害なのか？」という問いに対し、チーム全員が同じ言語で答えられる状態を作ることだ。
SentryのMetric Alertsは、そのための強力な武器になる。
1. ノイズを殺せ（閾値をシビアに設定し、不要な通知を徹底排除）。
2. コンテキストを付与せよ（タグ付けを怠るな）。
3. 自動化せよ（設定をコード管理し、誰でも変更・監査できるようにせよ）。
明日から、君たちのSentryは「ログのゴミ箱」から「システムの健康を守る盾」へと進化するはずだ。現場のエンジニア諸君、健闘を祈る。