Azure リソースヘルス & 問題診断

このワークフローは、特定の Azure リソースを分析して健全性ステータスを評価し、ログとテレメトリデータを使用して潜在的な問題を診断し、発見された問題の包括的な改善計画を作成します。

前提条件

• Azure MCP サーバーが設定され、認証されていること
• 対象の Azure リソースが特定されていること（名前およびオプションでリソースグループ/サブスクリプション）
• リソースがデプロイされ、実行中でログ/テレメトリを生成していること
• 利用可能な場合は、Azure CLI を直接使用するよりも Azure MCP ツール（azmcp-*）を優先する

ワークフローステップ

ステップ 1: Azure ベストプラクティスの取得

アクション: 診断とトラブルシューティングのベストプラクティスを取得 ツール: Azure MCP ベストプラクティスツール プロセス:

1. ベストプラクティスをロード:
   • Azure ベストプラクティスツールを実行して診断ガイドラインを取得
   • ヘルスモニタリング、ログ分析、問題解決パターンに焦点を当てる
   • 診断アプローチと改善推奨事項を通知するためにこれらのプラクティスを使用

ステップ 2: リソース検出と識別

アクション: 対象の Azure リソースを検出して識別 ツール: Azure MCP ツール + Azure CLI フォールバック プロセス:

1. リソース検索:

   • リソース名のみが指定されている場合: azmcp-subscription-list を使用してサブスクリプション全体を検索
   • az resource list --name <resource-name> を使用して一致するリソースを検出
   • 複数の一致が見つかった場合、ユーザーにサブスクリプション/リソースグループを指定するよう促す
   • 詳細なリソース情報を収集:
     • リソースタイプと現在のステータス
     • ロケーション、タグ、設定
     • 関連するサービスと依存関係

2. リソースタイプ検出:

   • リソースタイプを識別して適切な診断アプローチを決定:
     • Web Apps/Function Apps: アプリケーションログ、パフォーマンスメトリクス、依存関係追跡
     • 仮想マシン: システムログ、パフォーマンスカウンター、ブート診断
     • Cosmos DB: リクエストメトリクス、スロットリング、パーティション統計
     • ストレージアカウント: アクセスログ、パフォーマンスメトリクス、可用性
     • SQL Database: クエリパフォーマンス、接続ログ、リソース使用率
     • Application Insights: アプリケーションテレメトリ、例外、依存関係
     • Key Vault: アクセスログ、証明書ステータス、シークレット使用状況
     • Service Bus: メッセージメトリクス、配信不能キュー、スループット

ステップ 3: ヘルスステータス評価

アクション: 現在のリソースヘルスと可用性を評価 ツール: Azure MCP モニタリングツール + Azure CLI プロセス:

1. 基本的なヘルスチェック:

   • リソースのプロビジョニング状態と運用ステータスを確認
   • サービス可用性と応答性を検証
   • 最近のデプロイメントまたは設定変更を確認
   • 現在のリソース使用率（CPU、メモリ、ストレージなど）を評価

2. サービス固有のヘルス指標:

   • Web Apps: HTTP レスポンスコード、応答時間、稼働時間
   • データベース: 接続成功率、クエリパフォーマンス、デッドロック
   • ストレージ: 可用性パーセンテージ、リクエスト成功率、レイテンシ
   • VM: ブート診断、ゲスト OS メトリクス、ネットワーク接続性
   • Functions: 実行成功率、期間、エラー頻度

ステップ 4: ログ & テレメトリ分析

アクション: ログとテレメトリを分析して問題とパターンを識別 ツール: Log Analytics クエリ用の Azure MCP モニタリングツール プロセス:

1. モニタリングソースを検出:

   • azmcp-monitor-workspace-list を使用して Log Analytics ワークスペースを識別
   • リソースに関連付けられた Application Insights インスタンスを検出
   • azmcp-monitor-table-list を使用して関連するログテーブルを識別

2. 診断クエリを実行: リソースタイプに基づいた対象の KQL クエリで azmcp-monitor-log-query を使用:

   一般的なエラー分析:

   // Recent errors and exceptions
   union isfuzzy=true 
       AzureDiagnostics,
       AppServiceHTTPLogs,
       AppServiceAppLogs,
       AzureActivity
   | where TimeGenerated > ago(24h)
   | where Level == "Error" or ResultType != "Success"
   | summarize ErrorCount=count() by Resource, ResultType, bin(TimeGenerated, 1h)
   | order by TimeGenerated desc
   

   パフォーマンス分析:

   // Performance degradation patterns
   Perf
   | where TimeGenerated > ago(7d)
   | where ObjectName == "Processor" and CounterName == "% Processor Time"
   | summarize avg(CounterValue) by Computer, bin(TimeGenerated, 1h)
   | where avg_CounterValue > 80
   

   アプリケーション固有のクエリ:

   // Application Insights - Failed requests
   requests
   | where timestamp > ago(24h)
   | where success == false
   | summarize FailureCount=count() by resultCode, bin(timestamp, 1h)
   | order by timestamp desc
   
   // Database - Connection failures
   AzureDiagnostics
   | where ResourceProvider == "MICROSOFT.SQL"
   | where Category == "SQLSecurityAuditEvents"
   | where action_name_s == "CONNECTION_FAILED"
   | summarize ConnectionFailures=count() by bin(TimeGenerated, 1h)
   

3. パターン認識:

   • 繰り返されるエラーパターンまたは異常を識別
   • エラーをデプロイメント時刻または設定変更と相関関係
   • パフォーマンストレンドと低下パターンを分析
   • 依存関係の失敗または外部サービスの問題を確認

ステップ 5: 問題分類とルート原因分析

アクション: 特定された問題を分類し、根本原因を決定 プロセス:

1. 問題分類:

   • クリティカル: サービス利用不可、データ損失、セキュリティ侵害
   • 高: パフォーマンス低下、間欠的な障害、高いエラー率
   • 中: 警告、不最適な設定、マイナーなパフォーマンス問題
   • 低: 情報アラート、最適化の機会

2. ルート原因分析:

   • 設定の問題: 不正な設定、不足している依存関係
   • リソース制約: CPU/メモリ/ディスク制限、スロットリング
   • ネットワークの問題: 接続問題、DNS 解決、ファイアウォールルール
   • アプリケーションの問題: コードバグ、メモリリーク、非効率なクエリ
   • 外部依存関係: サードパーティサービスの障害、API リミット
   • セキュリティの問題: 認証失敗、証明書失効

3. 影響評価:

   • ビジネスへの影響と影響を受けるユーザー/システムを決定
   • データの整合性とセキュリティの影響を評価
   • 復旧時間目標と優先度を評価

ステップ 6: 改善計画の生成

アクション: 特定された問題に対処するための包括的な計画を作成 プロセス:

1. 即時アクション (クリティカル問題):

   • サービス可用性を復元するための緊急修正
   • 影響を軽減するための一時的な回避策
   • 複雑な問題のエスカレーション手順

2. 短期修正 (高/中優先度の問題):

   • 設定調整とリソーススケーリング
   • アプリケーションアップデートとパッチ
   • モニタリングとアラート機能の改善

3. 長期改善 (すべての問題):

   • より高い耐障害性のためのアーキテクチャ変更
   • 予防措置とモニタリング強化
   • ドキュメントとプロセスの改善

4. 実装ステップ:

   • 具体的な Azure CLI コマンドを含む優先度付きアクション項目
   • テストと検証手順
   • 各変更のロールバック計画
   • 問題解決を確認するためのモニタリング

ステップ 7: ユーザー確認とレポート生成

アクション: 調査結果を提示し、改善アクションの承認を得る プロセス:

1. ヘルス評価概要を表示:

   🏥 Azure リソースヘルス評価
   
   📊 リソース概要:
   • リソース: [名前] ([タイプ])
   • ステータス: [正常/警告/クリティカル]
   • ロケーション: [地域]
   • 最終分析: [タイムスタンプ]
   
   🚨 特定された問題:
   • クリティカル: X件 (即時対応が必要)
   • 高: Y件 (パフォーマンス/信頼性に影響)
   • 中: Z件 (最適化用)
   • 低: N件 (情報項目)
   
   🔍 トップの問題:
   1. [問題タイプ]: [説明] - 影響: [高/中/低]
   2. [問題タイプ]: [説明] - 影響: [高/中/低]
   3. [問題タイプ]: [説明] - 影響: [高/中/低]
   
   🛠️ 改善計画:
   • 即時アクション: X件
   • 短期修正: Y件
   • 長期改善: Z件
   • 推定解決時間: [タイムライン]
   
   ❓ 詳細な改善計画を進めますか? (y/n)
   

2. 詳細レポートを生成:

   # Azure リソースヘルスレポート: [リソース名]
   
   **生成日時**: [タイムスタンプ]  
   **リソース**: [フルリソース ID]  
   **総合ヘルス**: [色付きステータス]
   
   ## 🔍 エグゼクティブサマリー
   [ヘルスステータスと主要な調査結果の概要]
   
   ## 📊 ヘルスメトリクス
   - **可用性**: 過去 24 時間で X%
   - **パフォーマンス**: [平均応答時間/スループット]
   - **エラー率**: 過去 24 時間で X%
   - **リソース使用率**: [CPU/メモリ/ストレージのパーセンテージ]
   
   ## 🚨 特定された問題
   
   ### クリティカル問題
   - **[問題 1]**: [説明]
     - **根本原因**: [分析]
     - **影響**: [ビジネスへの影響]
     - **即時アクション**: [必要なステップ]
   
   ### 高優先度問題
   - **[問題 2]**: [説明]
     - **根本原因**: [分析]
     - **影響**: [パフォーマンス/信頼性への影響]
     - **推奨修正**: [ソリューションステップ]
   
   ## 🛠️ 改善計画
   
   ### フェーズ 1: 即時アクション (0～2時間)
   ```bash
   # サービスを復元するための重要な修正
   [説明付き Azure CLI コマンド]
   

   フェーズ 2: 短期修正 (2～24時間)

   # パフォーマンスと信頼性の向上
   [説明付き Azure CLI コマンド]
   

   フェーズ 3: 長期改善 (1～4週間)

   # アーキテクチャと予防措置
   [Azure CLI コマンドと設定変更]
   

   📈 モニタリング推奨事項

   • 設定するアラート: [推奨アラートのリスト]
   • 作成するダッシュボード: [モニタリングダッシュボードの提案]
   • 定期的なヘルスチェック: [推奨される頻度と範囲]

   ✅ 検証ステップ

   • ログを通じた問題解決を確認
   • パフォーマンス改善を確認
   • アプリケーション機能をテスト
   • モニタリングとアラート機能を更新
   • 学習内容をドキュメント化

   📝 予防措置

   • [同様の問題を防ぐための推奨事項]
   • [プロセス改善]
   • [モニタリング強化]

エラーハンドリング

• リソースが見つからない: リソース名/ロケーション指定に関するガイダンスを提供
• 認証の問題: ユーザーを Azure 認証セットアップに導く
• 権限不足: リソースアクセスに必要な RBAC ロールをリストアップ
• ログが利用不可: 診断設定の有効化とデータの待機を提案
• クエリタイムアウト: 分析をより小さい時間枠に分割
• サービス固有の問題: 制限事項を記載した汎用的なヘルス評価を提供

成功基準

• ✅ リソースのヘルスステータスが正確に評価されている
• ✅ すべての重大な問題が特定され、分類されている
• ✅ 主要な問題のルート原因分析が完了している
• ✅ 具体的なステップを含めた実行可能な改善計画が提供されている
• ✅ モニタリングと予防推奨事項が含まれている
• ✅ 問題がビジネスへの影響で明確に優先順位付けされている
• ✅ 実装ステップに検証とロールバック手順が含まれている