こんにちは！開発チームの守り神、そして夜中の無駄なアラートに怯えないための「攻めのオブザーバビリティ」を布教している先輩エンジニアです。
日々の開発、本当にお疲れ様です。
ふと聞くけれど、あなたのチームではこんな「監視の罠」にハマっていませんか？
- 「エラーが発生しました！」というSlack通知が毎秒飛んできて、どれが本当に緊急かわからない。
- 「なんかサイトが重い気がする…」とユーザーから指摘されて初めて、特定のAPIの遅延に気づく。
- 夜中にPagerDutyが鳴り響いたけど、起き上がって調べたら数分で勝手に直っていた「ノイズ」だった。
……心当たり、ありますよね。これ、全部「ただエラーログを流し見しているだけ」の古い監視体制が原因です。
現代のオブザーバビリティにおいて、エラーは「起きたこと（事実）」でしかありません。本当に重要なのは、「エラーの発生率が急増していないか」「ユーザー体験を損なうほどのレイテンシ（遅延）になっていないか」を文脈（トランザクション）と一緒に捉えることです。
今回は、Sentryが誇る最強の武器「Metric Alerts（メトリックアラート）」を使いこなし、ノイズゼロで「本当に対応が必要な異常」だけをキャッチする方法を、基礎から優しく、かつ骨太に解説していきます。
これをマスターすれば、毎日のオンコール当番が劇的に楽になりますよ。さあ、一緒に扉を開けましょう！
—
1. なぜ「エラー件数」の通知だけでは不十分なのか？
初心者のうちは、「エラーが1件起きたらSlackに通知する」という設定をしがちです。しかし、これには決定的な欠陥があります。
1. ノイズの嵐: 軽微な404エラーや、リトライで即座に回復する一時的なネットワークエラーでも容赦なく通知が飛ぶため、エンジニアが「通知疲れ」を起こして本当に重要なアラートを見落とす。
2. 量の変化を見落とす: 「いつもは1日数件のエラーが、急に1分間に500件に跳ね上がった」という速度（Rate）の異常を、単体エラーの通知では検知できない。
3. 遅延（パフォーマンス）との相関が見えない: エラーは出ていなくても、「APIのレスポンスが普段は50msなのに、DBのロック競合で3秒に跳ね上がっている」という異常は、エラーログだけでは絶対に気づけない。
ここで登場するのが Sentry Metric Alerts です。
Metric Alertsは、Sentryが集計する数値を「メトリック（指標）」として捉え、「エラーの発生レート（割合）」や「APIの応答速度（P95レイテンシ）」をベースにしきい値監視できる機能です。
—
2. 基礎セットアップ：Sentryでメトリックを計測する
Metric Alertsを有効にするには、まずあなたのアプリケーションがSentryに対して「トランザクション（APIのリクエストなど）」と「エラー」を正しく送信できている必要があります。
ここでは、最も一般的なNode.js（Express）を例に、精度高い「Hello World」的な最小限のセットアップを見ていきましょう。
ステップ1: SDKのインストールと初期化
まずはSentryのSDKをインストールします。
npm install –save @sentry/node
そして、アプリケーションのエントリーポイント（例: `app.js`）で初期化を行います。ここで重要なのは、パフォーマンスモニタリング（Tracing）のサンプリングレートを設定することです。これがメトリックの土台になります。
const Sentry = require(“@sentry/node”);
const express = require(“express”);
const app = express();
// Sentryの初期化（これがすべての基本です）
Sentry.init({
dsn: “YOUR_SENTRY_DSN_HERE”, // あなたのSentryプロジェクトのDSNを指定
// パフォーマンスモニタリングを有効化（1.0は100%サンプリング。本番では0.1〜0.2を推奨）
tracesSampleRate: 1.0,
environment: “production”, // 環境名を明確に分けるのがプロの技
});
// 1. リクエストの監視を開始するミドルウェア（必ず最初に置く）
app.use(Sentry.Handlers.requestHandler());
app.use(Sentry.Handlers.tracingHandler());
// — テスト用のAPIエンドポイント（HelloWorld） —
app.get(“/api/greet”, (req, res) => {
// わざと遅延を発生させるシミュレーション（あとでレイテンシ監視のテストに使います）
const isSlow = req.query.slow === “true”;
if (isSlow) {
setTimeout(() => {
res.json({ message: “Hello from a slow world…” });
}, 2000); // 2秒待つ
} else {
res.json({ message: “Hello, Sentry Metric Alerts!” });
}
});
// 意図的なエラーを発生させるエンドポイント
app.get(“/api/error”, (req, res) => {
throw new Error(“💥 データベース接続がタイムアウトしました！”);
});
// 2. エラーハンドラー（必ずルート定義の「後」、他のミドルウェアの「前」に置く）
app.use(Sentry.Handlers.errorHandler());
// サーバー起動
app.listen(3000, () => {
console.log(“Server is running on port 3000”);
});
ここまでで、Sentryへトランザクション（APIの実行時間）とエラーが飛ぶ基盤が整いました。
—
3. 実践！「エラーレート急増」と「APIレイテンシ異常」を検知するMetric Alertsの設定
いよいよ本丸です。Sentryのダッシュボードから、ノイズのない洗練されたアラートを作っていきましょう。
Sentryのサイドメニューから [Alerts] -> [Create Alert] を選択し、[Metric Alert] を選びます。
ケースA：エラーレートの急増を検知する
「単純にエラーが1件起きたら」ではなく、「全トランザクションに対するエラーの割合（Error Rate）が、一定数を超えたら」通知する設定を作ります。
1. Define the metric:
- Apdex / Count / Percentage の中から、今回は `Percentage`（割合）を選択。
- The rate of `transactions` that are `errors` （トランザクションのうちエラーであるものの割合）を指定します。
2. Filter:
- 特定の重要機能に絞りたい場合は、`transaction.op:http.server` や `environment:production` などのタグで絞り込みます。
3. Set conditions (Thresholds):
- Alert when: `Above`
- Critical}: `5%` 以上 （過去5分間の平均で、トランザクションの5%以上がエラーになったら）
- Time Window: `5 minutes` （5分の移動平均で評価することで、一瞬のエラーバーストによる誤検知を防ぎます）
> 💡 先輩の知見:
> エラーの「絶対数（例: 10件）」で監視すると、アクセスが少ない深夜は気づかず、アクセスが爆発する昼間には無数のアラートが流れます。「割合（Percentage）」で見ることで、システムの健康状態を正確に測ることができます。
—
ケースB：特定のAPIレイテンシ異常（遅延）を検知する
次に、エラーすら起きずに「ただユーザーを待たせている」という最悪のケースを検知します。
1. Define the metric:
- メトリックに `Duration` を選択。
- 集計関数に `P95` (95パーセンタイル) を選びます（平均値だと一部の極端な遅延がかき消されてしまうため、P95やP99を使うのがプロの常道です）。
2. Filter (特定の重いエンドポイントに絞る):
- 例えば決済APIなど、絶対に遅くなっては困るエンドポイントを指定します。
- Filterに `transaction:/api/checkout` のようにパスを指定します。
3. Set conditions (Thresholds):
- Critical: `1000ms` （P95のレイテンシが1秒を超えた状態が継続した場合）
- Time Window: `10 minutes`
これで、「決済APIが重くなっている」というインシデントを、ユーザーからのクレームの前に自ら察知できるようになります。
—
4. PagerDuty / Slack 連携で「夜眠れるオンコール」を作る
アラートを作ったら、それをどこに飛ばすかが重要です。Sentryの [Actions] セクションで通知先を設定します。
- Slack / Microsoft Teams:
- 開発チームの日常的なチャンネルに飛ばします。ただし、Metric Alertsは「本当にやばい時」しか鳴らない設定にしているので、ここへの通知は「チーム全員で状況を把握する情報」として機能します。
- PagerDuty / Opsgenie (インシデント管理ツール):
- Criticalのしきい値を超えた場合のみ、PagerDutyへ連携します。
- これにより、深夜に無駄なアラートで叩き起こされることがなくなり、「本当にインシデントが発生し、対応が必要な時」だけにオンコール担当者を呼ぶことができます。
—
5. まとめ：オブザーバビリティの第一歩を踏み出そう
お疲れ様でした！今回はSentryの「Metric Alerts」を用いて、エラーレートの急増とAPIレイテンシの異常を複合的に監視する方法を解説しました。
- 単発のエラー通知から卒業し、比率（Rate）や統計値（P95）で監視する
- Time Window（時間窓）を使って、一時的なノイズを無視する
- Slack（日常共有）とPagerDuty（緊急対応）を使い分ける
この設計を取り入れるだけで、あなたのチームの運用品質は見違えるほど向上します。「アラートに振り回される毎日」から、「データに基づいて静かにシステムを守るエンジニア」へ。
さあ、今すぐあなたのSentryダッシュボードを開いて、最初のMetric Alertを設定してみましょう。毎日の作業が、そして夜の睡眠が、劇的に快適になりますよ！