Sentryを「ただのエラーログ置き場」にするな：カスタムメトリクスでビジネスインパクトを可視化する神髄
Sentryを単なる「例外検知ツール」だと思っているなら、君は宝の山の上で砂遊びをしているようなものだ。
真のオブザーバビリティとは、「システムが壊れたこと」を知るのではなく、「壊れたことでビジネスがどう毀損したか」をリアルタイムで握ることにある。SentryのMetrics機能は、まさにその橋渡しをするための最強の武器だ。
今回は、SentryのStatsD互換メトリクスを使い、エラーとビジネス指標を同一タイムラインで相関させる「プロの運用術」を伝授する。
—
1. なぜ「ビジネスメトリクス」をSentryに集約すべきか
PrometheusやDatadogにメトリクスを投げているチームは多い。しかし、エラー発生時の「カート離脱率」や「決済失敗数」を、エラーログと同じコンテキスト（Trace IDやUser Context）で追いかけられるか？
Sentryにメトリクスを統合する最大のメリットは、「エラーとビジネス指標の相関を、タグ付けだけで瞬時に相関分析できる」点だ。
実践：カート離脱率をSentryで計測する（SDK設定）
Sentry SDKを使って、ビジネス指標をCounterとして送信する。
import sentry_sdk
Metricsは設定不要。SDKがStatsDプロトコルをラップして送信してくれる
def add_to_cart(item_id, user_id):
# カート追加をカウント
sentry_sdk.metrics.increment(
“cart.added”,
value=1,
tags={“item_id”: item_id}
)
def checkout_failed(error_code):
# 決済失敗をカウント。ここでエラーと紐づくタグを仕込む
sentry_sdk.metrics.increment(
“checkout.failed”,
value=1,
tags={“error_code”: error_code}
)
【プロの知見】
ここで重要なのは、`tags`の中に`release`や`environment`を自動付与させつつ、ビジネス固有の属性（`region`や`plan_type`）を混ぜることだ。これで「特定のプランユーザーだけ決済エラーが多い」といった、インフラメトリクスでは絶対に見えない相関が浮かび上がる。
—
2. 開発スピードを加速させる「神速」Tips
開発現場で震えるほど役立つショートカット
SentryのUIをマウスで操作しているエンジニアを見ると、私はため息が出る。
- `Cmd + K` (Mac) / `Ctrl + K` (Win): コマンドパレット。プロジェクト移動、Issue検索、何でもここから。
- `Shift + ?`: 全ショートカットキーのリスト。これを暗記するだけで作業効率は2倍になる。
- `J` / `K`: Issueリストの上下移動。爆速でトリアージするなら必須。
絶対に入れるべき「神プラグイン/設定」
- Sentry CLIのCI/CD統合: `sentry-cli releases set-commits` を必ず叩け。誰のどのコミットがエラーの原因か、ログを追わずに画面上で特定できる。これができないチームは、エラー調査に一生時間を浪費する。
- CODEOWNERS連携: Sentryの設定で`CODEOWNERS`を読み込ませろ。エラーが発生した瞬間、担当チームに自動でメンションが飛ぶ。これだけで心理的安全性と責任の所在が明確になる。
—
3. 実用的な `sentry.client.config` (ベストプラクティス)
チームで共通化すべき設定は、コードベースの直下に `sentry_config.yaml` として管理し、環境変数と注入するのが定石だ。
プロジェクト全体で一貫性を持たせるための設定例
dsn: ${SENTRY_DSN}
traces_sample_rate: 0.1 # 本番環境は0.1程度から開始し、ビジネス影響度に応じて調整
profiles_sample_rate: 0.05 # プロファイリングはCPU負荷を考慮し慎重に
重要なタグの強制付与（インフラとビジネスの相関用）
before_send: |
def before_send(event, hint):
# PII（個人情報）のマスキングを自動化
if ‘user’ in event:
event[‘user’].pop(‘email’, None)
return event
重要なメトリクスだけをサンプリングせずに送る設定など（SDK仕様に依存）
metrics_summary_flush_interval: 10
—
4. 現場のテックリードへ：チーム開発の「掟」
1. 「無視するエラー」に名前をつけろ:
Sentryの「Discard Rule」を使い、既知のノイズは即座に捨てろ。ノイズが放置されたダッシュボードは、誰も見なくなる。ゴミのない監視画面こそが、エンジニアの集中力を守る。
2. アラートは「アクション」とセットで:
「エラーが出た」だけの通知は無意味だ。アラート通知（Slack/PagerDuty）には必ず「原因特定用のダッシュボードへのリンク」と「直近のデプロイ履歴」を自動で添付しろ。
3. ビジネスメトリクスをKPIに含めろ:
月次の振り返りで「今月発生したエラー数」だけでなく「決済失敗による機会損失額（メトリクスから算出）」を報告しろ。経営陣を巻き込むオブザーバビリティこそが、エンジニアの地位を向上させる。
最後に
Sentryは単なるエラーバケツではない。システムという生命体の「健康状態」と「ビジネスの血流」の両方を可視化する心電図だ。
今日から、コードの中に「ビジネスの鼓動」を刻むメトリクスを仕込んでほしい。障害が起きたとき、慌てふためいてログを漁るのではなく、静かにダッシュボードを見て「ビジネスへの影響は最小限だ。ここを直せばいい」と断言できる君たちを待っている。
さあ、計測を始めよう。What gets measured, gets managed.