Azure Monitor には Data Collection Rule (DCR) があります。
Azure Portal から作成することができますが、実は Template を使用するほうが様々な構成を作成することができます。
Bicep を使って、Data Collection Rule を作成し、Azure Portal ではできないような構成を試してみます。

背景

Azure Monitor Agent (AMA) を使用してログやメトリックを収集する際、Data Collection Rule (DCR) が重要な役割を果たします。
DCR は、

• どのデータソースから
• どのような変換を行い
• どこに送信するか

を定義します。

Azure Portal からも DCR を作成できますが、Portal の UI では制限があり、すべての機能を使いこなすことができません。
特に以下のような高度なシナリオでは、Bicep や ARM テンプレートを使用する必要があります:

• カスタムログ以外のカスタムテーブルへのデータ送信
• 複数のデータストリームへの分岐
• KQL を使用した高度なデータ変換

本記事では、DCR の構成要素を詳しく解説し、実際に 5 つのシナリオを通じて Bicep での DCR 作成を試していきます。

DCR の構成要素

Data Collection Rule は、Microsoft の公式ドキュメントによると、以下の主要な要素で構成されています:

各要素の説明

DCR の Template 構造は以下の 4 つの主要なセクションで構成されます:

1. dataSources (データソース)
   • 収集するデータの種類と、そのデータから生成される streams (データストリーム) を定義します
   • 各データソースは streams プロパティで、生成されるデータストリームの名前を指定します
   • 例:
     • windowsEventLogs: Windows イベントログ → Microsoft-Event ストリーム
     • logFiles: カスタムログファイル → カスタムストリーム
       • テキストベースのログファイルを収集する際に使用します
       • ファイルパスやパターン、ログのフォーマット（テキスト形式）を指定できます
       • アプリケーション固有のログや、標準のログタイプに含まれない独自のログを収集する場合に便利です
     • iisLogs: IIS ログ → Microsoft-W3CIISLog ストリーム
     • performanceCounters: パフォーマンスカウンター → Microsoft-Perf ストリーム
     • syslog: Linux Syslog → Microsoft-Syslog ストリーム

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

dataSources: {
  iisLogs: [
    {
      streams: [
        'Microsoft-W3CIISLog'
      ]
      name: 'iisLogsDataSource'
    }
  ]
}

2. destinations (送信先)
   • データの送信先を定義します
   • 各送信先には一意の名前を付け、dataFlows から参照します
   • 主な送信先:
     • logAnalytics: Log Analytics ワークスペース
       • ログデータを格納し、KQL でクエリ・分析を行う際に使用します
     • azureMonitorMetrics: Azure Monitor メトリック
       • パフォーマンスカウンターなどのメトリックデータを送信します
     • storageAccounts: Azure Storage アカウント (プレビュー)
       • ログデータを長期保存やアーカイブ目的で Storage Account に送信できます
       • コスト効率の良いデータ保持やコンプライアンス要件に対応する際に有用です
       • Log Analytics への送信と併用することも可能です

1
2
3
4
5
6
7
8

destinations: {
  logAnalytics: [
    {
      workspaceResourceId: logAnalytics.id
      name: 'logAnalyticsDestination'
    }
  ]
}

3. dataFlows (データフロー)
   • データソースから送信先へのデータの流れを定義します
   • 各フローには以下のプロパティがあります:
     • streams: 入力となるデータストリーム名の配列
     • destinations: 送信先名の配列
     • transformKql (オプション): KQL を使用したデータ変換
     • outputStream (オプション): 変換後のストリーム名 (カスタムテーブルに送信する場合など)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

dataFlows: [
  {
    destinations: [
      'logAnalyticsDestination'
    ]
    outputStream: 'Microsoft-W3CIISLog'
    streams: [
      'Microsoft-W3CIISLog'
    ]
    transformKql: 'source'
  }
]

4. streamDeclarations (ストリーム定義) (オプション)
   • カスタムストリームのスキーマ (列名と型) を定義します
   • カスタムログを収集する際に必要です
     • 既知のストリーム（ログ）とは異なり、どんなデータが来るかわからないため、事前にスキーマを定義する必要があります
   • 各列の名前とデータ型 (string, int, datetime, boolean など) を指定します

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

streamDeclarations: {
  'Custom-Text-customtext_analysis_CL': {
    columns: [
      {
        name: 'TimeGenerated'
        type: 'datetime'
      }
      {
        name: 'RawData'
        type: 'string'
      }
      {
        name: 'FilePath'
        type: 'string'
      }
      {
        name: 'Computer'
        type: 'string'
      }
    ]
  }
}

データの流れ

DCR 内でのデータの流れは以下のようになります:

1. dataSources がデータを収集し、streams (データストリーム) を生成

• カスタムログの場合は、streamDeclarations で定義されたスキーマを使用

2. dataFlows が streams を受け取る
3. dataFlows 内で transformKql によるデータ変換 (オプション)
4. dataFlows が outputStream を指定して destinations に送信
5. destinations で定義された Log Analytics ワークスペースなどにデータが格納される

ざっくり手順

本記事では、以下の 5 つのシナリオを順番に実装していきます:

1. IIS ログの収集

   • 基本的な DCR の作成
   • IIS ログを標準テーブル (W3CIISLog) に収集

2. IIS ログを Transform して収集

   • KQL を使用したデータ変換
   • 不要なフィールドの削除やデータの加工

3. IIS ログをカスタムテーブルにも収集

   • 1つのデータストリームから 2つのテーブルに送信
   • 標準テーブルとカスタムテーブルの両方に格納

4. IIS ログをカスタムテーブルにだけ収集

   • カスタムテーブルへの直接送信
   • 標準テーブルを使用しない

5. カスタムテキストログを 3 つのテーブルに収集

   • カスタムログソースの定義
   • テーブルプランに応じた複数テーブルへの振り分け

事前準備

各シナリオを試す前に、以下のリソースを準備します:

必要なリソース

• Log Analytics ワークスペース: ログの送信先
• Windows 仮想マシン: IIS がインストールされた VM
• Azure Monitor Agent: VM にインストール済み

Bicep ファイルの準備

本記事では、Bicep を使用して DCR を作成します。
以下のような基本構造を使用します:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101

param location string = resourceGroup().location
param suffix string = 'bicep'
@secure()
param password string
param vnetAddress string = '10.0.0.0/16'

// Log Analytics Workspace
module logAnalytics 'br/public:avm/res/operational-insights/workspace:0.14.1' = {
  params: {
    name: 'log-${suffix}'
    location: location
  }
}

// Vnet
module vnet 'br/public:avm/res/network/virtual-network:0.7.2' = {
  params: {
    name: 'vnet-${suffix}'
    location: location
    addressPrefixes: [
      vnetAddress
    ]
    subnets: [
      {
        name: 'default'
        addressPrefix: cidrSubnet(vnetAddress, 24, 0)
        networkSecurityGroupResourceId: nsg.outputs.resourceId
      }
    ]
  }
}

// Network Security Group
module nsg 'br/public:avm/res/network/network-security-group:0.5.2' = {
  params: {
    name: 'nsg-${suffix}'
    location: location
    securityRules: [
     {
      name: 'allow_http'
      properties: {
        access: 'Allow'
        direction: 'Inbound'
        priority: 100
        protocol: 'Tcp'
        sourceAddressPrefix: '*'
        sourcePortRange: '*'
        destinationAddressPrefix: '*'
        destinationPortRange: '80'
      }
     }
    ]
  }
}

// IIS VM
module iisVm 'br/public:avm/res/compute/virtual-machine:0.21.0' = {
  params: {
    name: 'iisvm-${suffix}'
    location: location
    adminUsername: 'AzureAdmin'
    adminPassword: password
    availabilityZone: -1
    imageReference:{
      publisher: 'MicrosoftWindowsServer'
      offer: 'WindowsServer'
      sku: '2022-datacenter-azure-edition-hotpatch'
      version: 'latest'
    }
    nicConfigurations: [
      {
        ipConfigurations: [
          {
            name: 'ipconfig1'
            pipConfiguration: {
              publicIpNameSuffix: '-pip'
            }
            privateIPAddressVersion: 'IPv4'
            subnetResourceId: vnet.outputs.subnetResourceIds[0]
          }
        ]
      }
    ]
    osDisk: {
      diskSizeGB: 128
      managedDisk: {
        storageAccountType: 'Premium_LRS'
      }
    }
    osType: 'Windows'
    vmSize: 'Standard_D4s_v4'
    extensionCustomScriptConfig: {
      name: 'install_iis'
      settings: {
        commandToExecute: 'powershell -Command "Install-WindowsFeature -name Web-Server -IncludeManagementTools"'
      }
    }
  }
}

output vmPublicIP string = iisVm.outputs.nicConfigurations[0].ipConfigurations[0].publicIP

それでは、各シナリオを詳しく見ていきましょう。

シナリオ 1: IIS ログの収集

最も基本的なシナリオとして、IIS ログを標準の W3CIISLog テーブルに収集します。

DCR の構成

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

param location string = resourceGroup().location
param suffix string = 'bicep'

// Data Collection Rule
resource dcr 'Microsoft.Insights/dataCollectionRules@2023-03-11' = {
  name: 'dcr-${suffix}'
  location: location
  properties: {
    dataSources: {
      iisLogs: [
        {
          streams: [
            'Microsoft-W3CIISLog'
          ]
          name: 'iisLogsDataSource'
        }
      ]
    }
    destinations: {
      logAnalytics: [
        {
          workspaceResourceId: logAnalytics.id
          name: 'logAnalyticsDestination'
        }
      ]
    }
    dataFlows: [
      {
        destinations: [
          'logAnalyticsDestination'
        ]
        outputStream: 'Microsoft-W3CIISLog'
        streams: [
          'Microsoft-W3CIISLog'
        ]
        transformKql: 'source'
      }
    ]
  }
}

// Reference existing Log Analytics Workspace
resource logAnalytics 'Microsoft.OperationalInsights/workspaces@2025-02-01' existing = {
  name: 'log-${suffix}'
}

// Reference existing VM
resource iisVm 'Microsoft.Compute/virtualMachines@2025-04-01' existing = {
  name: 'iisvm-${suffix}'
}

// Data Collection Rule Association
resource dcrAssociation 'Microsoft.Insights/dataCollectionRuleAssociations@2023-03-11' = {
  name: 'dcra-${suffix}'
  scope: iisVm
  properties: {
    dataCollectionRuleId: dcr.id
  }
}

ポイント

• dataSources: IIS ログをデータソースとして定義
  • streams: Microsoft-W3CIISLog という標準のデータストリームを使用
• destinations: Log Analytics ワークスペースを送信先として指定
• dataFlows: データストリームと送信先を紐づけ、変換処理なしで直接送信

データフローの図解

graph LR
    IIS[IIS Logs] --> DS[Data Stream:<br/>Microsoft-W3CIISLog]
    DS --> DF1[Data Flow 1:<br/>変換なし]
    DF1 --> T1[W3CIISLog<br/>標準テーブル]
    
    classDef source fill:#4CAF50,stroke:#333,color:#fff
    classDef flow fill:#2196F3,stroke:#333,color:#fff
    classDef dest fill:#FF9800,stroke:#333,color:#fff
    
    class IIS,DS source
    class DF1 flow
    class T1 dest

確認

デプロイ後、数分待ってから Log Analytics ワークスペースで以下のクエリを実行します:

W3CIISLog
| where TimeGenerated > ago(30m)
| take 10

いくつかのステータスコードが確認できています

シナリオ 2: IIS ログを Transform して収集

次に、KQL を使用してデータを変換してから収集します。
不要なフィールドを削除したり、新しいフィールドを追加したりできます。
今回は 下記のスクリーンショットにあるように、ステータス コードをもとにフィルター処理などを行い、その結果を収集します。

DCR の構成

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

// Data Collection Rule
resource dcr 'Microsoft.Insights/dataCollectionRules@2023-03-11' = {
  name: 'dcr-${suffix}'
  location: location
  properties: {
    dataSources: {
      iisLogs: [
        {
          streams: [
            'Microsoft-W3CIISLog'
          ]
          name: 'iisLogsDataSource'
        }
      ]
    }
    destinations: {
      logAnalytics: [
        {
          workspaceResourceId: logAnalytics.id
          name: 'logAnalyticsDestination'
        }
      ]
    }
    dataFlows: [
      {
        destinations: [
          'logAnalyticsDestination'
        ]
        outputStream: 'Microsoft-W3CIISLog'
        streams: [
          'Microsoft-W3CIISLog'
        ]
        transformKql: 'source | where scStatus  !in ("200", "304") | extend ErrorCategory = case(scStatus startswith "4", "ClientError", scStatus startswith "5", "ServerError", "Other") | project TimeGenerated, Computer, sSiteName, csMethod, csUriStem, scStatus, scWin32Status, TimeTaken, csUserAgent, ErrorCategory'
      }
    ]
  }
}

Transform KQL の説明

使用している KQL の各部分を解説します:

source 
| where scStatus !in ("200", "304")  // 正常なステータスコードを除外
| extend ErrorCategory = case(
    scStatus startswith "4", "ClientError",
    scStatus startswith "5", "ServerError", 
    "Other"
  )  // エラーカテゴリを追加
| project TimeGenerated, Computer, sSiteName, csMethod, csUriStem, 
          scStatus, scWin32Status, TimeTaken, csUserAgent, ErrorCategory
  // 必要なフィールドのみを選択

ポイント

• transformKql: データ変換のロジックを KQL で記述
• source: 元のデータストリームを参照する予約語
• where: 条件によるフィルタリング（200 と 304 を除外）
• extend: 新しいフィールドの追加（ErrorCategory）
• project: 出力するフィールドの選択

データフローの図解

graph LR
    IIS[IIS Logs] --> DS[Data Stream:<br/>Microsoft-W3CIISLog]
    DS --> DF1[Data Flow 1:<br/>変換あり]
    DF1 --> T1[W3CIISLog<br/>標準テーブル]
    
    classDef source fill:#4CAF50,stroke:#333,color:#fff
    classDef flow fill:#2196F3,stroke:#333,color:#fff
    classDef dest fill:#FF9800,stroke:#333,color:#fff
    
    class IIS,DS source
    class DF1 flow
    class T1 dest

確認

KQL を実行して確認します:

W3CIISLog
| where TimeGenerated > ago(30m)

VM にログインすると 200 のログ（黄色ハイライト）が記録されていますが、 DCR の Transform KQL により、除外されていることが確認できます。
逆に除外対象ではない 404 のログ（赤色枠）は収集されていることがわかります。

シナリオ 3: IIS ログをカスタムテーブルにも収集

1つのデータストリームから、標準テーブルとカスタムテーブルの両方に送信します。

カスタムテーブルの作成

まず、Log Analytics ワークスペースに補助プランのカスタムテーブルを作成します:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

# パラメータ定義（必要に応じて既定値を書き換えてください）
Param(
    [string]$SubscriptionId = "xxx",
    [string]$ResourceGroupName = "xxx",
    [string]$WorkspaceName = "xxx"
)

# 共通 API バージョン / ベースパス
$ApiVersion = "2023-01-01-preview"
$BasePath   = "/subscriptions/$SubscriptionId/resourcegroups/$ResourceGroupName/providers/microsoft.operationalinsights/workspaces/$WorkspaceName"


# Create Auxiliary Table iislog_CL in Log Analytics Workspace
$tableParams = @'
{
    "properties": {
        "schema": {
               "name": "iislog_CL",
               "columns": [
                    {
                        "name": "TimeGenerated",
                        "type": "DateTime"
                    },
                    {
                        "name": "cIP",
                        "type": "string"
                    },
                    {
                        "name": "scStatus",
                        "type": "string"
                    }
              ]
        },
        "plan": "Auxiliary"
    }
}
'@

Invoke-AzRestMethod -Path "$BasePath/tables/iislog_CL?api-version=$ApiVersion" -Method PUT -payload $tableParams

DCR の構成

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

resource dcr 'Microsoft.Insights/dataCollectionRules@2023-03-11' = {
  name: 'dcr-${suffix}'
  location: location
  properties: {
    dataSources: {
      iisLogs: [
        {
          streams: [
            'Microsoft-W3CIISLog'
          ]
          name: 'iisLogsDataSource'
        }
      ]
    }
    destinations: {
      logAnalytics: [
        {
          workspaceResourceId: logAnalytics.id
          name: 'logAnalyticsDestination'
        }
      ]
    }
    dataFlows: [
      {
        destinations: [
          'logAnalyticsDestination'
        ]
        outputStream: 'Microsoft-W3CIISLog'
        streams: [
          'Microsoft-W3CIISLog'
        ]
        transformKql: 'source | where scStatus  !in ("200", "304") | extend ErrorCategory = case(scStatus startswith "4", "ClientError", scStatus startswith "5", "ServerError", "Other") | project TimeGenerated, Computer, sSiteName, csMethod, csUriStem, scStatus, scWin32Status, TimeTaken, csUserAgent, ErrorCategory'
      }
      // 2つ目の dataFlow を追加し、カスタムテーブルへ送信
      {
        destinations: [
          'logAnalyticsDestination'
        ]
        outputStream: 'Custom-iislog_CL'
        streams: [
          'Microsoft-W3CIISLog'
        ]
        transformKql: 'source | project TimeGenerated, cIP, scStatus'
      }
    ]
  }
}

デプロイ後、Azure Portal で DCR の設定を確認してみます。
データソース > ターゲット を確認すると Azure Monitor Logs (Log Analytics) のことしか書かれていません。
このように Azure Portal の GUI からでは、通常の [W3CIISLog] テーブルへ保存する設定しかできません。

一方で JSON 形式で DCR の内容を確認すると、2 つの dataFlows が定義されていることがわかります。
DCR の設定は Bicep や ARM テンプレートで行うことで、Azure Portal の UI ではできないような高度な構成が可能になります。

ポイント

• 複数の dataFlows: 同じデータストリームから複数のフローを定義
• outputStream: 送信先のテーブルを指定（Custom- プレフィックスでカスタムテーブルを指定）
• フィールド名のマッピング: Computer = Computer のように、元のフィールド名と出力先のフィールド名を指定

データフローの図解

graph LR
    IIS[IIS Logs] --> DS[Data Stream:<br/>Microsoft-W3CIISLog]
    DS --> DF1[Data Flow 1:<br/>変換あり]
    DS --> DF2[Data Flow 2:<br/>変換あり]
    DF1 --> T1[W3CIISLog<br/>標準テーブル]
    DF2 --> T2[iislog_CL<br/>カスタムテーブル]
    
    classDef source fill:#4CAF50,stroke:#333,color:#fff
    classDef flow fill:#2196F3,stroke:#333,color:#fff
    classDef dest fill:#FF9800,stroke:#333,color:#fff
    
    class IIS,DS source
    class DF1,DF2 flow
    class T1,T2 dest

確認

2つのテーブルそれぞれにデータが格納されているか確認します

まずは標準の W3CIISLog テーブルを確認します:

// 標準テーブルの確認
W3CIISLog
| where TimeGenerated > ago(30m)

次にカスタムテーブルを確認します:

// カスタムテーブルの確認
iislog_CL
| where TimeGenerated > ago(30m)

両方のテーブルにデータが格納されていることが確認できました。
また iislog_CL テーブルでは、Transform KQL により cIP と scStatus のカラムだけにしていますが、ステータスコードによるフィルターは実施していません。
そのため、200 のログも格納されていることがわかります。

シナリオ 4: IIS ログをカスタムテーブルにだけ収集

標準テーブルを経由せず、カスタムテーブルに直接送信します。
このシナリオでは、補助プランに対応していない標準のテーブル W3CIISLog を使用しないことで、コスト削減を図ることができます。

DCR の構成

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

resource dcr 'Microsoft.Insights/dataCollectionRules@2023-03-11' = {
  name: 'dcr-${suffix}'
  location: location
  properties: {
    dataSources: {
      iisLogs: [
        {
          streams: [
            'Microsoft-W3CIISLog'
          ]
          name: 'iisLogsDataSource'
        }
      ]
    }
    destinations: {
      logAnalytics: [
        {
          workspaceResourceId: logAnalytics.id
          name: 'logAnalyticsDestination'
        }
      ]
    }
    dataFlows: [
      // カスタムテーブルへ送信する dataFlow のみを定義
      {
        destinations: [
          'logAnalyticsDestination'
        ]
        outputStream: 'Custom-iislog_CL'
        streams: [
          'Microsoft-W3CIISLog'
        ]
        transformKql: 'source | project TimeGenerated, cIP, scStatus'
      }
    ]
  }
}

先ほどと同じく、Azure Portal で DCR の設定を確認してみます。
ターゲットの設定は変わらず Azure Monitor Logs (Log Analytics) のみが表示されます。

JSON 形式で DCR の内容を確認すると、dataFlows は 1 つだけであり、W3CIISLog テーブルにはデータが送信されないことがわかります。

ポイント

• 標準テーブル不使用: W3CIISLog テーブルにはデータが送信されない
• dataFlows: カスタムテーブルへの送信のみを定義

データフローの図解

graph LR
    IIS[IIS Logs] --> DS[Data Stream:<br/>Microsoft-W3CIISLog]
    DS --> DF2[Data Flow 1:<br/>変換あり]
    DF2 --> T2[iislog_CL<br/>カスタムテーブル]
    
    classDef source fill:#4CAF50,stroke:#333,color:#fff
    classDef flow fill:#2196F3,stroke:#333,color:#fff
    classDef dest fill:#FF9800,stroke:#333,color:#fff
    
    class IIS,DS source
    class DF2 flow
    class T2 dest

確認

ほぼ同時刻にログ検索を実行しました
実行時間がわかるようにそれぞれに executionTime というカラムを追加しています

標準の W3CIISLog テーブルへのデータの保存は停止していますが、カスタム テーブルへのデータの保存は継続していることが確認できます。

シナリオ 5: カスタムテキストログを 3 つのテーブルに収集

最後のシナリオとして、カスタムテキストログを読み込み、条件に応じて 3 つの異なるテーブルに振り分けます。
このシナリオは実は過去に Azure Monitor のテーブルプランの違いを試し隊 – クラウドを勉強し隊 で紹介しているので検証はそちらを参照してください。

DCR の構成

Azure Monitor のテーブルプランの違いを試し隊 – クラウドを勉強し隊 で使用した DCR を振り返ります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91

resource dataCollectionRule 'Microsoft.Insights/dataCollectionRules@2023-03-11' = {
  name: '${prefix}-dcr'
  location: location
  properties: {
    streamDeclarations: {
      // カスタム テキストログのため、Azure Monitor Agent にスキーマを伝える必要がある
      'Custom-Text-customtext_analysis_CL': {
        columns: [
          {
            name: 'TimeGenerated'
            type: 'datetime'
          }
          {
            name: 'RawData'
            type: 'string'
          }
          {
            name: 'FilePath'
            type: 'string'
          }
          {
            name: 'Computer'
            type: 'string'
          }
        ]
      }
    }
    dataSources: {
      logFiles: [
        // カスタム ログなのでファイルパスなどを指定
        {
          streams: [
            'Custom-Text-customtext_analysis_CL' // Stream 名。カスタム型の場合は、Custom-<TableName>
          ]
          filePatterns: [
            'C:\\Logs\\imds-customtext.log' // フォルダ、ファイルパターン
          ]
          format: 'text' // ログ形式。text または json
          settings: {
            // 時間のフォーマット
            text: {
              recordStartTimestampFormat: 'YYYY-MM-DD HH:MM:SS'
            }
          }
          name: 'customTextLogDataSource' // DCR 内の一意な名前
        }
      ]
    }
    destinations: {
      logAnalytics: [
        {
          workspaceResourceId: logAnalyticsWorkspace.id 
          name: 'logAnalyticsDestination' 
        }
      ]
    }
    dataFlows: [
      // 3つのテーブルへ送信するので、3 つの dataFlow を定義
      {
        destinations: [
          'logAnalyticsDestination'
        ]
        outputStream: 'Custom-customtext_analysis_CL' 
        streams: [
          'Custom-Text-customtext_analysis_CL'
        ]
        transformKql: 'source' 
      }
      {
        destinations: [
          'logAnalyticsDestination'
        ]
        outputStream: 'Custom-customtext_basic_CL' 
        streams: [
          'Custom-Text-customtext_analysis_CL' 
        ]
        transformKql: 'source' 
      }
      {
        destinations: [
          'logAnalyticsDestination'
        ]
        outputStream: 'Custom-customtext_auxiliary_CL' 
        streams: [
          'Custom-Text-customtext_analysis_CL'
        ]
        transformKql: 'source' 
      }
    ]
  }
}

ポイント

• streamDeclarations: カスタムログのスキーマを定義。これがないとどんな形式のデータなのかわからない
• dataSources: カスタムログのファイルパスと形式を指定
• dataFlows: 3 つの異なるテーブルに送信する

データフローの図解

graph TB
    LOG[Custom Text Logs<br/>C:\Logs\*.log] --> DS[Data Stream:<br/>Custom-Text-customtext_analysis_CL]
    DS --> DF1[Data Flow 1:<br/>Analysis ログ]
    DS --> DF2[Data Flow 2:<br/>Basic ログ]
    DS --> DF3[Data Flow 3:<br/>Auxiliary ログ]
    DF1 --> T1[customtext_analysis_CL<br/>Analytics テーブル]
    DF2 --> T2[customtext_basic_CL<br/>Basic テーブル]
    DF3 --> T3[customtext_auxiliary_CL<br/>Auxiliary テーブル]
    
    classDef source fill:#4CAF50,stroke:#333,color:#fff
    classDef flow fill:#2196F3,stroke:#333,color:#fff
    classDef dest fill:#FF9800,stroke:#333,color:#fff
    
    class LOG,DS source
    class DF1,DF2,DF3 flow
    class T1,T2,T3 dest

確認

実行結果は Azure Monitor のテーブルプランの違いを試し隊 – クラウドを勉強し隊 を見てください。
無事に1つのカスタムログソースから 3 つのテーブルにデータが格納されていることが確認できます。

DCR の Tips

各シナリオを通じて学んだ Tips をまとめます:

1. Azure Portal の限界を理解する

Azure Portal の GUI では、基本的な DCR 設定しかできません。
シナリオ 3 で確認したように、カスタムテーブルへの送信設定は Portal の UI には表示されませんが、JSON では複数の dataFlows が定義されています。
高度な構成を実現するには Bicep や ARM テンプレートが必須です。

2. streamDeclarations はカスタムストリームに必須

標準のストリーム（Microsoft-W3CIISLog、Microsoft-Event など）は Azure が事前にスキーマを定義していますが、カスタムログを収集する場合は streamDeclarations でスキーマを明示的に定義する必要があります。
どんなデータが来るかわからないため、列名とデータ型（string, int, datetime, boolean など）を事前に指定することで、データの整合性を保ちます。

3. 複数の dataFlows で柔軟なルーティング

1 つのデータソースから複数の送信先にデータを送る場合、複数の dataFlows を定義します。
それぞれのフローで異なる transformKql を適用できるため、同じデータソースから用途に応じて異なる形式で複数のテーブルに保存できます。

例:

• 全ログを標準テーブルに保存（監査用）
• エラーログのみをカスタムテーブルに保存（アラート用）
• 特定のフィールドだけを別のテーブルに保存（レポート用）

4. outputStream の命名規則

カスタムテーブルに送信する場合、outputStream には Custom- プレフィックスを付けた名前を指定します。
例えばテーブル名が iislog_CL の場合、outputStream は Custom-iislog_CL となります。

5. カスタムテーブル作成は事前に

DCR をデプロイする前に、カスタムテーブルを Log Analytics ワークスペースに作成しておく必要があります。
テーブルが存在しない状態で DCR をデプロイすると、データが送信されず、エラーになります。

6. DCR Association を忘れずに

DCR を作成しただけでは、VM からデータは収集されません。
dataCollectionRuleAssociations リソースを使って、DCR と VM を関連付ける必要があります。

1
2
3
4
5
6
7

resource dcrAssociation 'Microsoft.Insights/dataCollectionRuleAssociations@2023-03-11' = {
  name: 'dcra-${suffix}'
  scope: iisVm
  properties: {
    dataCollectionRuleId: dcr.id
  }
}

7. テーブルプランによるコスト最適化

シナリオ 5 で実施したように、カスタムテーブルでは Basic ログや Auxiliary ログなど、用途に応じたテーブルプランを選択することで、コストを最適化できます。
詳細は Azure Monitor のテーブルプランの違いを試し隊 を参照してください。

8. デバッグには JSON ビューを活用

DCR の設定を確認する際は、Azure Portal の JSON ビュー（リソース JSON）を使うと、実際の構成を詳細に確認できます。
特に複数の dataFlows や streamDeclarations の設定を確認する際に便利です。

9. 段階的なデプロイ

複雑な DCR を作成する場合は、以下の順序で段階的にデプロイすることをおすすめします:

1. まず基本的な DCR を作成（シナリオ 1）
2. transformKql を追加してデータ変換を確認（シナリオ 2）
3. カスタムテーブルへの送信を追加（シナリオ 3, 4）
4. 複雑なカスタムログ収集を実装（シナリオ 5）

各ステップでデータが正しく収集されることを確認してから次に進むことで、問題の切り分けが容易になります。

まとめ

本記事では、Data Collection Rule (DCR) の deep dive として、5 つのシナリオを実装しました:

1. 基本的な収集: IIS ログを標準テーブルに収集
2. データ変換: KQL を使用したフィルタリングとフィールド追加
3. 複数テーブルへの送信: 1 つのデータストリームから標準テーブルとカスタムテーブルへ
4. カスタムテーブル専用: 完全にカスタマイズされたスキーマでの収集
5. テーブルプランを活用: カスタムログを 3 つの異なるテーブルプラン（Analytics、Basic、Auxiliary）に振り分け

主要な学び

• Bicep の活用: Azure Portal では実現できない高度な DCR 構成が可能
• Transform KQL: データの変換、フィルタリング、加工を柔軟に実行
• カスタムテーブル: 用途に応じた最適なスキーマ設計
• データフローの分岐: 1 つのデータソースから複数の送信先へ効率的に配信

DCR を使いこなすことで、Azure Monitor でのログ収集が非常に柔軟になります。
ぜひ、実際の環境で試してみてください!

今回利用したコードは GitHub リポジトリに公開しています:
https://github.com/NakayamaKento/Azure_Bicep/tree/main/Blog/dcr_deepdive

参考リンク

• Data collection rules in Azure Monitor
• Data collection transformations
• Azure Monitor Agent overview
• Create custom tables in Azure Monitor Logs
• Kusto Query Language (KQL) reference
• Bicep resource definition for DCR