はじめに
Observability製品と生成AIを組み合わせた運用支援を目にする機会が増えてきた。
「AIが障害調査を支援する」と説明されることは多い。しかし、実際にAIが何を見ているのかは分かりにくい。
Instanaの画面を見ているのか。
トレースやログを直接読んでいるのか。
それとも、内部で何らかの診断を行っているのか。
今回は、IBM BobとInstana MCPを接続し、BobからObservabilityデータを調べてみた。
確認したのは次の点だ。
- サービス別のアクセス数を取得できるか
- コール数、レイテンシ、エラー率をまとめて確認できるか
- イベントやトレースを調査に利用できるか
- 原因候補の整理に使えるか
- 利用時にどのような制約があるか
なお、本記事は特定の顧客環境や案件事例を紹介するものではない。業務上の技術検証で得た知見を、検証環境およびサンプルアプリ上で再確認し、一般化した内容である。
まずInstana MCPが何をしているのかを確認した
最初に気になったのは、Bobが何を根拠に回答しているのかという点だった。
今回の構成は次のようになる。
IBM Bob
↓
Instana MCP
↓
Instana API
↓
Observability Data
BobがInstanaの画面を直接見ているわけではない。
Instana MCPを介してInstanaのAPIを呼び出し、メトリクス、トレース、イベントなどのObservabilityデータを取得する。その取得結果をBobが整理して回答する。
つまり、利用者は自然言語で質問しているが、その裏側ではInstanaのAPIに渡す条件が組み立てられている。
まずは、単純なメトリクス取得から試すことにした。
サービス別アクセス数を調べてみた
最初に試したのは、アプリケーションのアクセス状況だった。
Bobに次のように入力した。
〇〇アプリケーションの直近1時間のアクセス数を、サービス別に調べなさい。
BobはInstana MCPを通じて、アプリケーションを構成するサービスごとのコール数を取得した。
MCP呼び出しの主要な条件は次のようになる。
resource_type = "metrics"
operation = "application"
groupbyTag = "service.name"
groupbyTagEntity = "DESTINATION"
metric = "calls"
aggregation = "SUM"
windowSize = 3600000
windowSizeはミリ秒で指定するため、1時間は3,600,000ミリ秒になる。
結果は、次のような表として整理できた。
| サービス | コール数 |
|---|---|
| main-app | 3,847 |
| gateway-A | 749 |
| gateway-B | 743 |
ここで確認できたのは、Bobがアクセス数を推測しているのではないということだ。
Instanaが保持しているコール数を取得し、サービス別の表に整形している。自然言語で質問できるが、取得しているものはInstanaの観測データである。
一方で、上流サービスのコール数と下流サービスの合計が一致するとは限らない。内部呼び出し、エラー、ヘルスチェックなどが含まれる可能性があるため、単純な合計比較だけで判断しない方がよい。
コール数・レイテンシ・エラー率をまとめて取得した
アクセス数だけでは、どのサービスを調査すべきか判断できない。
そこで、コール数に加えて、P99レイテンシとエラー率をまとめて取得してみた。
〇〇アプリケーションについて、
サービス別のコール数、P99レイテンシ、エラー率の表を作成しなさい。
この場合、MCP呼び出しでは複数のメトリクスを指定する。
metrics = [
{"metric": "calls", "aggregation": "SUM"},
{"metric": "latency", "aggregation": "P99"},
{"metric": "errors", "aggregation": "MEAN"}
]
取得結果をサービス単位で並べることで、次の観点を同時に確認できた。
- 呼び出し回数が多いサービス
- レイテンシが高いサービス
- エラー率が高いサービス
これだけで障害原因が分かるわけではない。
しかし、「最初にどこを見るべきか」を決めるための情報としては利用できる。Instanaの画面を順番に確認する代わりに、調査開始時点の概況をBobに整理させる使い方である。
イベントやトレースも調べてみた
次に、メトリクス以外の情報を取得できるか確認した。
エラーイベントを整理する
直近1時間に発生したエラーイベントを取得し、
重大度と対象サービスごとに整理しなさい。
メトリクス上の変化だけでなく、同じ時間帯に発生したイベントを並べることで、調査対象を絞り込みやすくなる。
直近のトレースを確認する
〇〇サービスの直近トレースを取得し、
エラーを含むトレースを整理しなさい。
特定のトレースをさらに調べたい場合は、トレースIDを指定する。
トレースID 〇〇 の詳細を取得し、
エラーが発生しているSpanと関連属性を整理しなさい。
ここまで確認すると、Bob × Instana MCPは単なるメトリクス参照だけではなく、調査対象の特定や情報整理にも利用できそうだった。
そこで、障害調査を想定した一連の流れを試すことにした。
障害調査シナリオで試してみた
障害調査では、最初から原因が分かっているわけではない。
一般的には、次のように調査対象を絞り込んでいく。
- メトリクスから異常の起点を探す
- 発生前後のイベントを確認する
- エラーを含むトレースを確認する
- エラー情報やSpan属性を確認する
- 得られた情報から原因候補を整理する
最後の整理をBobに依頼した。
これまでに取得したメトリクス、イベント、トレースの情報を整理し、
可能性の高い原因候補と、追加で確認すべき項目を提示しなさい。
Bobは、取得済みの観測情報をもとに原因候補を整理した。
例えば、特定サービスのエラー率が上昇しており、同じ時間帯に関連イベントや接続エラーが確認できた場合、それらを関連付けて次の調査対象を提示する。
ここで重要なのは、Bobが画面上の「推定根本原因」という表示だけを読み取り、そのまま回答しているわけではないということだ。
利用しているのは、その背景にある呼び出し、イベント、エラー、トレースなどの観測情報である。
推定根本原因は「結論」ではなかった
検証を進める中で、最も重要だと感じた点である。
当初は、Bobが障害の根本原因を特定してくれるのではないかと考えていた。
しかし、実際の役割は少し異なっていた。
Bobが扱っているのは、Instanaから取得した次のような情報だ。
- コール数やレイテンシなどのメトリクス
- 発生前後のイベント
- エラーを含むトレース
- Spanに付与された属性
- 取得可能なエラー情報
これらの情報から原因候補を整理し、次に確認すべき対象を提示することはできる。
一方で、取得した情報だけで原因を断定できるとは限らない。
アプリケーションの仕様、変更内容、外部システムの状態、運用上の前提など、Observabilityデータだけでは分からない情報もある。
そのため、推定根本原因は結論ではない。
次の調査へ進むための入口として扱う必要がある。
実際にハマったポイント
call.tagのキー一覧を調べてみた
Observabilityデータを業務や処理の単位で分析するには、Spanに付与したカスタム属性が重要になる。
そこで、サービスに付与されているcall.tagの一覧を取得してみた。
〇〇サービスで利用されている call.tag のキー一覧を取得しなさい。
MCP呼び出しでは、次のようにcall.tagでグルーピングする。
groupbyTag = "call.tag"
groupbyTagEntity = "NOT_APPLICABLE"
結果として、サービスで利用されているタグのキーを確認できた。
request.id
operation.type
processing.status
terminal.type
これは、想定していた属性がInstanaに届いているかを確認する用途に使える。
しかし、ここで最初の制約に当たった。
call.tagの値別集計ができなかった
最初は、次のような値別集計を期待していた。
operation.type
├ type-a
├ type-b
└ type-c
しかし、今回試した方法で取得できたのは、operation.typeなどのキー一覧だった。
groupbyTagKeyに特定のキーを指定しても、その属性値ごとの内訳になるわけではなかった。
値別の集計が必要な場合は、サービス名など別の軸で集計するか、個別のトレースやSpanを取得して集計する必要がある。
call.tagを指定すれば任意の属性値で集計できると思っていたため、最初に戸惑った点だった。
Analyticsのgroup byは1軸だった
複数の属性を持つデータでは、2つの軸を組み合わせて分析したくなる。
例えば、次のような集計である。
属性A × 属性B
しかし、今回利用したAnalyticsのgroup byでは1軸での指定が前提となった。
そのため、次のように分けて考える必要がある。
属性Aで対象を絞り込む
↓
属性Bでgroup byする
あるいは、上位の属性ごとにダッシュボードやウィジェットを分割する。
これはBobの制約というより、Bobが呼び出すInstana APIとデータモデルを理解したうえで設計する必要がある部分だった。
APMとInfrastructureでは取得方法が異なった
アプリケーションのレイテンシを取得できたため、同じ方法でホストのCPUやメモリも取得できると考えていた。
しかし、APMとInfrastructureでは利用する情報や取得方法が異なる。
アプリケーション側では、例えば次の情報を扱う。
calls
latency
errors
インフラ側では、次のようなメトリクスを扱う。
cpu.used
memory.used
memory.total
load.1min
fs.used
tcp.established
また、インフラ情報の取得では、最初に利用可能なスキーマやメトリクスを確認し、その後に対象メトリクスを指定する流れになった。
1. 対象エンティティと利用可能な情報を確認する
2. メトリクス、集計方法、フィルターを指定して取得する
アプリケーションのP99レイテンシと、ホストのCPU使用率を同じ問い合わせ方法で取得できるわけではない。
サービス名だけではホストを直接特定できなかった
アプリケーション監視ではservice.nameを利用する場面が多い。
そのため、サービス名から対象ホストのCPUやメモリを直接取得できると考えていた。
しかし、ホストエンティティに対して、サービス名をそのままフィルターとして利用できるとは限らなかった。
今回の検証では、対象ホストを別途特定し、ホスト名を使ってインフラメトリクスを取得した。
アプリケーション
↓
サービス
↓
プロセス
↓
ホスト
これらの関係を理解したうえで問い合わせる必要がある。
アプリケーション視点とインフラ視点は接続されているが、同じ識別子だけですべてをたどれるわけではなかった。
ダッシュボード設計にも使ってみた
調査だけでなく、ダッシュボード設計にも利用できるか試してみた。
従来は、次のような流れで設計する。
観測要件を整理する
↓
必要なタグを決める
↓
集計軸を決める
↓
ダッシュボードを設計する
↓
設定を作成する
そこで、観測したい内容をテキストでBobに渡した。
以下の観測要件をもとに、
必要なタグ、メトリクス、フィルター、ダッシュボード構成を設計しなさい。
〔観測要件を記載〕
Bobは、要件から必要なタグと集計方法を整理し、ダッシュボード構成のたたき台を提示した。
属性の付与方法が必要な場合は、OpenTelemetryのspan.set_attribute()やOTTLの設定案についても相談できる。
さらに、構成案をもとにダッシュボードJSONを生成し、投入後の設定内容を確認する流れにもつなげられる。
観測要件
↓
タグ設計
↓
ダッシュボード構成
↓
JSON生成
↓
投入後の確認
ただし、生成された設定をそのまま利用できるとは限らない。
タグ名、メトリクス名、集計方法、APIの制約を確認しながら修正する必要がある。完成品を自動生成するというより、設計と実装の最初のたたき台を作る用途で有効だった。
検証結果のまとめ
今回確認した内容を整理する。
| 確認したこと | 結果 |
|---|---|
| サービス別のコール数取得 | ✅ |
| P99レイテンシ取得 | ✅ |
| エラー率取得 | ✅ |
| イベント情報の整理 | ✅ |
| トレース情報の取得 | ✅ |
call.tagのキー確認 |
✅ |
call.tagの値別集計 |
❌ |
複数軸による同時group by
|
❌ |
| インフラメトリクス取得 | ✅ |
| サービス名からのホスト直接指定 | ❌ |
| 原因候補と追加調査項目の整理 | ✅ |
| 根本原因の自動確定 | ❌ |
| ダッシュボード設計支援 | ✅ |
できることと、できないことは比較的明確だった。
Bobに自然言語で依頼することはできるが、裏側で利用されるInstana APIの構造や制約がなくなるわけではない。
期待した結果が得られない場合は、プロンプトだけを変更するのではなく、次の点を確認する必要がある。
- 対象となるエンティティ
- 利用するメトリクス
- 集計方法
-
group byの軸 - タグの種類
- フィルター条件
- 取得対象の時間範囲
自然言語で操作できることと、Observabilityのデータモデルを理解しなくてよいことは同じではなかった。
まとめ
今回の検証を通じて分かったのは、Bob × Instana MCPの価値は、障害原因を自動で特定することではなかったということだ。
むしろ、
「情報を探す時間」を減らし、
「判断する時間」を増やすこと
に価値があるということだった。
メトリクス、イベント、トレースなどの情報を人が順番に探し、関連付ける作業には時間がかかる。
Bob × Instana MCPを利用すると、自然言語を起点に必要なデータを取得し、調査対象と追加確認項目を整理できる。
ただし、推定根本原因は結論ではない。
取得した観測事実をどのように解釈し、何を追加で確認し、どの対策を選択するかは人が判断する必要がある。
AIがObservabilityを置き換えるのではない。
Observabilityデータへ到達し、
状況を理解するまでの時間を短縮する。
今回試した範囲では、
Bob × Instana MCPは
そのための仕組みとして最も価値を感じた。
検証環境
- IBM Bob
- IBM Instana
- Instana MCP
- OpenTelemetry
- 検証用サンプルアプリケーション
製品機能やAPIの挙動は、利用するバージョンや環境によって異なる可能性があります。実際の利用時には、対象環境の仕様と取得結果を確認してください。