Windows 用 Log Analytics エージェントに関するイシューのトラブルシューティング

この記事では、Azure Monitor の Windows 用 Log Analytics エージェントで発生する可能性のあるエラーのトラブルシューティングのヘルプを提供し、それらを解決するための考えられる解決策を提案します。

Log Analytics のトラブルシューティング ツール

Windows 用 Log Analytics エージェントのトラブルシューティング ツールは、Log Analytics エージェントでのイシューの検出と診断に役立つように設計された、PowerShell スクリプトのコレクションです。 それは、インストール時にエージェントに自動的に含まれます。 このツールを実行することが、問題を診断するための最初の手順になります。

トラブルシューティング ツールを使用する

  1. Log Analytics エージェントがインストールされているコンピューターで、管理者として PowerShell プロンプトを開きます。

  2. ツールが置かれているディレクトリに移動します。

    cd "C:\Program Files\Microsoft Monitoring Agent\Agent\Troubleshooter"

  3. 次のコマンドを使用してメイン スクリプトを実行します。

    .\GetAgentInfo.ps1

  4. トラブルシューティングのシナリオを選択します。

  5. コンソールに表示される指示に従います。 トレース ログのステップでは、ログ収集を停止する際に手動による操作が必要です。 イシューの再現度に基づいて一定期間待ち、"S" を選択してログ収集を停止し、次のステップに進みます。

    結果ファイルの場所は完了時にログされ、新しいエクスプローラー ウィンドウが、ファイルを強調表示した状態で表示されます。

インストール

トラブルシューティング ツールは、Log Analytics エージェントのビルド 10.20.18053.0 以降のインストール時に自動的に同梱されます。

対象となるシナリオ

トラブルシューティング ツールは、次のシナリオを確認します。

  • エージェントがデータを報告していないか、ハートビート データがない。
  • エージェントの拡張機能のデプロイが失敗している。
  • エージェントがクラッシュしている。
  • エージェントの CPU またはメモリの消費が高い。
  • インストールとアンインストールのエクスペリエンスに問題がある。
  • カスタム ログに問題がある。
  • OMS ゲートウェイに問題がある。
  • パフォーマンス カウンターに問題がある。
  • エージェント ログを収集できない。

Note

イシューが発生した場合は、トラブルシューティング ツールを実行してください。 ログを最初に用意すれば、サポート チームが問題を迅速にトラブルシューティングするのに役立ちます。

重要なトラブルシューティング ソース

Windows 用 Log Analytics エージェントに関連するイシューのトラブルシューティングを支援するために、エージェントではイベントを Windows イベント ログ (特に アプリケーションとサービス\Operations Manager 以下) にログします。

接続に関する問題

エージェントがプロキシ サーバーまたはファイアウォールを介して通信する場合は、ソース コンピューターと Azure Monitor サービスからの通信を妨げる制限が設定されている場合があります。 不適切な構成のために通信がブロックされた場合、エージェントをインストールするときや、設定後に別のワークスペースに報告するようにエージェントを構成するときに、ワークスペースへの登録が失敗することがあります。 登録が成功した後で、エージェントの通信が失敗する可能性があります。 このセクションでは、Windows エージェントに関するこの種の問題を解決する方法について説明します。

次の表に示す以下のポートと URL を許可するようにファイアウォールまたはプロキシが構成されていることを再確認してください。 Web トラフィックに対して HTTP 検査が有効になっていないことも確認してください。 これによってエージェントと Azure Monitor の間で安全な TLS チャネルが妨げられる場合があります。

エージェントのリソース Port Direction バイパス HTTPS 検査
*.ods.opinsights.azure.com ポート 443 送信 はい
*.oms.opinsights.azure.com ポート 443 送信 はい
*.blob.core.windows.net ポート 443 送信 はい
*.agentsvc.azure-automation.net ポート 443 送信 はい

Azure Government に必要なファイアウォールの情報については、Azure Government の管理に関するトピックを参照してください。 Azure Automation Hybrid Runbook Worker を使用して Automation サービスに接続および登録し、お使いの環境で Runbook または管理ソリューションを使用することを計画している場合、Hybrid Runbook Worker 用のネットワークの構成に関する記事に説明されているポート番号と URL にアクセスできる必要があります。

エージェントが Azure Monitor と正常に通信しているかどうかを確認する方法はいくつかあります。

  • ワークスペースで [Azure Log Analytics Agent Health assessment](Azure Log Analytics の Agent Health の評価)を有効にします。 Agent Health ダッシュボードで [Count of unresponsive agents](応答していないエージェントの数) 列を表示すると、エージェントが一覧にあるかどうかを簡単に確認できます。

  • 次のクエリを実行して、報告先に構成されているワークスペースにエージェントからハートビートが送信されていることを確認します。 <ComputerName> は、マシンの実際の名前に置き換えます。

    Heartbeat 
    | where Computer like "<ComputerName>"
    | summarize arg_max(TimeGenerated, * ) by Computer 
    

    コンピューターがサービスと正常に通信している場合、クエリからは結果が返されます。 クエリから結果が返されない場合は、まず適切なワークスペースに報告するようにエージェントが構成されていることを確認します。 正しく構成されている場合は、ステップ 3 に進み、Windows イベント ログを検索して、Azure Monitor との通信を妨げている可能性があるイシューがエージェントによってログされているかどうかを確認します。

  • 接続の問題を特定するもう 1 つの方法は、TestCloudConnectivity ツールを実行することです。 このツールは、既定でエージェントと共にフォルダー %SystemRoot%\Program Files\Microsoft Monitoring Agent\Agent にインストールされます。 管理者特権でのコマンド プロンプトから、このフォルダーに移動してツールを実行します。 このツールにより結果が返され、どこでテストが失敗したかが強調表示されます。 たとえば、ブロックされた特定のポートまたは URL に関連していた可能性があります。

    TestCloudConnection ツールの実行結果を示すスクリーンショット。

  • イベント ソースHealth Service ModulesHealthServiceService ConnectorOperations Manager イベント ログを絞り込み、イベント レベル警告エラーで絞り込んで、次の表のイベントが書き込まれたかどうかを確認します。 その場合は、発生する可能性がある各イベントについて記載されている解決手順を確認します。

    イベント ID source 説明 解像度
    2133 & 2129 Health Service エージェントからサービスへの接続に失敗しました。 このエラーは、エージェントが Azure Monitor サービスと直接またはファイアウォールやプロキシ サーバーを介して通信できない場合に発生する可能性があります。 エージェントのプロキシ設定、またはネットワーク ファイアウォールやプロキシでコンピューターからサービスへの TCP トラフィックが許可されていることを確認します。
    2138 Health Service Modules プロキシに認証が必要です。 エージェント プロキシ設定を構成し、プロキシ サーバーとの認証に必要なユーザー名/パスワードを指定します。
    2129 Health Service Modules 接続が失敗しました。 TLS ネゴシエーションに失敗しました。 ネットワーク アダプターの TCP/IP 設定とエージェント プロキシ設定を確認します。
    2127 Health Service Modules データの送信に失敗し、エラー コードを受信しました。 1 日にときおり発生するだけの場合は、ランダムな異常として無視できる場合があります。 監視して発生する頻度を把握します。 1 日中頻繁に発生する場合は、まずネットワーク構成とプロキシ設定を確認します。 説明に HTTP エラー コード 404 が含まれていて、エージェントからサービスにデータを送信しようとしたのが初めての場合、内部 404 エラー コードには 500 エラーが含まれます。 404 エラー コードは "見つからない" ことを意味します。つまり、新しいワークスペース用のストレージ領域がまだプロビジョニング中であることを示します。 次回の再試行時に、データはワークスペースに正常に書き込まれます。 HTTP エラー 403 は、アクセス許可または資格情報の問題を示している可能性があります。 403 エラーには、イシューの解決に役立つ詳しい情報が含まれています。
    4000 Service Connector DNS 名前解決に失敗しました。 コンピューターで、サービスにデータを送信するときに使用されるインターネット アドレスを解決できませんでした。 このイシューは、コンピューター上の DNS リゾルバーの設定、不適切なプロキシの設定、またはプロバイダーとの一時的な DNS の問題の場合があります。 ときおり発生する場合は、一時的なネットワーク関連の問題が原因の可能性があります。
    4001 Service Connector サービスへの接続に失敗しました。 このエラーは、エージェントが Azure Monitor サービスと直接またはファイアウォールやプロキシ サーバーを介して通信できない場合に発生する可能性があります。 エージェントのプロキシ設定、またはネットワーク ファイアウォールやプロキシでコンピューターからサービスへの TCP トラフィックが許可されていることを確認します。
    4002 Service Connector クエリに応答してサービスから HTTP 状態コード 403 が返されました。 サービスの状態についてサービス管理者に確認してください。 クエリは後で再試行されます。 このエラーは、エージェントの初期登録フェーズ中に書き込まれます。 https://<workspaceID>.oms.opinsights.azure.com/AgentService.svc/AgentTopologyRequest のような URL が表示されます。 403 エラー コードは "禁止" を意味し、誤って入力されたワークスペース ID またはキーが原因で発生する可能性があります。 コンピューターの日付と時刻も正しくない可能性があります。 時刻が現在の時刻より 15 分後または前である場合、オンボードは失敗します。 このイシューを修正するには、Windows コンピューターの日付や時間を更新します。

データ収集の問題

エージェントがインストールされ、構成された 1 つまたは複数のワークスペースに報告されると、有効なものとそのコンピューターをターゲットにしているものに応じて、構成の受信、パフォーマンス、ログ、またはその他のデータのサービスへの収集または転送が停止します。 以下のこと確認する必要があります。

  • ワークスペースで使用できないのは特定のデータ型ですか、それともすべてのデータですか。
  • データ型はソリューションによって指定されていますか、それともワークスペース データ収集の構成の一部として指定されていますか。
  • 何台のコンピューターが影響を受けますか。 ワークスペースに報告しているのは 1 台のコンピューターですか、それとも複数のコンピューターですか。
  • それは機能していて 1 日の特定の時点で停止しましたか、それとも収集が実行されたことはありませんでしたか。
  • 使用しているログ検索クエリの構文は正しいですか。
  • エージェントで Azure Monitor からその構成を受信したことはありますか。

トラブルシューティングの最初の手順は、コンピューターからハートビート イベントが送信されているかどうかを確認することです。

Heartbeat 
    | where Computer like "<ComputerName>"
    | summarize arg_max(TimeGenerated, * ) by Computer

クエリから結果が返される場合は、特定のデータ型の収集とサービスへの転送が行われていないかどうかを判断する必要があります。 このイシューは、更新された構成をエージェントがサービスから受信していないこと、またはエージェントの正常な動作を妨げる他の何らかの症状の可能性があります。 さらにトラブルシューティングを行うには、次の手順を実行します。

  1. コンピューターで管理者特権のコマンド プロンプトを開き、net stop healthservice && net start healthservice を入力してエージェント サービスを再起動します。

  2. Operations Manager イベント ログを開き、イベント ソースHealthService から イベント ID7023、7024、7025、7028、および 1210 を検索します。 これらのイベントは、エージェントが Azure Monitor から構成を正常に受信しており、コンピューターをアクティブに監視していることを示します。 イベント ID 1210 のイベントの説明では、最後の行に、エージェントの監視範囲に含まれるすべての解決策と分析情報も指定されます。

    イベント ID 1210 の説明を示すスクリーンショット。

  3. 数分お待ちください。 クエリ結果または視覚化に想定されるデータが表示されない場合は、Operations Manager イベント ログの解決策と分析情報のどちらのデータを表示しているかに応じて、イベント ソースHealthServiceHealth Service Modules を検索します。 イベント レベル "警告" と "エラー" でフィルター処理して、次の表のイベントが書き込まれたかどうかを確認します。

    イベント ID source 説明 解決方法
    8000 HealthService このイベントは、パフォーマンス、イベント、または収集されたその他のデータ型に関連するワークフローを、ワークスペースへの取り込みのためにサービスに転送できないかどうかを示します。 ソース HealthService のイベント ID 2136 がこのイベントと共に書き込まれ、エージェントがサービスと通信できないことを示す場合があります。 考えられる理由としては、プロキシと認証設定の構成が不適切、ネットワークが停止している、またはネットワーク ファイアウォールまたはプロキシがコンピューターからサービスへの TCP トラフィックを許可していないことが考えられます。
    10102 と 10103 Health Service Modules ワークフローでデータ ソースを解決できませんでした。 このイシューは、指定されたパフォーマンス カウンターまたはインスタンスがコンピューター上に存在しないか、ワークスペース データ設定で誤って定義されている場合に発生する可能性があります。 これがユーザー指定のパフォーマンス カウンターである場合は、指定されている情報が正しい形式であり、ターゲット コンピューター上に存在することを確認します。
    26002 Health Service Modules ワークフローでデータ ソースを解決できませんでした。 このイシューは、指定された Windows イベント ログがコンピューター上に存在しない場合に発生する可能性があります。 このイベント ログがコンピューターに登録されていないと予想される場合、このエラーは無視しても問題ありません。 それ以外で、これがユーザー指定のイベント ログである場合は、指定された情報が正しいことを確認してください。