はじめに
IBM Instanaの Application Perspective における Smart Alert は、アプリケーションの異常を自動検出するための強力な機能です。しかし、Scopeの設定には3つの選択肢があり、「どれを選ぶべきか」「PoCと本番で使い分けるべきか」で迷う方も多いのではないでしょうか。
本記事では、Erroneous Calls（エラーコール）をStatic Thresholdで監視するケースを例に、3つのScopeの違いと、PoC→本番運用への段階的なアプローチを解説します。
対象読者
- Instanaを導入・検証中のSRE / DevOpsエンジニア
- Smart Alertの設定で「Scopeをどうするか」迷っている方
- PoCから本番へのアラート設計戦略を知りたい方
前提条件
- IBM Instana のApplication Perspectiveが構成済みであること
- Smart Alertの基本的なUI操作を理解していること
検証環境
本記事では「sakura」というApplication Perspectiveを使用します。このアプリは以下の5つのサービスで構成されています。
| サービス名 | 役割 |
|---|---|
| sakura-ratings | レーティングサービス |
| sakura-cart | カートサービス |
| sakura-catalogue | カタログサービス |
| sakura-discount | ディスカウントサービス |
| MySQL@3306 | データベース |
Smart Alertの共通設定は以下の通りです。
| 項目 | 設定値 |
|---|---|
| Blueprint | Erroneous Calls |
| Threshold Type | Static |
| Metric | Error Rate |
| Warning | ≥ 5% |
| Critical | ≥ 20% |
| Calls | Inbound calls |
Smart Alert の Scope とは
Smart Alertの設定画面で「Scope: Where is the condition happening?」というセクションがあります。
ここでは、Individual alerts として以下の3つの選択肢が提供されます。
- for this application perspective — アプリケーション全体
- per service for this application perspective — サービス単位
- per endpoint for this application perspective — エンドポイント単位
この選択によって、「何を1単位として集計し、閾値を評価するか」が根本的に変わります。
3つのScopeの違い
1. for this application perspective（アプリ全体）
Application Perspective配下の全サービス・全エンドポイントのコールを1つの集計値にまとめて、閾値を評価します。
sakura（全体）
├── sakura-ratings の全コール ─┐
├── sakura-cart の全コール ─┤
├── sakura-catalogue の全コール─┼─→ 全体を1つに集約 → Error Rate算出 → 閾値評価
├── sakura-discount の全コール─┤
└── MySQL の全コール ─┘
→ 閾値超過時：アラート1件
特徴：
- アラートは最大1件。「アプリ全体が異常かどうか」がわかる
- 個別サービスの局所障害が他サービスのトラフィックに薄められて検出されない可能性がある
- 例：sakura-cart だけError Rate 50%でも、全体トラフィックが多ければ全体のError Rateは5%に達しないことがある
ユースケース： アプリ全体のユーザー体験が劣化しているかを俯瞰的に把握したい場合。
2. per service for this application perspective（サービス単位）
各サービスごとに独立してError Rateを計算し、閾値を個別に評価します。
sakura
├── sakura-ratings → Error Rate算出 → 閾値評価 → 超過時：アラート①
├── sakura-cart → Error Rate算出 → 閾値評価 → 超過時：アラート②
├── sakura-catalogue → Error Rate算出 → 閾値評価 → 超過時：アラート③
├── sakura-discount → Error Rate算出 → 閾値評価 → 超過時：アラート④
└── MySQL → Error Rate算出 → 閾値評価 → 超過時：アラート⑤
特徴：
- 障害サービスごとに個別のアラート通知が発行される
- アラートタイトルに
${service.name}プレースホルダーが使えるため、通知の時点でどのサービスか即座に特定できる - 個別サービスの障害が他サービスに薄められることがない
ユースケース： 障害発生時に「どのサービスで問題が起きているか」を即座に切り分けたい場合。
3. per endpoint for this application perspective（エンドポイント単位）
各サービスの中の個々のエンドポイントそれぞれについてError Rateを独立して計算・評価します。
sakura
├── sakura-cart
│ ├── POST /cart/add → Error Rate算出 → 閾値評価 → アラート
│ ├── GET /cart/items → Error Rate算出 → 閾値評価 → アラート
│ └── POST /cart/checkout → Error Rate算出 → 閾値評価 → アラート
├── sakura-catalogue
│ ├── GET /catalogue → Error Rate算出 → 閾値評価 → アラート
│ └── GET /catalogue/{id} → Error Rate算出 → 閾値評価 → アラート
└── ... 以下同様
特徴：
- 最も細かい粒度で障害をピンポイント検出可能
- エンドポイント数が多いと大量のアラートが発生する可能性がある
- Adaptive Thresholdが使えない（Static Thresholdのみ）
- アラートタイトルに
${endpoint.name}が使える
ユースケース： 決済APIやログインAPIなど、ビジネスクリティカルなエンドポイントを個別監視したい場合。
比較表
| 観点 | for this AP（全体） | per service | per endpoint |
|---|---|---|---|
| 集計粒度 | 全コールを1つに集計 | サービスごと | エンドポイントごと |
| アラート通知数 | 最大1件 | 障害サービス数分 | 障害エンドポイント数分 |
| 局所障害の検出 | 薄まるリスクあり | サービスレベルで検出 | ピンポイント検出 |
| ノイズ量 | 最小 | 中程度 | 最大 |
| Adaptive Threshold | ✅ 利用可能 | ✅ 利用可能 | ❌ 利用不可 |
| Titleのplaceholder | ${application.name} |
+ ${service.name}
|
+ ${endpoint.name}
|
| 運用負荷 | 最小 | 中程度 | 要チューニング |
PoC → 本番運用への段階的アプローチ
Phase 1: PoC / 初期導入 — アプリ全体から始める
推奨Scope: for this application perspective
PoCの段階では、各サービスの「正常なError Rate」のベースラインがまだわかりません。いきなりper serviceやper endpointに設定すると、閾値の妥当性を判断する基準がないまま、アラートの嵐に見舞われる可能性があります。
まずアプリ全体で「このアプリケーションの正常な状態とは何か」を把握するフェーズと位置づけます。
この段階でやるべきこと：
- Static Threshold で Warning 5% / Critical 20% をスタート地点として設定
- Smart Alert設定画面のPreview Chart（Last 24 Hours / Last 7 Days）で、過去データに対して閾値が妥当か確認
- アラート通知のAlert Channelを設定し、通知フローの動作確認を行う
Phase 2: サービス構造の理解後 — per service を追加
推奨Scope: per service for this application perspective（追加）
Dependencies画面で各サービスの依存関係とトラフィック特性が見えてきたら、Phase 1のアプリ全体アラートは残したまま、per serviceのSmart Alertを追加します。
重要なポイント：
- 全サービスに一律同じ閾値を適用するのではなく、サービス特性に応じて閾値を調整することを検討する
- アラートタイトルに
${service.name}を含めて、通知時に即座にサービスを特定できるようにする
サービス特性に応じた閾値設計の例を以下に示します。
| サービス | 特性 | Warning | Critical |
|---|---|---|---|
| sakura-cart | ユーザー操作直結、エラーは致命的 | 3% | 10% |
| sakura-catalogue | 参照系、多少のエラーは許容 | 5% | 20% |
| sakura-discount | 外部API依存、一時的エラーが起きやすい | 10% | 30% |
| MySQL | DB直接アクセス、エラーは通常ゼロに近い | 1% | 5% |
この段階では2層構造で運用します。
- 第1層（Phase 1）: アプリ全体 → 「ユーザー影響の俯瞰」
- 第2層（Phase 2）: per service → 「障害箇所の特定」
Phase 3: 本番安定運用後 — クリティカルなエンドポイントのみ per endpoint を追加
推奨Scope: per endpoint for this application perspective（限定的に追加）
十分なトラフィックデータが蓄積された後、ビジネスクリティカルなエンドポイントに限定して per endpointを追加します。
全エンドポイントにper endpointを設定するのはノイズが多すぎるため非推奨です。
per endpointの対象として推奨されるエンドポイント例：
- 決済処理（
POST /cart/checkout） - ユーザー認証（
POST /auth/login） - 注文確定（
POST /orders）
最終的な本番運用の推奨構成
┌─────────────────────────────────────────────────────┐
│ 第1層: for this application perspective（俯瞰） │
│ - アプリ全体の健全性 │
│ - Error Rate Warning 5% / Critical 20% │
│ - Adaptive Threshold の活用も検討 │
│ - 通知先: Slack全体チャンネル + PagerDuty │
│ - 対象: 経営層・SREチーム │
├─────────────────────────────────────────────────────┤
│ 第2層: per service（障害切り分け） │
│ - サービス単位の障害検出 │
│ - サービス特性に応じた個別閾値 │
│ - ${service.name} をタイトルに含める │
│ - 通知先: 担当チーム別Slackチャンネル │
│ - 対象: オンコールエンジニア │
├─────────────────────────────────────────────────────┤
│ 第3層: per endpoint（ピンポイント） ※限定的 │
│ - ビジネスクリティカルなエンドポイントのみ │
│ - 決済・認証・注文確定など │
│ - 通知先: PagerDuty直接エスカレーション │
│ - 対象: 該当サービスの開発チーム │
└─────────────────────────────────────────────────────┘
Alert Channel設計のTips
Smart Alertでは、WarningとCriticalで異なるAlert Channelを設定できます。これを活用して、以下のような通知設計が効果的です。
| Severity | 通知先 | 期待するアクション |
|---|---|---|
| Warning | Slackチャンネル | 状況認識・調査開始 |
| Critical | PagerDuty + Slack | 即座にインシデント対応 |
Terraform による管理
本番環境では、Smart Alert設定をコードとして管理することを強く推奨します。Instanaは Terraform Provider を提供しており、Smart Alertの設定をIaCで管理可能です。
resource "instana_application_alert_config" "sakura_erroneous_per_service" {
name = "$${application.name} - $${service.name} erroneous call alert"
application_id = instana_application_config.sakura.id
alert_evaluation_type = "PER_AP_SERVICE"
rule {
erroneous_calls {
metric = "ERROR_RATE"
aggregation = "SUM"
}
}
threshold {
static {
operator = ">="
value = 5.0
}
}
# ... 以下省略
}
まとめ
| フェーズ | 推奨Scope | 目的 |
|---|---|---|
| PoC / 初期導入 | for this application perspective | ベースライン把握 |
| サービス理解後 | + per service | 障害箇所の特定 |
| 本番安定運用 | + per endpoint（限定的） | クリティカルAPI監視 |
Smart AlertのScopeは「最初から最も細かい粒度にすればよい」というものではありません。段階的にScopeを広げていくことで、アラートの精度を高めつつ、運用チームのノイズ耐性を超えないバランスを保つことが重要です。
最初はアプリ全体のScopeで「正常とは何か」を学び、サービス構造の理解が深まったらper serviceで障害切り分けを可能にし、最終的にビジネスインパクトの大きいエンドポイントだけをper endpointで監視する。この3層構造が、実運用で最もバランスの取れたアプローチだと考えます。