Azure Monitor Agent を使用して Azure Batch プールのコンピューティング ノードを監視する

Azure Batchアカウントプラットフォームのメトリクスは、プール、ノード、コア、ジョブ、タスクに関する情報を提供します。 CPU、メモリ、ディスク、ネットワーク使用状況などのゲストOSのパフォーマンスを監視するには、プールのコンピュートノードにAzure Monitor Agent(AMA)をインストールしてください。

この記事では、次の方法について説明します。

  • ユーザー割り当ての管理IDとAMAでバッチプールを作成します。
  • LinuxのパフォーマンスカウンターとSyslog用のデータ収集ルール(DCR)を作成しましょう。
  • DCRをバッチプールリソースに関連付けます。
  • Log AnalyticsとAzure Monitor Metricsでデータを検証してください。

例はAzure CLIとLinuxプールを使用しています。 同じアーキテクチャはWindows AMA拡張とWindowsデータソースを用いたWindowsプールをサポートしています。

Important

AMAによるバッチプール計算ノードの監視は、 ユーザーサブスクリプション プール割り当てモードを使用するバッチアカウントのみでサポートされています。 バッチサービスプール割り当てモードでは、顧客がアクセスできないバッチ管理のサブスクリプションにコンピュートノードが作成されます。

ノード監視の仕組み

監視されたバッチプールは以下のリソースを使用します:

  • ユーザーサブスクリプションプール割り当てモードのバッチアカウントです。
  • ユーザー割り当ての管理型アイデンティティを持つバッチプールです。
  • プール作成時にインストールされるAzure Monitor Agent拡張機能です。
  • 収集すべきデータと宛先を指定するDCR。
  • BatchプールのAzure Resource ManagerリソースをターゲットとするDCRアソシエーションです。
  • ログデータ用のLog Analyticsワークスペースと、オプションでゲストメトリクス用のAzure Monitor Metricsも利用できます。

DCRをバッチプールリソースIDに関連付けます:

/subscriptions/<subscription-id>/resourceGroups/<resource-group>/
providers/Microsoft.Batch/batchAccounts/<batch-account>/pools/<pool-name>

DCRをBatchがプール用に作成する仮想マシンのスケールセットだけに関連付けないでください。 バッチはそのスケールセットのライフサイクルを管理します。 プールがノードゼロにスケールすると、Batchはスケールセットを削除し、後のリサイズ時に新しいものを作成できます。

Log Analyticsレコードはバッチで作成された計算リソースのリソースIDを保持します。 ゲスト指標は、Linuxの場合はazure.vm.linux.guestmetrics名前空間の現在のバッチ作成仮想マシンスケールセット、Windowsの場合は仮想マシンゲスト(Windows)名前空間で利用可能です。

前提条件

開始する前に、次のものが必要です。

DCR、Log Analytics workspace、バッチプールを同じAzureリージョン内に作成します。 プールが外部アクセス制限のある仮想ネットワークを使用している場合は、Azure Monitorエージェントのネットワーク要件を確認してください。

Tip

拡張を持つプールは仮想マシン構成を使用しなければなりません。 既存のプールに拡張機能を追加することはできません。 AMAを追加、削除、更新するには、新しいプールを作成してください。 詳細については、「 バッチプールで拡張機能を使う」をご覧ください。

環境変数の設定

リソースの変数を設定しましょう。 次のプレースホルダー値を置き換えます。

subscriptionId="<subscription-id>"
resourceGroup="<resource-group>"
location="<location>"
batchAccount="<batch-account-name>"
poolName="<pool-name>"
workspaceName="<log-analytics-workspace-name>"
identityName="<managed-identity-name>"
dcrName="<data-collection-rule-name>"

az account set --subscription "$subscriptionId"

identityId=$(az identity show \
  --resource-group "$resourceGroup" \
  --name "$identityName" \
  --query id \
  --output tsv)

workspaceId=$(az monitor log-analytics workspace show \
  --resource-group "$resourceGroup" \
  --workspace-name "$workspaceName" \
  --query id \
  --output tsv)

batchAccountId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Batch/batchAccounts/$batchAccount"
poolResourceId="$batchAccountId/pools/$poolName"
dcrId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Insights/dataCollectionRules/$dcrName"

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

以下のデータ収集ルール(DCR)は、60秒ごとに一般的なLinuxパフォーマンスカウンターを収集します。 それは、カウンターを Log Analytics の Perf テーブルと Azure Monitor メトリックの両方に送信します。 また、警告やより重度の高いSyslogレコードをLog Analyticsに送信します。

Azure Monitor Metrics はゲストパフォーマンス計数器の先としてプレビュー中です。 現在の制限については、「Azure Monitor Agentでパフォーマンスカウンターを収集する」を参照してください。

ファイル名は dcr.json。 <location> と <workspace-resource-id> を独自の値に置き換えます。

{
  "location": "<location>",
  "kind": "Linux",
  "properties": {
    "dataSources": {
      "performanceCounters": [
        {
          "name": "batchNodePerformance",
          "streams": [
            "Microsoft-Perf",
            "Microsoft-InsightsMetrics"
          ],
          "samplingFrequencyInSeconds": 60,
          "counterSpecifiers": [
            "\\Processor(*)\\% Processor Time",
            "\\Processor(*)\\% User Time",
            "\\Processor(*)\\% Privileged Time",
            "\\Processor(*)\\% Idle Time",
            "\\Memory\\% Available Memory",
            "\\Memory\\Used Memory MBytes",
            "\\Memory\\% Used Memory",
            "\\Logical Disk(*)\\% Free Space",
            "\\Logical Disk(*)\\Free Megabytes",
            "\\Logical Disk(*)\\Disk Reads/sec",
            "\\Logical Disk(*)\\Disk Writes/sec",
            "\\Logical Disk(*)\\Disk Read Bytes/sec",
            "\\Logical Disk(*)\\Disk Write Bytes/sec",
            "\\Network(*)\\Total Bytes Transmitted",
            "\\Network(*)\\Total Bytes Received",
            "\\Network(*)\\Total Bytes",
            "\\System\\Uptime"
          ]
        }
      ],
      "syslog": [
        {
          "name": "batchNodeSyslog",
          "streams": [
            "Microsoft-Syslog"
          ],
          "facilityNames": [
            "auth",
            "authpriv",
            "cron",
            "daemon",
            "kern",
            "syslog",
            "user"
          ],
          "logLevels": [
            "Warning",
            "Error",
            "Critical",
            "Alert",
            "Emergency"
          ]
        }
      ]
    },
    "destinations": {
      "logAnalytics": [
        {
          "name": "batchMonitorWorkspace",
          "workspaceResourceId": "<workspace-resource-id>"
        }
      ],
      "azureMonitorMetrics": {
        "name": "azureMonitorMetrics-default"
      }
    },
    "dataFlows": [
      {
        "streams": [
          "Microsoft-Perf"
        ],
        "destinations": [
          "batchMonitorWorkspace"
        ]
      },
      {
        "streams": [
          "Microsoft-InsightsMetrics"
        ],
        "destinations": [
          "azureMonitorMetrics-default"
        ]
      },
      {
        "streams": [
          "Microsoft-Syslog"
        ],
        "destinations": [
          "batchMonitorWorkspace"
        ]
      }
    ]
  }
}

DCRの作成または更新:

az rest \
  --method put \
  --url "https://management.azure.com${dcrId}?api-version=2022-06-01" \
  --body @dcr.json

カウンターの選択や取り込みコストの制御については、「Azure Monitor Agentでパフォーマンスカウンターを収集する」をご覧ください。

Azure Monitor Agent を使用してプールを作成する

ファイル名は pool.json。 以下の例はUbuntu 22.04を使用し、Linux AMA拡張機能をインストールしています。 <managed-identity-resource-id>を$identityIdの値に置き換えてください。

{
  "name": "<pool-name>",
  "type": "Microsoft.Batch/batchAccounts/pools",
  "identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "<managed-identity-resource-id>": {}
    }
  },
  "properties": {
    "vmSize": "STANDARD_D2S_V3",
    "taskSlotsPerNode": 1,
    "taskSchedulingPolicy": {
      "nodeFillType": "Pack"
    },
    "deploymentConfiguration": {
      "virtualMachineConfiguration": {
        "imageReference": {
          "publisher": "canonical",
          "offer": "0001-com-ubuntu-server-jammy",
          "sku": "22_04-lts",
          "version": "latest"
        },
        "nodeAgentSkuId": "batch.node.ubuntu 22.04",
        "extensions": [
          {
            "name": "AzureMonitorAgent",
            "publisher": "Microsoft.Azure.Monitor",
            "type": "AzureMonitorLinuxAgent",
            "typeHandlerVersion": "1.0",
            "autoUpgradeMinorVersion": true,
            "enableAutomaticUpgrade": true,
            "settings": {
              "authentication": {
                "managedIdentity": {
                  "identifier-name": "mi_res_id",
                  "identifier-value": "<managed-identity-resource-id>"
                }
              }
            }
          }
        ]
      }
    },
    "scaleSettings": {
      "fixedScale": {
        "targetDedicatedNodes": 1,
        "targetLowPriorityNodes": 0,
        "resizeTimeout": "PT15M"
      }
    }
  }
}

バッチ管理APIを使ってプールを作成する:

az rest \
  --method put \
  --url "https://management.azure.com${poolResourceId}?api-version=2024-07-01" \
  --body @pool.json

Windowsプールの場合は、以下をご利用ください:

  • 拡張タイプ AzureMonitorWindowsAgent。
  • Windowsイメージと互換性のあるバッチノードエージェントSKU。
  • Windows DCR(kindがWindowsに設定されています)。
  • Windowsパフォーマンスカウンターや必要に応じてSyslogの代わりにWindowsイベントコレクションも使用します。

WindowsとLinuxの両方のカウンターに1つのDCRを使うのはやめましょう。 一部のカウンター名が同じメトリックに対応し、重複収集を引き起こすことがあります。

DCRをバッチプールと関連付ける

バッチプールリソースでアソシエーションを作成します:

az monitor data-collection rule association create \
  --name "batch-pool-monitoring" \
  --resource "$poolResourceId" \
  --rule-id "$dcrId"

関連性を確認する:

az monitor data-collection rule association list \
  --resource "$poolResourceId" \
  --output table

ノードが削除または置き換えられた場合でも、この関連付けはプール上に残ります。 現在の Batch によって作成された仮想マシン スケール セットのみを対象とする関連付けに置き換えないでください。

エージェントとログ収集の検証

ノードがアイドル状態になってから、最初のレコードが届くまで最大5分かかる場合があります。

エージェントの心拍を確認してください

Log Analyticsワークスペースで以下のクエリを実行してください:

Heartbeat
| where TimeGenerated > ago(30m)
| summarize
    Samples = count(),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    AgentVersion = any(Version)
    by Computer, _ResourceId

オペレーターは通常、1分間に1回の心拍を送信します。

パフォーマンスカウンターの検証

Perf
| where TimeGenerated > ago(30m)
| summarize
    Samples = count(),
    Average = avg(CounterValue),
    P95 = percentile(CounterValue, 95),
    Maximum = max(CounterValue)
    by Computer, ObjectName, CounterName, InstanceName
| order by ObjectName asc, CounterName asc

Linuxの論理ディスクカウンターには複数のマウントポイントインスタンスが含まれています。 チャートやアラートを作成する際は InstanceName でフィルタリングし、読み取り専用マウントや一時マウントが結果を歪めないようにしましょう。

Syslogの検証

Syslog
| where TimeGenerated > ago(30m)
| project
    TimeGenerated,
    Computer,
    Facility,
    SeverityLevel,
    ProcessName,
    SyslogMessage,
    _ResourceId
| order by TimeGenerated desc

ゲスト指標を見る

DCRがMicrosoft-InsightsMetricsストリームをAzure Monitorメトリクス宛先に送信すると、ゲストメトリクスは現在バッチで作成された仮想マシンスケールセットに表示されます。

  1. Azureポータルで、Batchがプール用に作成した仮想マシンのスケールセットを開きます。
  2. [メトリック] を選びます。
  3. メトリック名前空間については、Linuxならazure.vm.linux.guestmetrics、Windowsには仮想マシンゲスト(Windows)を選択します。
  4. 指標を選択し、集計します。

最近の Perf レコードから現在の計算リソースIDを見つけることができます:

Perf
| where TimeGenerated > ago(30m)
| summarize arg_max(TimeGenerated, _ResourceId) by Computer

Note

プールがノード数がゼロになると、バッチはバックアップ仮想マシンのスケールセットを削除できます。 スケールセットが存在しない間、ゲストメトリックリソースは利用できません。 ワークスペースで既に収集されたLog Analyticsデータは、ワークスペースの保持設定に従って引き続き利用可能です。

ノードデータでバッチプラットフォームの指標を監視する

ノードゲストデータは、自動で収集されたバッチアカウントプラットフォームの指標を補完します。 両方の情報源を活用してください:

  • TotalNodeCount、RunningNodeCount、IdleNodeCount、UnusableNodeCount、TaskStartEvent、TaskCompleteEventなどのバッチアカウント指標を使って、サービスやスケジューリングの状態を監視します。
  • ゲストパフォーマンスカウンターを使って、CPU、メモリ、ディスク、ネットワークのコンピュートノードの状態を調査します。
  • バッチサービスログを使って、プール、ジョブ、タスクのライフサイクルイベントとノードの挙動を関連付けます。

メトリクスの定義や集約のガイダンスについては、Azure Batch monitoring data reference および Monitor Azure Batch をご覧ください。

データ収集の問題解決

データが届かない場合は以下のチェックをしてください:

症状: チェック
ハートビートなし AMA拡張機能が正常にプロビジョニングされていること、ユーザー割り当てIDがプールに紐づけられ拡張機能設定で参照されていること、必要なAzure Monitorエンドポイントに到達可能であることを確認してください。
AMAによると、そのリソースはDCRとは関連していません DCRアソシエーションがバッチプールリソースIDを対象としているか確認してください。 基盤となる仮想マシン スケール セットに対する関連付けだけでは、プールの関連付けの代わりにはなりません。
ハートビートは届いていますが、Perf は空です パフォーマンスカウンターのデータソースとLog Analyticsを対象としたデータフローの両方に、Microsoft-Perfが存在することを確認します。 カウンターパスとDCRオペレーティングシステムの種類を確認してください。
ゲストメトリックネームスペースは利用できません Microsoft-InsightsMetricsターゲットがazureMonitorMetrics-defaultしていることを確認し、集約に数分の時間を設け、プールに現在ノードとバックアップスケールセットがあることを確認しましょう。
重複するレコード プールから同じデータを収集する複数のDCRがないか確認してください。 重複収集は摂取コストを増加させます。

AMAのログ位置情報やディスク要件については、Azure Monitor Agent requirementsを参照してください。 バッチ割り当ておよびノードの失敗については、Azure Batch poolおよびnode errorsを参照してください。

コストに関する考慮事項

Azure Monitorの料金は、Log Analyticsの取り込み、保持、アラート、その他有効化された機能に適用されることがあります。 コスト管理:

  • モニタリング目標に必要なカウンターとログのみを集めてください。
  • 作業量に合ったサンプリング頻度を使いましょう。
  • クエリやアラートで意味のあるマウントポイントインスタンスでディスクデータをフィルタリングします。
  • 同じプールに重複するDCRを関連付けるのは避けてください。
  • ワークスペースの保持設定を確認します。

詳細については、Azure Monitor のコストと使用状況およびAzure Batch のコストを管理するための計画をご覧ください。

リソースをクリーンアップする

監視対象プールが不要になったら、プールと他のワークロードと共有されていない監視リソースを削除してください。

計算ノードを継続せずにプール構成を維持するには、プールをゼロにリサイズします:

az batch account login \
  --resource-group "$resourceGroup" \
  --name "$batchAccount"

az batch pool resize \
  --pool-id "$poolName" \
  --target-dedicated-nodes 0 \
  --target-low-priority-nodes 0

ゼロにスケーリングすると、バックアップとなる仮想マシンのスケールセットを削除できます。 すでにLog Analyticsに保存されているデータは、ワークスペースの保持設定に従って引き続き利用可能です。

関連するコンテンツ

  • Last updated on