第25回: Sentry連携の実運用 — エラー通知で満足していませんか？

(Updated: )
1 min read

章: 第8章: パフォーマンスと本番運用実践

「Sentry を入れたのに、アラートが多すぎて見なくなった」

Sentry を導入したものの、通知が大量に飛んできて結局スルーしている——こういった状況になっていませんか？

エラーが届いても「どの環境で」「どのリリースで」「誰に影響があったのか」がすぐに分からなければ、対応の優先順位が立てられません。Sentry の真価はエラー受信ではなく、タグ設計によるトリアージの効率化にあります。

問題の本質と解決策

問題: タグやユーザー情報を設定していないと、同種エラーのグルーピングができず、影響範囲の把握に時間がかかります。

解決策: configureScope で環境名・リリース番号・ユーザーIDをタグとして付与します。これにより、エラーが届いた瞬間に「どの環境の、どのバージョンの、誰の問題か」が分かり、対応優先度を即座に判断できます。

タグなし vs タグあり 比較

観点 タグなし タグあり（env・release・user）
影響範囲の把握 ログを手動で確認 即座に絞り込み可能
同種エラーの集約 手作業でグルーピング 自動でまとまる
優先度判断 勘に頼る データで判断できる
リリース起因の特定 デプロイ履歴と照合 タグで即座に判定

チェックポイント: env・release・user.id の3つはすべて設定されていますか？この3点セットがあるだけで、トリアージの速度が大きく変わります。

実装サンプル


<?php
\Sentry\configureScope(function (\Sentry\State\Scope $scope) use ($user, $release) {
    $scope->setTag('env', app()->environment());
    $scope->setTag('release', $release);
    $scope->setUser(['id' => (string) $user->id]);
});

\Sentry\captureMessage('決済連携でリトライ発生');

まとめ & 次のステップ

  • Sentry はエラー通知を受け取るだけでなく、タグ設計で真価を発揮します
  • env・release・user_id の3タグは必ず設定しましょう
  • 同種エラーのグルーピングにより、重複通知に惑わされなくなります
  • アラート通知量が多い場合は、フィルタルールを設定して重要度別に整理します
  • まず configureScope を AppServiceProvider の boot() に追加するところから始めましょう

次回は Pennantで機能フラグ運用 を学びます。新機能を安全に段階的リリースするための仕組みを解説します。

Related Articles