はじめに

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層構造が、実運用で最もバランスの取れたアプローチだと考えます。

参考リンク