次の方法で共有


Azure Monitor エージェントを使用して仮想マシンからイベントとパフォーマンス カウンターを収集する

この記事では、Azure Monitor エージェントを使用して、仮想マシンからイベントおよびパフォーマンス カウンターを収集する方法について説明します。

前提条件

この手順を完了するには、以下が必要です。

データ収集ルールを作成する

データ収集ルールを定義して、複数のマシンから複数の Log Analytics ワークスペース (異なるリージョンまたはテナントのワークスペースを含む) にデータを送信できます。 Log Analytics ワークスペースと "同じリージョン" にデータ収集ルールを作成します。 Windows イベントおよび Syslog データは、Azure Monitor ログにのみ送信できます。 パフォーマンス カウンターは Azure Monitor メトリックと Azure Monitor ログの両方に送信できます。

注意

現時点では、Microsoft.HybridCompute (Azure Arc 対応サーバー) リソースはメトリックス エクスプローラー (Azure portal UX) で表示できませんが、メトリック REST API (メトリック名前空間 - リスト、メトリック定義 - リスト、メトリック - リスト) を使用して取得できます。

注意

テナント間でデータを送信するには、まず Azure Lighthouse を有効にする必要があります。

  1. [モニター] メニューで、[データ収集ルール] を選択します。

  2. [作成] を選択して、新しいデータ収集ルールと関連付けを作成します。

    [データ収集ルール] 画面の [作成] ボタンを示すスクリーンショット。

  3. [ルール名] を入力し、[サブスクリプション][リソース グループ][リージョン]、および [プラットフォームの種類] を指定します。

    • [リージョン] により、DCR が作成される場所を指定します。 仮想マシンとそれらの関連付けは、テナント内の任意のサブスクリプションまたはリソース グループに配置できます。
    • [プラットフォームの種類] により、このルールを適用できるリソースの種類を指定します。 [カスタム] オプションにより、Windows と Linux の両方の種類が許可されます。

    [データ収集ルール] 画面の [基本] タブを示すスクリーンショット。

  4. [リソース] タブで、次の操作を実行します。

    1. [+ リソースの追加] を選択し、データ収集ルールにリソースを関連付けます。 リソースは、Azure 仮想マシン、Virtual Machine Scale Sets、Azure Arc for servers のいずれかです。 Azure portal は、まだインストールされていないリソースに Azure Monitor エージェントをインストールします。

      重要

      ポータルは、既存のユーザー割り当て ID と共に、ターゲット リソースでシステム割り当てマネージド ID を有効にします (該当する場合)。 既存のアプリケーションでは、ユーザー割り当て ID を要求で指定しない限り、マシンでは既定でシステム割り当て ID が代わりに使用されます。

      プライベート リンクを使用したネットワークの分離が必要な場合は、それぞれのリソースに対して同じリージョンから既存のエンドポイントを選択するか、新しいエンドポイントを作成します

    2. [データ収集エンドポイントを有効にする] を選択します。

    3. データ収集ルールに関連付ける各リソースのデータ収集エンドポイントを選択します。

    [データ収集ルール] 画面の [リソース] タブを示すスクリーンショット。

  5. [収集と配信] タブで、[データ ソースの追加] を選択して、データ ソースを追加し、送信先を設定します。

  6. [データ ソースの種類] を選択します。

  7. 収集するデータを選択します。 パフォーマンス カウンターでは、定義済みのオブジェクトのセットとそのサンプリング レートから選択できます。 イベントについては、一連のログと重大度レベルから選択できます。

    データ収集ルールで基本パフォーマンス カウンターを選ぶ Azure portal フォームを示すスクリーンショット。

  8. [カスタム] を選択して、現在サポートされているデータ ソースではないログとパフォーマンス カウンターを収集したり、XPath クエリを使用してイベントをフィルター処理したりします。 次に、[XPath] を指定して、特定の値を収集できます。

    既定では使用できないパフォーマンス カウンターを収集するには、\PerfObject(ParentInstance/ObjectInstance#InstanceIndex)\Counter 形式を使用します。 カウンター名にアンパサンド (&) が含まれている場合、それを & に置き換えます。 たとえば、\Memory\Free & Zero Page List Bytes のようにします。

    DCR の例については、「Azure Monitor でのデータ収集ルール (DCR) のサンプル」を参照してください。

    データ収集ルールでカスタム パフォーマンス カウンターを選ぶ Azure portal フォームを示すスクリーンショット。

  9. [送信先] タブで、データ ソースの 1 つ以上の送信先を追加します。 同じタイプまたは異なるタイプの送信先を複数選択できます。 たとえば、複数の Log Analytics ワークスペース (マルチホームとも呼ばれます) を選択できます。

    Windows イベントおよび Syslog データ ソースは、Azure Monitor ログにのみ送信できます。 パフォーマンス カウンターは Azure Monitor メトリックと Azure Monitor ログの両方に送信できます。 現時点では、ハイブリッド コンピューティング (Arc for Server) リソースは、Azure Monitor メトリック (プレビュー) の宛先をサポートしていません

    データ収集ルールでデータ ソースを追加する Azure portal フォームを示すスクリーンショット。

  10. [データ ソースの追加][確認と作成] の順に選択して、データ収集ルールの詳細と、一連の仮想マシンとの関連付けを確認します。

  11. [作成] を選択してデータ収集ルールを作成します。

パラメーター ファイル
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "vmName": {
      "value": "my-azure-vm"
    },
    "associationName": {
      "value": "my-windows-vm-my-dcr"
    },
    "dataCollectionRuleId": {
      "value": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/my-resource-group/providers/microsoft.insights/datacollectionrules/my-dcr"
    }
   }
}

Note

データ収集ルールを作成した後、データが送信先に送信されるまでに最大で 5 分かかることがあります。

XPath クエリを使用してイベントをフィルター処理する

Log Analytics ワークスペースに収集されるすべてのデータに対して課金されます。 そのため、必要なイベント データのみを収集する必要があります。 Azure portal の基本的な構成では、イベントをフィルター処理する機能が制限されています。

ヒント

Azure Monitor のコストを削減するための戦略については、「コストの最適化と Azure Monitor」を参照してください。

さらにフィルターを指定するには、カスタム構成を使用して、不要なイベントを除外する XPath を指定します。 XPath エントリは、LogName!XPathQuery の形式で記述されます。 たとえば、イベント ID が 1035 のイベントのみをアプリケーション イベント ログから返す必要があるとします。 これらのイベントを対象とする XPathQuery*[System[EventID=1035]] になります。 アプリケーション イベント ログからイベントを取得する必要があるため、XPath は Application!*[System[EventID=1035]] です

Windows イベント ビューアーから XPath クエリを抽出する

Windows では、スクリーンショットで示すように、イベント ビューアーを使用して XPath クエリを抽出できます。

XPath クエリを [データ ソースの追加] 画面のフィールドに貼り付ける場合 (手順 5 で表示)、ログの種類のカテゴリの後に '!' を追加する必要があります。

Windows イベント ビューアーで XPath クエリを作成するための手順を示すスクリーンショット。

ヒント

FilterXPath パラメーターを指定した PowerShell コマンドレット Get-WinEvent を使用し、最初にローカルで、つまり、自分のコンピューターで XPath クエリの有効性をテストできます。 詳細については、「Windows エージェントベースの接続」の手順に記載されているヒントを参照してください。 Get-WinEvent PowerShell コマンドレットでは、最大 23 個の式がサポートされています。 Azure Monitor のデータ収集ルールでは、最大 20 個がサポートされます。 次のスクリプトは、一例を示しています。

$XPath = '*[System[EventID=1035]]'
Get-WinEvent -LogName 'Application' -FilterXPath $XPath
  • 上記のコマンドレットでは、-LogName パラメーターの値は、感嘆符 (!) までの XPath クエリの最初の部分です。 XPath クエリの残りの部分は $XPath パラメーターに入ります。
  • スクリプトがイベントを返す場合、クエリは有効です。
  • [No events were found that match the specified selection criteria.](指定した選択条件に一致するイベントは見つかりませんでした。) というメッセージが表示された場合は、クエリはおそらく有効ですが、一致するイベントがローカル コンピューターにありません。
  • [The specified query is invalid](指定したクエリは無効です) というメッセージが表示された場合は、クエリ構文が無効です。

カスタム XPath を使用してイベントをフィルター処理する例:

説明 XPath
イベント ID = 4648 のシステム イベントのみを収集する System!*[System[EventID=4648]]
イベント ID = 4648 で、プロセス名が consent.exe であるセキュリティ ログ イベントを収集する Security!*[System[(EventID=4648)]] and *[EventData[Data[@Name='ProcessName']='C:\Windows\System32\consent.exe']]
イベント ID = 6 (ドライバーの読み込み) を除くすべての重大、エラー、警告、および情報のイベントをシステム イベント ログから収集する System!*[System[(Level=1 or Level=2 or Level=3) and (EventID != 6)]]
イベント ID 4624 (成功したログオン) を除くすべての成功および失敗のセキュリティ イベントを収集する Security!*[System[(band(Keywords,13510798882111488)) and (EventID != 4624)]]

注意

Windows イベント ログでサポートされている XPath の制限事項の一覧については、「XPath 1.0 の制限事項」を参照してください。
たとえば、クエリ内で "position"、"Band"、"timediff" の関数を使用できますが、"starts-with" や "contains" などのその他の関数は現在サポートされていません。

よく寄せられる質問

このセクションでは、一般的な質問への回答を示します。

Azure Monitor エージェントを使用して Windows セキュリティ イベントを収集するにはどうすればよいですか?

セキュリティ イベントの Log Analytics ワークスペースへの送信時に、新しいエージェントを使用して収集するには、次の 2 つの方法があります。

  • Azure Monitor エージェントを使用すると、他の Windows イベントと同じように、セキュリティ イベントをネイティブに収集できます。 これらは Log Analytics ワークスペースの 'Event' テーブルに送信されます。
  • ワークスペースで Microsoft Sentinel が有効になっている場合、セキュリティ イベントは、Azure Monitor エージェントを介して代わりに SecurityEvent テーブルに送信されます (Log Analytics エージェントを使用した場合と同じです)。 このシナリオでは、最初にソリューションを有効にする必要があります。

同じマシン上で Azure Monitor エージェントと Log Analytics エージェントを使用すると、イベントが複製されますか?

両方のエージェントで同じイベントを収集すると、重複が発生します。 この重複の原因として考えられるのは、レガシ エージェントがワークスペース構成データから冗長データを収集することです。これは、データ収集ルールによって収集されます。 または、レガシ エージェントでセキュリティ イベントを収集し、かつ Microsoft Sentinel の Azure Monitor エージェント コネクタで Windows セキュリティ イベントを有効にしている可能性があります。

重複イベントは、一方のエージェントから他方のエージェントに移行する期間だけに制限してください。 データ収集ルールを完全にテストし、そのデータ収集を確認した後、ワークスペースに対する収集を無効にし、Microsoft Monitoring Agent データ コネクタを切断してください。

Azure Monitor エージェントからは、Xpath クエリとパフォーマンス カウンターの指定以外の詳細なイベント フィルター処理オプションが提供されますか?

Linux の Syslog イベントについては、ファシリティと、各ファシリティのログ レベルを選択できます。

同じイベント ID を含むデータ収集ルールを作成し、それを同じ VM に関連付けると、イベントは重複しますか?

はい。 重複を回避するために、データ収集ルールで行うイベントの選択に重複イベントが含まれていないことを確認してください。

次のステップ