SumoLogic MCP Server

SumoLogic MCP サーバー

自然言語で SumoLogic とのやり取りを変革 - 平易な英語で質問するだけで、SumoLogic の操作を簡単に行える Model Context Protocol（MCP）サーバーです。

🚀 ここが特別です

これは単なる API ラッパーではありません。sumologic-context.json が実現するコンテキスト認識により、お使いの特定の環境、リソース、一般的なクエリを理解した自然言語で SumoLogic を操作できます。

導入前と導入後

導入前（従来の API）：

# Complex API calls with exact syntax
curl -X POST "https://api.sumologic.com/api/v1/search/jobs" \
  -H "Authorization: Basic <encoded>" \
  -d '{"query":"_sourceCategory=webapp | count by _sourceHost", "from":"2024-01-01T00:00:00", "to":"2024-01-01T23:59:59"}'

導入後（コンテキストを活用した自然言語）：

"Show me error counts from our production web servers yesterday"
"Which collectors are having ingestion issues?"
"Create a dashboard for our new microservice deployment"

🎯 主な機能

🧠 コンテキストに基づくインテリジェンス

sumologic-context.json 設定ファイルにより、基本的な API アクセスが、お客様の環境を把握したインテリジェントなアシスタントへと変わります。このアシスタントは次の情報を認識します。

• お使いの特定のコレクターとその用途
• 一般的なクエリと業務上の意味
• リソース間の関係と依存関係
• チーム固有の用語とワークフロー

🔧 SumoLogic のあらゆる操作に対応

• 接続管理：接続と正常性を確認
• コレクターとソース：データ取り込みを作成、管理、監視
• 検索と分析：自然言語で複雑なクエリを実行
• モニターとアラート：監視設定を管理
• ダッシュボード：可視化を作成、更新

💬 自然言語インターフェース

次のような質問ができます。

• 「今週の決済サービスのエラー率はどのくらいですか？」
• 「過去1時間の遅いデータベースクエリを表示してください」
• 「新しい Kubernetes クラスター用のコレクターを作成してください」
• 「確認しておくべき重大なアラートはありますか？」

🌟 sumologic-context.json の力

コンテキスト認識とは？

sumologic-context.json ファイルは、強力な秘密兵器です。このファイルによって、MCP サーバーはお客様固有の SumoLogic 環境を理解し、非常に直感的なやり取りが可能になります。

実際のコンテキスト設定

{
  "version": "1.0",
  "organization": "acme-corp",
  "environments": {
    "production": {
      "applications": {
        "web-frontend": {
          "sourceCategory": "prod/web/frontend",
          "sourceName": "nginx-*",
          "description": "Production web frontend servers (Nginx)",
          "commonFilters": ["_sourceHost=web-prod-*"],
          "sampleQueries": [
            "_sourceCategory=\"prod/web/frontend\" | where status_code >= 400",
            "_sourceCategory=\"prod/web/frontend\" | timeslice 1m | count by status_code",
            "_sourceCategory=\"prod/web/frontend\" | json field=response_time | avg(response_time)"
          ]
        },
        "api-backend": {
          "sourceCategory": "prod/api/backend", 
          "sourceName": "api-server-*",
          "description": "Production API backend services",
          "commonFilters": ["_sourceHost=api-prod-*"],
          "sampleQueries": [
            "_sourceCategory=\"prod/api/backend\" error OR exception",
            "_sourceCategory=\"prod/api/backend\" | json field=response_time | avg(response_time) by endpoint",
            "_sourceCategory=\"prod/api/backend\" | where status_code = 500"
          ]
        },
        "mobile-app": {
          "sourceCategory": "prod/mobile/app",
          "sourceName": "mobile-api-*",
          "description": "Production mobile application backend",
          "commonFilters": ["_sourceHost=mobile-prod-*"],
          "sampleQueries": [
            "_sourceCategory=\"prod/mobile/app\" crash OR exception",
            "_sourceCategory=\"prod/mobile/app\" | json field=user_id | count by user_id"
          ]
        }
      },
      "infrastructure": {
        "database": {
          "sourceCategory": "prod/database/postgresql",
          "sourceName": "postgres-*",
          "description": "Production PostgreSQL database logs",
          "commonFilters": ["_sourceHost=db-prod-*"],
          "sampleQueries": [
            "_sourceCategory=\"prod/database/postgresql\" slow query",
            "_sourceCategory=\"prod/database/postgresql\" | where duration > 1000"
          ]
        },
        "kubernetes": {
          "sourceCategory": "prod/k8s/containers",
          "sourceName": "k8s-*",
          "description": "Production Kubernetes cluster logs",
          "commonFilters": ["_sourceHost=k8s-*"],
          "namespaces": ["default", "production", "monitoring", "ingress-nginx"]
        }
      }
    },
    "staging": {
      "applications": {
        "web-frontend": {
          "sourceCategory": "staging/web/frontend",
          "sourceName": "nginx-staging-*",
          "description": "Staging web frontend servers"
        },
        "api-backend": {
          "sourceCategory": "staging/api/backend", 
          "sourceName": "api-staging-*",
          "description": "Staging API backend services"
        }
      }
    }
  },
  "shortcuts": {
    "errors": {
      "description": "Find error messages and exceptions",
      "queryTemplate": "error OR exception OR fatal OR \"stack trace\" OR \"internal server error\"",
      "timeRange": "-15m"
    },
    "performance": {
      "description": "Performance monitoring with configurable threshold",
      "queryTemplate": "response_time OR duration OR latency | where ${metric} > ${threshold}",
      "defaultParams": {
        "metric": "response_time", 
        "threshold": "1000"
      },
      "timeRange": "-1h"
    },
    "security": {
      "description": "Security-related events and authentication failures",
      "queryTemplate": "authentication OR authorization OR \"access denied\" OR \"unauthorized\"",
      "timeRange": "-1h"
    },
    "database-slow": {
      "description": "Slow database queries",
      "queryTemplate": "\"slow query\" OR (duration > ${threshold}) OR \"query timeout\"",
      "defaultParams": {
        "threshold": "5000"
      },
      "timeRange": "-30m"
    }
  },
  "commonFields": {
    "timestamp_field": "@timestamp",
    "host_field": "_sourceHost",
    "service_field": "service_name",
    "environment_field": "environment",
    "log_level_field": "level"
  }
}

コンテキストを活用した例

この高度なコンテキスト設定により、やり取りがどれほど自然で強力になるかをご覧ください。

例1：複数環境のエラー分析

質問： 「本番環境とステージング環境の Web フロントエンドのエラー率を比較してください」

AI の処理：

1. production と staging の両環境で web-frontend を特定します
2. コンテキストを考慮したクエリを使用します。
   • 本番環境：_sourceCategory="prod/web/frontend" | where status_code >= 400
   • ステージング環境：_sourceCategory="staging/web/frontend" | where status_code >= 400
3. 適切な期間を設定して比較分析を行います
4. 次のように報告します。「本番環境の Web フロントエンド：エラー率 0.2%（正常）、ステージング環境：エラー率 1.1%（上昇傾向。最近のデプロイテストが原因と考えられます）」

例2：インフラストラクチャの正常性確認

質問： 「Kubernetes クラスターのパフォーマンスはどうですか？」

AI が自動で行う処理：

1. 「Kubernetes クラスター」を prod/k8s/containers ソースカテゴリーに対応付けます
2. 設定済みの名前空間 default、production、monitoring、ingress-nginx を確認します
3. インフラストラクチャ固有のフィルター _sourceHost=k8s-* を適用します
4. コンテナーの正常性とリソース使用量に関するサンプルクエリを使用します
5. 次のように回答します。「K8s クラスターは正常です。4つの名前空間で247個のポッドが稼働しています。本番環境の名前空間でリソースの制約は検出されませんでした。」

例 3：スマートショートカットの使用

あなたの質問： 「過去 1 時間の遅いデータベースクエリを表示してください」

AI がショートカットを活用します：

1. 「遅いデータベースクエリ」が database-slow ショートカットに対応すると認識します
2. テンプレートを適用します："slow query" OR (duration > 5000) OR "query timeout"
3. PostgreSQL ログを対象にします：_sourceCategory="prod/database/postgresql"
4. デフォルトのしきい値（5000ms）とカスタムの時間範囲（-1h）を使用します
5. 結果：「過去 1 時間に 12 件の遅いクエリが見つかりました。平均実行時間：7.2 秒。最も多いクエリ：ユーザー認証クエリ。」

例 4：サービス横断のパフォーマンス分析

あなたの質問： 「モバイルアプリのパフォーマンス問題の原因は何ですか？」

AI が包括的な分析を実行します：

1. mobile-app アプリケーションのコンテキストを特定します
2. モバイル専用のクエリを実行します：_sourceCategory="prod/mobile/app" crash OR exception
3. api-backend のパフォーマンスと相互参照します：avg(response_time) by endpoint
4. database ログを確認し、関連する遅いクエリを調べます
5. 調査結果をまとめます：「モバイルアプリのクラッシュ率が 15％増加しています。根本原因：データベース接続プールの枯渇により、API エンドポイント /user/profile の応答時間が平均 3.2 秒になっています。」

例 5：セキュリティインシデントへの対応

あなたの質問： 「過去 1 時間にセキュリティ上の問題がなかったか確認してください」

AI がセキュリティショートカットを使用します：

1. すべての本番アプリケーションに security ショートカットのテンプレートを適用します
2. 次を検索します：authentication OR authorization OR "access denied" OR "unauthorized"
3. web-frontend、api-backend、mobile-app を同時にスキャンします
4. サービス間で調査結果を関連付けます
5. 報告します：「セキュリティアラート：API バックエンドで、IP 192.168.1.100 からの未承認アクセス試行が 47 件検出されました。Web フロントエンドでも、これに対応する 403 応答が確認されています。」

📋 前提条件

• Node.js 20+（LTS を推奨）
• SumoLogic アカウント（API アクセス権付き）
• API 認証情報（Access ID と Key）
• Docker（任意。コンテナ化したデプロイに使用）

⚡ クイックスタート

1. インストール

git clone https://github.com/greyaperez/mcp-sumologic.git
cd mcp-sumologic
npm install

2. 設定

# Copy environment template
cp .env.example .env

.env に SumoLogic の認証情報を記入します：

SUMOLOGIC_ACCESS_ID=your_access_id
SUMOLOGIC_ACCESS_KEY=your_access_key
SUMOLOGIC_API_ENDPOINT=https://api.us2.sumologic.com/api
SUMOLOGIC_CONTEXT_CONFIG=./sumologic-context.json
SUMOLOGIC_DEFAULT_TIMEZONE=UTC

3. コンテキストファイルを作成する

環境の詳細を記述した sumologic-context.json を作成します：

{
  "version": "1.0",
  "organization": "your-org",
  "environments": {
    "production": {
      "applications": {
        "web-frontend": {
          "sourceCategory": "prod/web/frontend",
          "sourceName": "nginx-*",
          "description": "Production web frontend servers",
          "commonFilters": ["_sourceHost=web-prod-*"],
          "sampleQueries": [
            "_sourceCategory=\"prod/web/frontend\" | where status_code >= 400"
          ]
        }
      },
      "infrastructure": {
        "database": {
          "sourceCategory": "prod/database/postgresql",
          "sourceName": "postgres-*", 
          "description": "Production PostgreSQL database logs",
          "commonFilters": ["_sourceHost=db-prod-*"]
        }
      }
    }
  },
  "shortcuts": {
    "errors": {
      "description": "Find error messages and exceptions",
      "queryTemplate": "error OR exception OR fatal",
      "timeRange": "-15m"
    }
  },
  "commonFields": {
    "timestamp_field": "@timestamp",
    "host_field": "_sourceHost",
    "service_field": "service_name"
  }
}

4. サーバーを実行する

# Development mode
npm run dev

# Production mode
npm run build && npm start

🐳 Docker によるデプロイ

ビルドと実行

# Build image
docker build -t mcp/sumologic .

# Run with environment variables
docker run -i --rm \
  -e SUMOLOGIC_ACCESS_ID="your_access_id" \
  -e SUMOLOGIC_ACCESS_KEY="your_access_key" \
  -e SUMOLOGIC_API_ENDPOINT="https://api.us2.sumologic.com/api" \
  -e SUMOLOGIC_CONTEXT_CONFIG="./sumologic-context.json" \
  -e SUMOLOGIC_DEFAULT_TIMEZONE="UTC" \
  mcp/sumologic

🔧 Claude Desktop との連携

Claude Desktop の設定に追加します：

オプション 1：Node.js を直接使用

{
  "mcpServers": {
    "sumologic": {
      "command": "node",
      "args": ["/path/to/mcp-sumologic/dist/index.js"],
      "env": {
        "SUMOLOGIC_ACCESS_ID": "your_access_id",
        "SUMOLOGIC_ACCESS_KEY": "your_access_key",
        "SUMOLOGIC_API_ENDPOINT": "https://api.us2.sumologic.com/api",
        "SUMOLOGIC_CONTEXT_CONFIG": "./sumologic-context.json",
        "SUMOLOGIC_DEFAULT_TIMEZONE": "UTC"
      }
    }
  }
}

オプション 2：Docker

{
  "mcpServers": {
    "sumologic": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "SUMOLOGIC_ACCESS_ID",
        "-e", "SUMOLOGIC_ACCESS_KEY",
        "-e", "SUMOLOGIC_API_ENDPOINT",
        "-e", "SUMOLOGIC_CONTEXT_CONFIG",
        "-e", "SUMOLOGIC_DEFAULT_TIMEZONE",
        "mcp/sumologic"
      ],
      "env": {
        "SUMOLOGIC_ACCESS_ID": "your_access_id",
        "SUMOLOGIC_ACCESS_KEY": "your_access_key",
        "SUMOLOGIC_API_ENDPOINT": "https://api.us2.sumologic.com/api",
        "SUMOLOGIC_CONTEXT_CONFIG": "./sumologic-context.json",
        "SUMOLOGIC_DEFAULT_TIMEZONE": "UTC"
      }
    }
  }
}

🛠️ 利用可能なツール

ツール	説明	コンテキスト対応
check_connection	API の接続を確認	✅
list_collectors	ビジネスコンテキスト付きで、すべてのコレクターを一覧表示	✅
get_collector	関連情報を含むコレクターの詳細を取得	✅
create_hosted_collector	スマートなデフォルト設定でコレクターを作成	✅
update_collector	コレクターのプロパティを更新	✅
delete_collector	影響分析を行ってコレクターを削除	✅
list_sources	用途の説明付きでソースを一覧表示	✅
get_source	コンテキスト付きでソースの詳細を取得	✅
create_http_source	テンプレートを使用して HTTP ソースを作成	✅
start_search_job	クエリ候補を提示して検索を実行	✅
check_search_job_status	検索のステータスを確認	✅
get_search_job_results	ビジネス上の解釈を添えて結果を取得	✅
list_monitors	ビジネスへの影響を添えてモニターを一覧表示	✅
get_monitor	コンテキスト付きでモニターの詳細を取得	✅

💡 コンテキスト設定のベストプラクティス

1. 環境とサービスタイプごとに整理する

{
  "environments": {
    "production": {
      "applications": {
        "web-frontend": {
          "sourceCategory": "prod/web/frontend",
          "description": "Production web frontend servers (Nginx)",
          "commonFilters": ["_sourceHost=web-prod-*"]
        }
      },
      "infrastructure": {
        "database": {
          "sourceCategory": "prod/database/postgresql", 
          "description": "Production PostgreSQL database logs"
        }
      }
    }
  }
}

2. 実際の SumoLogic クエリを含める

{
  "sampleQueries": [
    "_sourceCategory=\"prod/web/frontend\" | where status_code >= 400",
    "_sourceCategory=\"prod/api/backend\" | json field=response_time | avg(response_time) by endpoint"
  ]
}

3. 再利用可能なクエリショートカットを作成する

{
  "shortcuts": {
    "performance": {
      "description": "Performance monitoring with configurable threshold",
      "queryTemplate": "response_time OR duration OR latency | where ${metric} > ${threshold}",
      "defaultParams": {
        "metric": "response_time", 
        "threshold": "1000"
      },
      "timeRange": "-1h"
    }
  }
}

4. フィールドマッピングを標準化する

{
  "commonFields": {
    "timestamp_field": "@timestamp",
    "host_field": "_sourceHost", 
    "service_field": "service_name",
    "environment_field": "environment",
    "log_level_field": "level"
  }
}

5. 一貫した命名パターンを使用する

• ソースカテゴリー：{env}/{service-type}/{service-name}
• ソース名：{service}-{env}-*（例：nginx-prod-*）
• ホストフィルター：_sourceHost={service}-{env}-*

🔍 使用例

環境を考慮したクエリ

"Show me errors in production web frontend"
"Compare API performance between staging and production"  
"Check database health in all environments"

ショートカットを活用した分析

"Run security check for the last hour"
"Find slow database queries with default threshold"
"Show performance issues with response time over 2000ms"

インフラストラクチャインテリジェンス

"How is our Kubernetes cluster doing?"
"Check Redis cache hit rates in production"
"Show load balancer health across all environments"

サービス横断の相関分析

"Is the mobile app backend causing the database slowdown?"
"Compare error rates between web frontend and API backend"
"Show the full request flow from load balancer to database"

プロアクティブな管理

"Create a monitor for API response times over 1 second"
"Set up alerting for Kubernetes pod crashes"
"Monitor database connection pool exhaustion"

🤝 コントリビュート

1. リポジトリをフォークします
2. フィーチャーブランチを作成します（git checkout -b feature/amazing-feature）
3. 変更をコミットします（git commit -m 'Add amazing feature'）
4. ブランチにプッシュします（git push origin feature/amazing-feature）
5. プルリクエストを作成します

📄 ライセンス

このプロジェクトはMITライセンスの下でライセンスされています。詳細はLICENSEファイルをご覧ください。

---

SumoLogicの利用体験を変革する準備はできていますか？ シンプルなコンテキストファイルから始めて、複雑な操作が質問するだけで簡単になる様子をご覧ください！🚀