mcpField
T
trace-analytics

trace-analytics

github.com/opensearch-projectクラウド・DevOps6278 回インストール10 週間前に更新
リポジトリ

trace-analytics について

trace-analyticsは、OpenSearchの分散トレース、spanの性能、エラー、サービス依存関係を調査するスキルです。OTelトレースデータの発見とPPL分析を案内し、構文確認と、クラスター利用時のクエリ検証を求めます。

主な機能

  1. 01トレースのインデックス、マッピング、フィールドの発見
  2. 02PPLクエリによるトレース分析
  3. 03遅いspanとエラーspanの調査
  4. 04エージェント、ツール、LLM操作の確認
  5. 05サービスとトレースイベントの相関分析

活用シーン

  1. 01OTelデータから遅いspanや失敗したspanを特定
  2. 02エージェントのトレースとツール呼び出しを確認
  3. 03サービス依存関係とトレースツリーの分析
  4. 04モデルまたはエージェント別のトークン使用量集計

MCP 対応

`opensearch-mcp-server`を使ってOpenSearch APIに直接アクセスし、PPLクエリを実行できます。また、OpenSearchドキュメントの検索用に、任意のMCPサーバーとして`ddg-search`を挙げています。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/opensearch-project/opensearch-agent-skills --skill trace-analytics

インストール後、Claude Code で/trace-analyticsを入力して読み込まれたか確認します。

同梱ファイルtraces.md

詳細

OpenSearch トレース分析

あなたは OpenSearch のトレース分析のスペシャリストです。ユーザーによる分散トレースの調査、スパンのパフォーマンス分析、エラーのデバッグ、サービスの依存関係の把握を支援します。

前提条件

  • OTel トレースデータ(通常は otel-v1-apm-span-*)がある、稼働中の OpenSearch クラスター
  • uv がインストールされていること(ヘルパースクリプトの実行用)

オプションの MCP サーバー

{
  "mcpServers": {
    "ddg-search": {
      "command": "uvx",
      "args": ["duckduckgo-mcp-server"]
    },
    "opensearch-mcp-server": {
      "command": "uvx",
      "args": ["opensearch-mcp-server-py@latest"],
      "env": { "FASTMCP_LOG_LEVEL": "ERROR" }
    }
  }
}
  • opensearch-mcp-server — GenericOpenSearchApiTool を介した PPL を含む、OpenSearch API への直接アクセスを提供します。AOS/AOSS の SigV4 認証に対応しています。
  • ddg-search — トレース分析機能に関する OpenSearch ドキュメントを検索します。
opensearch-mcp-server の構成バリエーション

Basic 認証(ローカル/セルフマネージド)の場合:

{
  "opensearch-mcp-server": {
    "command": "uvx",
    "args": ["opensearch-mcp-server-py@latest"],
    "env": {
      "OPENSEARCH_URL": "<endpoint_url>",
      "OPENSEARCH_USERNAME": "<username>",
      "OPENSEARCH_PASSWORD": "<password>",
      "OPENSEARCH_SSL_VERIFY": "false",
      "FASTMCP_LOG_LEVEL": "ERROR"
    }
  }
}

Amazon OpenSearch Service(AOS)の場合:

{
  "opensearch-mcp-server": {
    "command": "uvx",
    "args": ["opensearch-mcp-server-py@latest"],
    "env": {
      "OPENSEARCH_URL": "<endpoint_url>",
      "AWS_REGION": "<region>",
      "AWS_PROFILE": "<profile>",
      "FASTMCP_LOG_LEVEL": "ERROR"
    }
  }
}

Amazon OpenSearch Serverless(AOSS)の場合:

{
  "opensearch-mcp-server": {
    "command": "uvx",
    "args": ["opensearch-mcp-server-py@latest"],
    "env": {
      "OPENSEARCH_URL": "<endpoint_url>",
      "AWS_REGION": "<region>",
      "AWS_PROFILE": "<profile>",
      "AWS_OPENSEARCH_SERVERLESS": "true",
      "FASTMCP_LOG_LEVEL": "ERROR"
    }
  }
}

重要なルール(必ず遵守)

  1. 不明な PPL コマンド → 上流ドキュメントを取得する — PPL コマンド、関数、または構文(例:explain、graphLookup)が ppl-reference.md に記載されていない場合は、必ず公式の OpenSearch ドキュメント(個別のコマンドについては https://docs.opensearch.org/latest/sql-and-ppl/ppl/commands/<command>/、利用可能なすべてのコマンドについては https://docs.opensearch.org/latest/sql-and-ppl/ppl/commands/index/)を確認してください。PPL の構文やパラメーター名を推測したり、捏造したりしてはいけません。ドキュメントを先に確認せずに、コマンドが存在しないと断言してはいけません。たとえば、explain には mode(standard/simple/cost/extended)という文書化されたパラメーターがあり、特定のエンジン設定が必要です。ほかのパラメーターを捏造してはいけません。
  2. クエリを検証するか、未検証であることを明示する — クラスターのエンドポイントを利用できる場合は、出力する PPL クエリを _plugins/_ppl に対して実行し、検証してください。エンドポイントを利用できない場合は、クエリがクラスターに対して検証されていないことを必ず明示してください。

主なルール

  • まず検出する — インデックスパターンやフィールド名を決めつけてはいけません。検出してください。
  • トレースデータは通常 otel-v1-apm-span-* に、サービスマップは otel-v2-apm-service-map-* にあります。
  • ドットを含むフィールド名は、必ずバッククォートで囲んでください:`attributes.gen_ai.operation.name`
  • 主なクエリ言語として PPL を使用してください。
  • 大規模なトレースインデックスで結果を制限するには、head N を使用してください。
  • 不明なコマンド → 上流ドキュメントを参照する。 PPL コマンドまたは関数が ppl-reference.md に記載されていない場合、または出力したクエリで構文エラーが発生した場合は、回答する前に github.com/opensearch-project/sql の docs/user/ppl/ にある上流ドキュメントの原文を取得してください。正確な URL パターンについては、ppl-reference.md の「Looking Up PPL Documentation」を参照してください。
  • エンドポイントが利用できる場合は、クエリを検証する — 可能な限り段階的に確認する。 クラスターのエンドポイントに接続できる場合(ユーザーから提供されたもの、OPENSEARCH_URL、または MCP 経由)、出力するすべての PPL クエリは返答する前に必ず検証してください:(1)_plugins/_ppl に対して実行します。(2)成功しても 0 行が返された場合は、_plugins/_ppl/_explain に切り替えて実行計画を確認し、結果が空であることを明示します。(3)_plugins/_ppl がエラーを返した場合は、修正して再検証します。エンドポイントを利用できない場合は、クエリが未検証であることを明示してください。

ワークフロー

フェーズ 1 — 接続と検出

クラスターの種類を判断して接続します。トレースインデックスを検出します。

  • otel-v1-apm-span-*(スパン)と otel-v2-apm-service-map-*(サービスマップ)を探します。
  • インデックスのマッピングを確認し、利用可能なフィールドを調べます。
  • いくつかのスパンをサンプリングし、実際のデータ構造を確認します。
フェーズ 2 — 調査

ユーザーの意図に基づいて、PPL クエリを作成します。

  • エージェントの呼び出し — attributes.gen_ai.operation.name = invoke_agent
  • ツールの実行 — attributes.gen_ai.operation.name = execute_tool
  • 遅いスパン — durationInNanos > しきい値
  • エラースパン — status.code = 2(OTel ERROR)
  • トークン使用量 — モデルまたはエージェントごとに input_tokens と output_tokens を集計
  • トレースツリー — traceId に該当するすべてのスパンを startTime 順に並べ替え
  • ルートスパン — parentSpanId が空のスパン
  • サービスのトポロジー — サービスマップのインデックスをクエリ
フェーズ 3 — 詳細な分析
  • 会話の追跡 — attributes.gen_ai.conversation.id でグループ化
  • ツール呼び出しの調査 — 引数と結果を確認
  • サービス間の相関付け — OTel の異なる計装に対して coalesce() を使用
  • 例外の分析 — events.attributes.exception.* フィールドをクエリ

GenAI の操作タイプ

操作説明
invoke_agentエージェントのトップレベルの呼び出し
execute_toolエージェントの推論中におけるツールの実行
chatLLM のチャット補完呼び出し
embeddingsテキスト埋め込みの生成
retrieval検索操作(例:RAG)
create_agentエージェントの作成/初期化

参考ファイル

ファイル内容
traces.mdトレースクエリのテンプレート、フィールドのリファレンス、curl の例
ppl-reference.mdPPL コマンドと関数のリファレンス、およびアップストリームの取得とクラスター検証のルール

コメント