AI-Powered OpenTelemetry Analysis

AI を活用した OpenTelemetry 分析

🚀 オブザーバビリティデータを実用的なインテリジェンスに変換しましょう

ダッシュボードに埋もれるのはもうやめましょう。テレメトリデータと対話を始めましょう。

現代のアプリケーションは、OpenTelemetry を通じて膨大なオブザーバビリティデータを生成します。トレース、メトリクス、ログには、運用上のあらゆる疑問への答えが含まれています。しかし、その答えを見つけるには、複雑なクエリ言語を使いこなし、カスタムダッシュボードを構築し、異なるデータ種別にまたがるシグナルを手作業で関連付ける必要があります。

質問するだけで答えが得られるとしたら、どうでしょうか？

この MCP サーバーは、AI アシスタントと OpenTelemetry データの橋渡しをし、オブザーバビリティスタック全体と自然言語でやり取りできるようにします。

• 「直近1時間に決済サービスで発生したすべてのエラーを表示して」 — AI がトレースとログをクエリし、見落としていたかもしれないパターンを見つけます
• 「チェックアウトサービスの動作が遅いのはなぜ？」 — レイテンシのパターン、ボトルネック、異常について、すぐに分析結果が得られます
• 「昨日の午後2時から3時の間に、システムで何が変わった？」 — メトリクスを比較し、異常を特定して、サービス間のイベントを関連付けます
• 「認証失敗の根本原因を見つけて」 — AI に分散システム内のエラー伝播を追跡させます

📡 OpenTelemetry とは？

OpenTelemetry（OTEL）は、アプリケーションからテレメトリデータを収集・管理するための業界標準フレームワークです。ベンダーに依存せず、テレメトリデータの計装、生成、収集、エクスポートを行う方法を提供します。

オブザーバビリティの三本柱

OpenTelemetry は、次の3種類の重要なテレメトリデータを収集します。

トレース

• 分散システム内を流れるリクエストを追跡します
• 複数のサービスにまたがるトランザクションの全行程を示します
• 各ステップのタイミング、ステータス、コンテキスト情報を含みます
• 例：フロントエンド → カートサービス → 決済サービス → 通知サービスと進む、ユーザーのチェックアウト処理を追跡します

メトリクス

• 時間の経過に伴うシステムの挙動を数値で測定します
• カウンター、ゲージ、ヒストグラムを含みます
• リソース使用率、ビジネス KPI、パフォーマンス指標を追跡します
• 例：CPU 使用率、リクエストレイテンシのパーセンタイル、1分あたりの販売数

ログ

• 個別のイベントを構造化して記録します
• タイムスタンプ、重大度レベル、コンテキスト属性を含みます
• トレースやメトリクスと関連付けて、全体像を把握できます
• 例：エラーメッセージ、監査証跡、デバッグ情報

OpenTelemetry が重要な理由

従来の監視ツールでは、独自の形式に縛られることがよくあります。OpenTelemetry は次の方法で、こうしたサイロ化を解消します。

1. ベンダー中立性：一度収集すれば、どこにでも送信できます。Elasticsearch、OpenSearch、Jaeger、Prometheus などに対応しています
2. 統合された収集：すべてのテレメトリ種別に対して、単一の計装を使用します
3. コンテキストの自動付与：トレース、メトリクス、ログ間の関連付けを標準で提供します
4. 業界標準：Cloud Native Computing Foundation の支援を受けています

このサーバーが OpenTelemetry を強化する仕組み

OpenTelemetry はデータ収集を解決しますが、そのデータの分析には依然として専門知識が必要です。この MCP サーバーを使うと、OpenTelemetry のデータに自然な言葉で質問できます。

• クエリ言語は不要：複雑なクエリを書く代わりに、平易な英語で質問できます
• シグナル間の相関付け：AI がトレース、メトリクス、ログを自動的に関連付けます
• パターン認識：手動では見落とす可能性のある異常や傾向を発見できます
• コンテキストの理解：AI がサービス間の関係や依存関係を理解します

詳細はこちらをご覧ください。

• OpenTelemetry のドキュメント
• OTEL Collector の設定
• アプリケーションの計装
• OpenTelemetry デモアプリケーション

💡 重要な理由

従来の可観測性ツールはデータの収集と保存に優れていますが、そこから知見を得るには依然として人間の専門知識が必要です。AI をテレメトリーデータに直接接続することで、次のことが可能になります。

インシデントへの即時対応

午前3時に障害が発生したとき、複雑なクエリを作成している時間はありません。AI にエラーパターンの調査、システム内の障害の追跡、根本原因の特定を自然な言葉で依頼できます。

問題のプロアクティブな検出

何百もの固定アラートを設定する代わりに、AI にデータを継続的に分析させ、異常を検出できます。「今日のトラフィックに異常なパターンはありますか？」といった質問をすると、過去の基準値に基づくインテリジェントな分析が得られます。

誰もが利用できる可観測性

チームの全員がクエリに精通しているとは限りません。自然言語でアクセスできれば、開発者、SRE、さらにはプロダクトマネージャーも、複雑なクエリ言語を習得せずにシステムの動作を調べられます。

コンテキストを踏まえた開発

コードのレビュー中や機能の設計中に、開発者は類似のコードが本番環境でどのように動作するか、どのようなエラーを生成するか、システムのパフォーマンスにどう影響するかをすぐに確認できます。

🎯 実際のユースケース

インシデント発生時

• 「認証フローでエラーが発生したすべてのトレースを探してください」
• 「直近30分間のサービス依存関係の障害を表示してください」
• 「レイテンシーが上昇しているサービスはどれですか？」

パフォーマンス分析

• 「チェックアウトサービスで最も遅い処理を特定してください」
• 「今日の CPU 使用率を先週の基準値と比較してください」
• 「カートサービスのメモリーリークを探してください」

システムの理解

• 「すべてのサービス依存関係を図示してください」
• 「注文処理のクリティカルパスを表示してください」
• 「決済ゲートウェイと通信しているサービスはどれですか？」

異常検出

• 「直近1時間の異常なログパターンを探してください」
• 「すべてのサービスにわたるメトリクスの異常を検出してください」
• 「今日から出現し始めた、まれなエラーメッセージを表示してください」

🛠️ 仕組み

このサーバーは Model Context Protocol（MCP）を実装し、Elasticsearch/OpenSearch に保存された OpenTelemetry データにアクセスするための構造化インターフェースを AI アシスタントに提供します。質問すると、AI は次の処理を行います。

1. 意図を理解し、関連するデータの種類（トレース、メトリクス、ログ）を特定します
2. 提供されたツールを使って適切なクエリを構築します
3. 結果を分析し、知見を自然な言葉で提示します
4. 問題をさらに詳しく調べるため、追加のクエリを実行できます

⚡ クイックスタート

Windsurf/Claude Desktop ユーザー向け

MCP 設定に次の内容を追加してください。

{
  "mcpServers": {
    "otel-mcp-server": {
      "command": "npx",
      "args": ["-y", "otel-mcp-server"],
      "env": {
        "OPENSEARCH_URL": "http://localhost:9200",
        "USERNAME": "elastic",
        "PASSWORD": "changeme",
        "OPENAI_API_KEY": "sk-..."  // Optional: for ML-powered features
      }
    }
  }
}

注：ELASTICSEARCH_URL と OPENSEARCH_URL のどちらも使用できます。

開発者向け

# Clone and install
git clone https://github.com/ryanwith/melchi.git
cd melchi
npm install

# Configure your connection
cp .env.example .env
# Edit .env with your Elasticsearch details

# Build and run
npm run build

# Integrate with your MCP client using a direct node command to run dist/server.js

📊 利用可能な機能

クエリツール

• 直接クエリ：トレース、メトリクス、ログに対して Elasticsearch クエリを実行します
• サービスの検出：システム内のサービスを一覧表示し、検索します
• フィールドの検出：ワイルドカードに対応し、利用可能なフィールドを調べます（例：「.error」、「span.」）

分析ツール

• 異常検知：メトリクス、トレース、ログパターンの外れ値を見つけます
• サービストポロジーと依存関係のマッピング：
  • OpenTelemetry のスパンの親子関係からサービス間の関係を検出します
  • 依存関係ごとの詳細なレイテンシ統計（平均、最小、最大、p50、p95、p99）
  • サービス接続ごとのエラー率と成功率
  • サービス間のスループットメトリクス（1 分あたりの呼び出し数）
  • ノードサイズ、エッジ幅、色分けを含む、可視化に適したデータ
  • 重要なサービスとボトルネックを自動で特定します
• 時系列分析：メトリクスの傾向、季節性、異常を検出します
• ヘルスサマリー：ボトルネックを特定したシステムのヘルスレポートをすぐに取得できます

相関分析ツール

• エラー伝播：分散システム全体にわたってエラーを追跡します
• インシデント分析：障害発生時のログ、メトリクス、トレースを相関付けます
• パフォーマンスプロファイリング：遅い処理とリソースのボトルネックを特定します

🔧 インタラクションの例

サービスの依存関係を分析する

You: "Show me service dependencies with high latency"

AI: I'll analyze service dependencies and their performance metrics.

[AI executes dependency analysis and returns]:
Found 15 service dependencies. Here are the critical ones:

1. checkout-service → payment-service
   - Average latency: 450ms (95th percentile: 1200ms)
   - Error rate: 2.3%
   - Call volume: 1,250 calls/minute
   
2. frontend → recommendation-service  
   - Average latency: 890ms (95th percentile: 2100ms)
   - Error rate: 0.5%
   - Call volume: 3,400 calls/minute
   - ⚠️ This is a bottleneck - high latency affecting user experience

The recommendation service is your primary bottleneck, with p95 latency over 2 seconds.

パフォーマンスの問題を見つける

You: "Why is the checkout service slow today?"

AI: I'll analyze the checkout service performance. Let me:
1. Check for latency anomalies
2. Identify slow operations
3. Look for error patterns

[AI executes queries and returns]:
The checkout service is experiencing 3x normal latency on the payment-processing operation. 
This started at 2:15 PM and correlates with increased error rates from the payment gateway.
The service is timing out after 5 seconds, causing cascading failures.

エラーを調査する

You: "Find all authentication failures in the last hour"

AI: I'll search for authentication failures across logs and traces.

[AI executes queries and returns]:
Found 847 authentication failures in the last hour:
- 92% are "invalid token" errors from the mobile app (v2.3.1)
- Failures spike every 15 minutes, suggesting a token refresh issue
- All failures originate from 3 specific API endpoints
- The pattern started after the 1:30 PM deployment

🌟 主なメリット

調査のスピード向上

• MTTR を数時間から数分に短縮します
• 複数のツールを切り替える必要はありません
• データ種別をまたいだ相関をすぐに確認できます

導入のハードルを軽減

• 新しいチームメンバーもすぐに問題を調査できます
• クエリ言語の専門知識は必要ありません
• 自然言語だけで操作できます

先回りしたインサイト

• AI が人間では見落としがちなパターンを発見します
• 手動の介入なしで継続的に分析します
• 過去との比較や傾向の検出ができます

統一されたインターフェース

• 調査全体をひとつの会話スレッドで進められます
• ダッシュボードを切り替える必要はありません
• 分析中もコンテキストが維持されます

🚀 実データで始める

OpenTelemetry Demo を使用する

実際のマイクロサービスデータでテストできます：

# Deploy the OTEL demo with Kubernetes
kubectl create namespace otel-demo
helm install demo open-telemetry/opentelemetry-demo -n otel-demo --values demo/otel-demo-values.yaml

# Port-forward OpenSearch
kubectl port-forward -n elastic svc/opensearch 9200:9200

# Start your MCP Client with the following environment variables:
# OPENSEARCH_URL=http://localhost:9200

次のクエリを試す

接続したら、データを確認してみましょう：

• 「利用可能なサービスをすべて表示して」
• 「frontend サービスのエラーを見つけて」
• 「checkout サービスのレイテンシパターンを分析して」
• 「CPU 使用率の異常を検出して」
• 「レイテンシメトリクスを使ってサービスの依存関係をマッピングして」
• 「最も遅いサービス接続を表示して」
• 「エラー率が最も高いサービスはどれ？」
• 「サービストポロジーのボトルネックを特定して」

📚 高度な機能

ML を活用した分析（OpenAI API キーが必要）

• セマンティックログ検索：埋め込み表現を使って、類似するエラーパターンを検索します
• トレースの自動クラスタリング：類似する問題をまとめます
• 時系列予測：今後のメトリクスの傾向を予測します

ML 機能を有効にするには、環境変数 OPENAI_API_KEY を設定してください。

インテリジェントな相関分析

• トレース、メトリクス、ログを自動で相関付けます
• エラー伝播分析を含むサービス依存関係の追跡
• 分散トランザクション全体にわたる根本原因分析

柔軟なデプロイ

• Elasticsearch 7.x/8.x と OpenSearch で動作します
• OTEL と ECS の両方のマッピングモードに対応しています
• 利用可能なデータ種別に自動で適応します

🤝 貢献

貢献を歓迎します！まず実際に試してみて、貢献ガイドラインに従って問題を報告していただくことが、何よりの貢献です。新しい分析ツールの追加、クエリ機能の改善、ドキュメントの拡充など、直接的な貢献を通じて、オブザーバビリティを誰もが利用しやすくすることができます。

📄 ライセンス

MIT License - OpenTelemetry コミュニティのために ❤️ を込めて開発

---

オブザーバビリティデータとのやり取りを変えてみませんか？ 今すぐテレメトリデータと会話を始めましょう。