次の方法で共有

Azure Monitor でのデータ収集ルール (DCR) の構造

  • [アーティクル]

この記事では、定義を用いて DCR を直接操作する必要がある場合の DCR の JSON 構造について説明します。

プロパティ

次の表は、DCR の最上位のプロパティについて説明したものです。

プロパティ 説明
description ユーザーが定義したデータ収集ルールの省略可能な説明。
dataCollectionEndpointId DCR によって使用されるデータ収集エンドポイント (DCE) のリソース ID (DCR の作成時に指定した場合)。 DCE を使用しない DCR の場合、このプロパティは存在しません。
endpoints1 DCR のエンドポイントの logsIngestion と metricsIngestion の URL が含まれています。 このセクションとそのプロパティは、DCR の作成時に DCR の kind 属性を Direct にした場合にのみ、自動的に作成されます。
immutableId データ収集規則の一意の識別子。 このプロパティとその値は、DCR の作成時に自動的に作成されます。
kind DCR が使用されるデータ収集シナリオを指定します。 このパラメーターの詳細については後述します。

1 2024 年 3 月 31 日より前に作成された DCR の場合、このプロパティは作成されません。 この日付より前に作成された DCR には、データ収集エンドポイント (DCE) と dataCollectionEndpointId プロパティを指定する必要があります。 これらの埋め込み DCE を使用する場合は、新しい DCR を作成する必要があります。

種類

DCR の kind プロパティには、DCR が使用される収集の種類を指定します。 DCR の種類ごとに、構造とプロパティは異なります。

さまざまな DCR とその詳細を次の表に示します。

種類 説明
Direct ログ インジェスト API を使用した直接インジェスト。 この種類の値が使用される場合にのみ、DCR のエンドポイントが作成されます。
AgentDirectToStore 収集したデータを Azure Storage と Event Hubs に送信します。
AgentSettings Azure Monitor エージェントのパラメーターを構成します。
Linux Linux マシンからイベントとパフォーマンス データを収集します。
PlatformTelemetry プラットフォーム メトリックをエクスポートします。
Windows Windows マシンからイベントとパフォーマンス データを収集します。
WorkspaceTransforms ワークスペース変換 DCR。 この DCR には入力ストリームが含まれません。

DCR データ フローの概要

DCR の基本的なフローを次のダイアグラムに示します。 各コンポーネントについては、次のセクションで説明します。

DCR のさまざまなセクション間の関係を示すダイアグラム。

入力ストリーム

DCR の入力ストリーム セクションでは、収集対象の受信データを定義します。 個別のデータ収集シナリオに応じて、2 種類の受信ストリームがあります。 ほとんどのデータ収集シナリオではいずれかの入力ストリームを使用しますが、両方を使用する場合もあります。

Note

ワークスペース変換 DCR には入力ストリームがありません。

入力ストリーム 説明
dataSources 既知のデータ型。 多くの場合、これは Azure Monitor エージェントによって処理され、既知のデータ型を使用して Azure Monitor に配信されるデータです。
streamDeclarations DCR で定義する必要があるカスタム データ。

ログ インジェスト API から送信されるデータには、受信データのスキーマを持つ streamDeclaration が使用されます。 これは、任意のスキーマを持つ可能性があるカスタム データが API から送信されるためです。

AMA からのテキスト ログは、dataSources と streamDeclarations の両方を必要とするデータ収集の一例です。 データ ソースには構成が含まれます

データ ソース

データ ソースは、監視データの独自のソースであり、それぞれに独自の形式とデータ公開方法があります。 各データ ソースの種類には独自のパラメーター セットがあり、データ ソースごとに構成する必要があります。 データ ソースから返されるデータは、通常、既知の型であるため、DCR でスキーマを定義する必要はありません。

たとえば、Azure Monitor エージェント (AMA) を使用して VM から収集されるイベントとパフォーマンス データは、windowsEventLogs や performanceCounters などのデータ ソースを使用します。 収集するイベントとパフォーマンス カウンターの条件は指定しますが、データ自体の構造を定義する必要はありません。これは、受信する可能性があるデータのスキーマは既知であるからです。

共通パラメーター

すべてのデータ ソースの種類には、次の共通パラメーターがあります。

パラメーター 説明
name DCR 内のデータ ソースを識別する名前。
streams データ ソースが収集するストリームの一覧。 これが Windows イベントなどの標準のデータ型の場合、ストリームは Microsoft-<TableName> という形式になります。 カスタム型の場合は、Custom-<TableName> という形式になります

有効なデータ ソースの種類

次の表に、現在使用できるデータ ソースの種類を一覧表示します。

[データ ソースの種類] 説明 ストリーム パラメーター
eventHub Azure Event Hubs からのデータ。 Custom1 consumerGroup - 収集元のイベント ハブのコンシューマー グループ。
iisLogs Windows マシンからの IIS ログ Microsoft-W3CIISLog logDirectories - IIS ログが保存されるクライアント上のディレクトリ。
logFiles 仮想マシン上のテキストまたは json ログ Custom1 filePatterns - クライアントから収集されるログ ファイルのフォルダーとファイルのパターン。
format - json または text
performanceCounters Windows と Linux 仮想マシンの両方のパフォーマンス カウンター Microsoft-Perf
Microsoft-InsightsMetrics		 samplingFrequencyInSeconds - パフォーマンス データをサンプリングする頻度。
counterSpecifiers - 収集する必要があるオブジェクトとカウンター。
prometheusForwarder Kubernetes クラスターから収集される Prometheus データ。 Microsoft-PrometheusMetrics streams - 収集するストリーム
labelIncludeFilter - 名前と値のペアとしてのラベル包含フィルターの一覧。 現在サポートされているのは 'microsoft_metrics_include_label' のみです。
syslog Linux 仮想マシンの Syslog イベント Microsoft-Syslog facilityNames - 収集する施設
logLevels - 収集するログ レベル
windowsEventLogs 仮想マシンの Windows イベント ログ Microsoft-Event xPathQueries - 収集するイベントの条件を指定する XPath。
extension Azure Monitor エージェントによって使用される拡張機能ベースのデータ ソース。 拡張機能によって異なります extensionName - 拡張機能の名前
extensionSettings - 拡張機能に必要な各設定の値

1 収集するデータのスキーマは多様である可能性があるため、これらのデータ ソースにはデータ ソースとストリームの宣言の両方を使用します。 データ ソースで使用されるストリームは、ストリーム宣言で定義されるカスタム ストリームにすることをお勧めします。

ストリーム宣言

Log Analytics ワークスペースに送信されるさまざまな種類のデータの宣言。 各ストリームは、キーがストリーム名を表すオブジェクトです。この名前は先頭が Custom- でなければなりません。 ストリームには、送信される JSON データに含まれる最上位プロパティの完全な一覧が含まれます。 エンドポイントに送信するデータの形状は、相手先テーブルのデータと一致する必要はありません。 その代わりに、入力データの上に適用される変換の出力は、相手先の形状と一致する必要があります。

データ型

プロパティに割り当て可能なデータ型は次のとおりです。

  • string
  • int
  • long
  • real
  • boolean
  • dynamic
  • datetime.

Destinations

destinations セクションには、データが送信される各宛先のエントリが含まれます。 これらの宛先は、dataFlows セクションの入力ストリームと照合されます。

共通パラメーター

パラメーター 説明
name dataSources セクションの宛先を識別する名前。

有効な宛先

現在使用できる宛先を次の表に示します。

宛先 説明 必須のパラメーター
logAnalytics Log Analytics ワークスペース workspaceResourceId - ワークスペースのリソース ID。
workspaceID - ワークスペースの ID

これは、データの送信先であるテーブルではなく、単にワークスペースを指定するものです。 既知の宛先である場合、テーブルを指定する必要はありません。 カスタム テーブルの場合は、データ ソースでテーブルを指定します。
azureMonitorMetrics Azure Monitor のメトリック このサブスクリプションのメトリック ストアは 1 つのみなので、構成は必要ありません。
storageTablesDirect Azure Table Storage storageAccountResourceId - ストレージ アカウントのリソース ID
tableName - テーブルの名前
storageBlobsDirect Azure Blob Storage storageAccountResourceId - ストレージ アカウントのリソース ID
containerName - BLOB コンテナーの名前
eventHubsDirect Event Hubs eventHubsDirect - イベント ハブのリソース ID。

重要

DCR 内で 1 つのストリームが送信できる Log Analytics ワークスペースは 1 つだけです。 それぞれが同じワークスペース内の異なるテーブルを使用している場合は、1 つのストリームに対して複数の dataFlow エントリを持つことができます。 1 つのストリームから複数の Log Analytics ワークスペースにデータを送信する必要がある場合は、ワークスペースごとに個別の DCR を作成します。

データ フロー

データ フローにより、入力ストリームと宛先が照合されます。 各データ ソースには、必要に応じて変換を指定できます。また、場合によっては Log Analytics ワークスペース内の特定のテーブルを指定します。

データ フローのプロパティ

セクション 説明
streams 入力ストリーム セクションに定義される 1 つ以上のストリーム。 複数のデータ ソースを同じ宛先に送信する場合は、単一のデータ フローに複数のストリームを含めることができます。 データ フローに変換が含まれている場合のみ、単一のストリームを使用します。 同じ Log Analytics ワークスペース内の複数のテーブルに特定のデータ ソースを送信する場合は、1 つのストリームを複数のデータ フローで使用することもできます。
destinations 前述の destinations セクションにある 1 つ以上の宛先。 マルチホーム シナリオでは、複数の宛先が許可されます。
transformKql 受信ストリームに適用されるオプションの変換。 変換は受信データのスキーマを理解し、ターゲット テーブルのスキーマでデータを出力する必要があります。 変換を使用する場合、データ フローは単一のストリームのみを使用する必要があります。
outputStream データが送信される destination プロパティに指定されたワークスペース内のテーブルを記述します。 outputStream の値の形式は、データが標準テーブルに取り込まれる場合は Microsoft-[tableName]、データがカスタム テーブルに取り込まれる場合は Custom-[tableName] になります。 ストリームごとに許可される宛先は 1 つのみです。

このプロパティは、事前定義済みのテーブルに送信されるため、イベントやパフォーマンス データなど、Azure Monitor からの既知のデータソースには使用されません。

次のステップ

データ収集ルールの概要とそれらを作成する方法