Elastic ObservabilityとMCPを活用したエージェント型Kubernetes調査

Monitor clusters, pods, and nodes with full application context across EKS, GKE, AKS, and OpenShift. 

Join our on-demand webinar: Kubernetes management with Elastic & agentic AI to level up your skills. You can also start a free cloud trial, or run Elasticsearch locally.

エージェント機能を活用したKubernetesオブザーバビリティが、Elastic Observabilityで利用できるようになりました。Elastic ObservabilityのUIを使用している場合でも、独自の自律型エージェントワークフローを使用している場合でも、Elasticは発生しているKubernetesの問題の調査に役立つ一連の機能を提供します。チャットインターフェースから離れることなく、ClaudeやCursorなどのAIエージェントがElastic Observabilityに対してクエリを実行し、K8sの障害を把握してMLの異常を浮き彫りにできるようにするMCP（Model Context Protocol）アプリをリリースしました。

パート1では、ElasticのKubernetes統合がEDOTコレクターを介してテレメトリをElasticsearchに送信する仕組みを取り上げました。本記事ではさらに一歩進めて、そのテレメトリをAIから呼び出し可能なツールとして公開し、インラインでレンダリングされるインタラクティブなReact UIを備えたMCP（Model Context Protocol）アプリサーバーについて解説します。また、アラートから修復案の提示に至る根本原因分析の一連のプロセスを処理する自動化ランブック、Elastic Workflowsを活用してさらに発展させる方法についても紹介します。

作業環境でレンダリングするObservability MCPアプリ

Elastic Observability MCPアプリ（テクニカルプレビュー）は、ツールごとに1つずつ、計6つのビューを提供します。それぞれはツールが応答を返すとインラインでレンダリングされ、クリック可能なボタンとして推奨される次のステップのプロンプトを表示するため、適切なフォローアップを推測する必要がありません。MCPアプリはスタンドアロンのエージェントワークフローにとどまらず、Kibanaへのコンテキストの切り替えなしに、チャットやIDE内で直接、会話のインラインにライブでインタラクティブなビューをレンダリングします。

クラスターの状態のロールアップ

「壊れているのはどこ？」または「ステータスレポートをください」と尋ねると、全体的な健全性バッジ、理由付きの劣化サービス、上位ポッドのメモリ消費量、異常の深刻度の内訳、サービスのスループットなど、すべてを1つのインラインビューで一度に把握できます。

ビューは、導入がサポートする内容に応じて適応します。APMはサービスの健全性を提供します。Kubernetesのメトリックは、ポッドとノードのコンテキストを追加します。MLジョブは異常を重ねて表示します。シグナルが存在しない場合、ビューはエラーメッセージを表示するのではなく、何が不足しているかを知らせます。まずはKubernetesクラスターのステータスレポートから始めましょう。

健全性の概要のような複合レポートは、詳細を展開できる要約されたデータ表示を備えており、一度に表示する適切な情報量を選択できます。推奨される調査アクションは、返された特定の情報に関するガイダンスを提供するだけでなく、実行すべき他のツールへとユーザーを案内します。

サービス依存関係グラフ

「checkoutを呼び出しているのは何ですか？」または「トポロジーを表示」と尋ねて、レイヤー化された依存関係グラフ（上流の呼び出し元、下流の依存関係、プロトコル、エッジごとの呼び出し回数および遅延）を取得します。エッジにカーソルを合わせると、呼び出しパス全体が強調表示されます。Claudeに「フロントエンドのサービス依存関係を見せて」と頼んでみます。

ズーム、パン、ホバー操作で、複雑なサービス間の関係性を理解するために必要な詳細情報をすべて確認できます。

異常の詳細

「どこが異常ですか？」または「checkoutに何か異常はありますか？」と質問すると、自動的に選択された2つのビューのいずれかが表示されます。複数のエンティティが影響を受けている場合、概要モードには重大度カウント、影響を受けるエンティティ、ジョブごとの内訳が表示されます。単一のエンティティが対象である場合、詳細モードにはスコア、比較バー付きの実際値と代表値、逸脱率、および利用可能な場合は時系列が表示されます。フロントエンドサービスを確認してみましょう。

これはESQLクエリではなく、事前に定義された異常検知ジョブの結果の説明です。このブログシリーズのパート1で説明したように、Kubernetes統合には、有効化する必要のある機能がいくつか含まれています。このツールは、それらを最大限に活用するのに役立ちます。

Observe

ObserveはElasticのエージェントの主要なアクセスプリミティブで、1つのツール、3つの異なるニーズに対応する2つのモードです。「各Kubernetesクラスターのネットワークスループットを教えて」と指定すると、結果のテーブルやグラフが表示されます。「メモリが80MBを下回ったら教えてください」または「今後10分間、フロントエンドのメモリに異常がないか監視してください」と指定すると、条件が満たされるか、指定された期間が終了するまで処理が停止します。

表示はモードに応じて変化します。ワンショットクエリの場合は結果テーブル、サンプリング条件としきい値条件の場合は現在値、ピーク値、ベースライン値を示すリアルタイムトレンドチャート、異常検知モードの場合は深刻度スコア付きのトリガーカードが表示されます。 ここでは、最も負荷の高いKubernetesノードを特定するためにこれを使用します。

爆発半径でリスクを評価

「k8sノードがダウンしたらどうなる？」と尋ねると、放射状の影響図が表示されます。中央にターゲットノードがあり、完全停止状態のデプロイメントは赤色、機能低下状態は琥珀色、影響を受けない状態は灰色で示されます。画面上に浮かぶサマリーカードには、リスクのあるポッドとスケジュール変更の実現可能性が表示されます。単一レプリカ構成は、単一障害点として認識されます。ビジー状態のノードが故障した場合、何が起こるでしょうか？

アラート管理

アラート管理ツールを使用すると、アラートの作成、一覧表示、情報の取得、削除を行うことができます。次にアラートを作成しますが、その前にObserveをもう一度使用して簡単なベースラインを取得し、アラートが適切かどうかを確認します。

「フロントエンドのメモリが75MBを超えたら通知して」と指示すると、エージェントは永続的なKibanaアラートルールを作成します。これは、会話が終了した後も実行され続ける保存されたオブジェクトです。ビューには、ルール名、条件、時間枠、チェック間隔、KQLフィルター、タグを含むライブのルールカードが表示されます。次のステップのボタンでは、ルールの検証、メトリクスの安定化の監視、または現在のクラスターの健全性の確認を行えます。エージェントは、作成された内容とKibanaでの所在を確認します。

MCPアプリアーキテクチャー

このアプリは、Node.jsサーバー、6つの単一ファイルビューリソースに接続された6つのモデル対応ツール、再クエリ用のアプリ専用ツール、vite-plugin-singlefileのバンドルで構成されています。ツールは導入バックエンド（ユニバーサル、APM依存、K8s依存、ML依存）によってグループ化されているため、エージェントとユーザーの両方が、呼び出し時に機能ギャップを検出するのではなく、特定の導入に適用されるツールを事前に知ることができます。リポジトリには、6つのスキルが個別の.zipアーティファクトとして含まれており、エージェントに各ツールをいつ、どのように呼び出すかを教えます。

次の図は、アプリを構成する3つのコンポーネントを示しています。1つ目は、LLMと、ツールの使用方法をLLMに教えるClaudeスキルを保持するMCPホスト（Claude Desktop、VS Code、または同様のもの）です。2つ目は、ツールレジストリを公開し、React UIビューをバンドルして、Elasticとのすべての通信を処理する単一のNode.jsプロセスであるMCPアプリサーバーです。3つ目はElastic Stack自体であり、ElasticsearchとKibanaがライブデータおよびアラートのバックエンドとして機能します。

以下の図は、ユーザーリクエストのフローを示しています。Claudeは関連するスキルファイルを読み取り、呼び出すツールとそのパラメーターの設定方法を理解します。次にツールを呼び出すと、ElasticsearchとKibanaに対するサーバー側のクエリがトリガーされ、インタラクティブなウィジェットとしてインラインでレンダリングされるReact UIリソースとともに、コンパクトなテキストサマリーを受け取ります。

アラートから根本原因まで：調査ワークフロー

アラートルールは、問題が発生していることを示します。MLモジュールは、そのパターンを示します。Elastic Workflowsは、アラートが発生した瞬間に自動的に診断を実行します。

Kubernetesのアラートでトリガーされ、ダッシュボードを1つも開く前に構造化された根本原因のサマリーを返すKubernetes Investigation Workflow（テクニカルプレビュー）をリリースします。ページングを受けたSREがアラートを開くと、調査はすでに完了しています。

このワークフローは、複数のデータソースにクエリを実行するステップの有向グラフです。主にElasticsearch Query Language（ES|QL）経由で実行され、MLの異常検索にはElasticsearch検索が使用されます。ifステップはクエリ結果に基づいて分岐し、実行する裏付け（MLメモリの異常かログの分類か）と、アップストリームの健全性を評価するかどうか（APMの依存関係が存在する場合のみ）を選択します。AIステップは3か所で登場します。非OOMパスでのログパターンの分類、アップストリームの低下状態と正常状態の分類、そしてすべての構造化された証拠を根本原因のナラティブ（詳細説明）に統合する最後のai.summarizeです。

調査ワークフローの実際の様子

以下の実行例は、Elastic上で実行されるOpenTelemetry Astronomy Shop（16個のサービス、Kafka、PostgreSQL、すべてOTLP経由で事前インストルメント済み）に基づいています。Shopの実際のテレメトリと並行して、合成OOMKillカスケードを挿入しました。これにより、EDOTデータストリームを介して同じ名前空間に合成K8sシグナルおよびAPMシグナルが書き込まれます。このワークフローは、挿入したシグナルと実際のシグナルを区別できません。単にアラートを調査します。

アラートが発生： oteldemo-esyox-default 内の app-deployment で CrashLoopBackOff。再起動回数：6。

ワークフローステップ1 — ポッドとコンテナのコンテキストの特徴を把握する

このワークフローは、再起動回数、直近の終了理由、宣言された制限に対する使用率についてK8sメトリックをクエリします。

結果：最後の終了理由はOOMKilled、再起動回数は6。（注：このポッド/ウィンドウではkubeletstats使用率を利用できませんでした。ワークフローは正常に継続します。）

ワークフローの分岐： 終了理由はOOMKilledであるため、ワークフローはログ調査のパスではなく、メモリ調査のパスをたどります。

ワークフローステップ2a — ML異常結果を確認する

メモリ傾向を再計算するのではなく、ワークフローはML異常インデックスをクエリして、アクティブなk8s_pod_memory_growth異常を検索します。

結果：異常なし — スパイクはリークの疑いではなく、負荷起因としてフラグが付けられています。

ワークフローステップ3 — 上流サービスの健全性を確認する

このワークフローは、APMのservice_destination.1m集計から上流の依存関係を列挙し、現在のエラー率と平均レイテンシーを7日前の同じ時間帯と比較します。AI分類ステップにより、上流のパフォーマンス低下がアラートに先行していたかどうかが判断されます。結果：1つの上流 — api-gateway。現在の平均遅延時間は15.13ミリ秒、エラー率は41.26%。ベースライン（168時間前）：同一。分類：upstream_healthy — 5倍のエラー/3倍の遅延しきい値内。アップストリームは除外されました。

ワークフローステップ4 — 最近のK8sの変更と相関付けを行う

名前空間のイベントログでは、Pulled → Created → Started → Killing → BackOffという短いサイクルが約60～90秒ごとに繰り返されていることが示されています。過去2時間に導入またはスケーリングのイベントはありません。

ワークフローの出力：

根本原因の仮説（確信度：高）

app-deploymentでメモリー負荷によりOOMKillが発生しています。ポッドが
終了理由「OOMKilled」で6回再起動しました。MLはメモリスパイクを
負荷主導（リークなし）とフラグ付けしました。。上流のapi-gatewayは現在と7日間ベースラインの比較で正常です
。これはリソース割り当ての問題です — コンテナのメモリ
制限が実際のワーキングセットに対して低すぎます。

エビデンス：
- 6回の再起動、最後の終了理由：OOMKilled
- MLメモリ増加の異常なし → leak_suspected=false（負荷起因）
- 上流のapi-gatewayは7日間のベースラインと比較して変化なし（15.13ミリ秒、41.26％）→ 正常
- K8sイベントに頻繁なPulled/Created/Started/Killing/BackOffのサイクルが表示
  過去2時間に導入なし

考えられる原因：負荷時の実際のワーキングセットに対してメモリ制限が不十分です。

推奨される次のステップ：
1. 観測された使用状況に基づいてアプリ導入のメモリ制限を引き上げる
2. アプリケーションコードをレビューしてメモリ最適化の機会を検討する
3. 高負荷経路における段階的な機能低下を検討する

下流への影響：APMの宛先メトリクスからは、特に確認された影響はありません。

上記の出力は、アラートを開いたときに表示される画面です。ログの羅列やダッシュボードへのリンクではなく、回答が表示されます。

同じワークフローには、Claude Desktop、VS Code、またはあらゆるMCP互換クライアントからMCPツールとしてアクセスできます。開発者が「なぜcheckoutでエラーが発生しているのか？」と尋ねると、エージェントはIDEからワークフローを呼び出し、エディタを離れることなく、同じ構造化された出力（同じ証拠、同じ根本原因）をインラインで返します。

ワークフロー実行のアニメーションウォークスルーをご覧ください。

Kubernetes調査のためのオブザーバビリティスキル

また、Kubernetesのワークロード、ノード、コントロールプレーンの問題に対する完全な診断手順を組み込んだ、単一の包括的な調査スキル（observability-k8s-investigation）も提供しています。これは、経験豊富なSREが直感的に適用しながらもめったに書き留めることのない推論を含んだ、独自のアプローチに基づく調査手法です。AIエージェントのスキルに組み込まれているため、Kibanaを最新の状態に維持することで利用できるようになります。まず、最も一般的な誤診を防御する基本原則から始まります。

• **証拠がないこと自体は、証拠ではありません。**ログクエリがゼロ行を返す場合は、no_logs_availableを報告してください。空の結果から障害モードを推測しないでください。
• OOMKilledはデフォルトでメモリリークを意味するわけではありません。 リークと判断する前に、現在の使用状況を7日間のベースラインと比較してください。単に制限値が小さすぎる可能性があります。
• **平均CPUメトリックはスロットリングを覆い隠してしまいます。**平均使用率が40～60％であればポッドは正常に見えても、p99では深刻なスロットリングが発生している場合があります。平均だけでなく、最大値やp95も確認してください。

・**併発症状は原因ではありません。**2つのサービスのパフォーマンスが同時に低下している場合、通常は上流に共通の原因があります。因果関係があると見なすのは、一方のサービスのパフォーマンス低下がもう一方よりも明らかに先行し、その差が大きい場合に限られます。

そこから、このスキルは、ワークロード、ノード、コントロールプレーン、オートスケーリング、ネットワーク層にわたる16種類の異なるK8s障害パターンを網羅する障害モード分類をエンコードします。これには、OOMKilledやCFSスロットリングから、アドミッションWebhookブロック、StatefulSetスプリットブレインまでが含まれます。各モードには、それを特定する決定的なシグナルと、それを確認する裏付けチェックリストが用意されています。

調査フローは、把握（対象のポッド、名前空間、導入の特定）、特徴付け（再起動回数、終了理由、使用率の取得）、分類（タクソノミーとの照合）、裏付け（イベント、ログ、APM、ベースライン比較の取得）、統合（高、中、低の調整信頼度で、明確な証拠と推奨される次のステップを含む根本原因の仮説を生成）の構造化されたプロセスに従います。

2つの障害モードが証拠に当てはまる場合、スキルはその両方を挙げ、どちらが原因であると考えられるかとその理由を説明します。証拠が曖昧な場合は、その旨を示します。「競合する仮説は有効な出力である」というのは明確な設計原則であり、誤った確信を生み出すことは調査自体の障害モードとして扱われます。

はじめに

これらの機能は、パート1で説明したKubernetes統合に基づいています。ダッシュボードとデータ収集が稼働したら、次のようになります。

ステップ1 — 調査ワークフローの有効化（テクニカルプレビュー）。KibanaのWorkflowsページからKubernetes Crashloop Investigation Workflowをインポートし、必要に応じてアラートルールでトリガーするように設定します。

ステップ2 — MCP互換クライアントにMCPアプリをインストール（テクニカルプレビュー）。MCP App for ObservabilityのリポジトリはGitHubにあります（ダウンロードについてはリリースぺージをご覧ください）。アプリをインストールする際は、含まれているスキルも忘れずにインストールして有効化してください。お好みのエージェントクライアントからExample MCP Appのツールにアクセスしてください。手順は上記のGitHubリンクにあるREADMEに記載されています。

ステップ3 — K8s Investigation Skillの活用（テクニカルプレビュー）。Agent Builderを使用している場合、AI Agent Skillsにあらかじめ組み込まれているため、追加の手間なくそのまま利用できます。このスキルは、基礎となるツールやワークフローをいつ、どのように呼び出すかをエージェントに教え、会話のコンテキストにおいて一貫した診断を可能にします。

次のステップ

調査ワークフローは、監視しているサービスで何が故障しているかを診断します。次の質問はさらに難しくなります。監視していないサービスはどうでしょうか？

私たちは、トポロジーを考慮したカバレッジインテリジェンスについて検討しています。これは、Kubernetes APIを介してクラスターにデプロイされたすべてのワークロードを自動的に検出し、Elasticに流入するテレメトリと相互参照して、ギャップを明らかにするものです。「47個のサービスがあります。11個には分散トレースがありません。最もリスクの高い死角はこちらです。」この機能は現在検討中であり、今後の記事で取り上げる予定です。

並行して、診断だけでなく対策にも重点を置いてワークフローを拡張しています。具体的には、調査概要を添付したケースを作成したり、人間の承認を得るためのロールバックを提案したり、根本原因に対処するまでの時間を稼ぐためにワークロードを拡張したりといったことです。

現在Elastic上でKubernetesを実行されている場合は、インシデントごとに手動で繰り返している調査手順、ワークフローからの提案なら信頼できる修復策、そして次に構築すべきMCPツールについて、ぜひお聞かせください。Elasticコミュニティディスカッションはこちらからご参加いただけます。