連載

2023年9月13日

【Azure】大量のメトリックアラートを一発で作る方法（リソーステンプレート編）：Tech TIPS

Azureの仮想マシンなどには、CPU使用率やメモリ空き容量といった「メトリック（測定値）」をほぼリアルタイムで確認できる機能がある。このメトリックの値が上限／下限を超えたときに「メトリックアラート」として警告するように設定することで、不具合や障害に素早く気付き、速やかに対処しやすくなる。しかしGUIで作るには手間がかかりすぎることも。リソーステンプレートからのデプロイによって効率よく大量生成できる方法を紹介する。

[島田広道，デジタルアドバンテージ] PC用表示関連情報

LINE

Hatena

連載目次

対象：Azure Virtual Machine（仮想マシン）などのリソース、Bicep

AzureのメトリックアラートをいちいちPortalで作るのが面倒くさい！

　Azure上のリソースには、それが消費しているCPUやメモリ、ディスク、ネットワークなどの状態を常時監視／測定する機能「メトリック」が備わっている。その測定値が指定のしきい値を超えたときに警告する機能を「メトリックアラート」と呼ぶ。

　例えば、CPU使用率が90％を超えたり、利用可能なメモリ容量が10％を切ったり、といった条件が満たされたら、即座に警告をメールやSMSなどで通知するように設定できる（こうした一連の設定をまとめたものを「アラートルール」と呼ぶ）。適切に設定しておくと、予期せぬトラブルが生じたときに警告の通知を受け取ることで、速やかに対処しやすくなる。

　メトリックアラートはAzure PortalからGUIで手軽に生成できるため、一度は作ったことがあるという人も多いのではないだろうか。

　ただ、複数のメトリックアラートを作らなければならない場合、GUIだとかなりの手間が掛かる。また、複数のリソースに対して、似たようなメトリックアラートを複数生成するような場合、GUIで間違えることなく正確にパラメーターの指定を繰り返すのは非常に面倒で困難な作業だ。

　そのような場合は、コマンドラインで一括生成した方がはるかに効率的だ。本Tech TIPSでは、Azureのリソーステンプレートを使って複数のメトリックアラートを1回のデプロイで生成する基本的な手順について説明する。リソーステンプレートの記述にはBicepを利用する。説明を単純化するため、アラートルールのしきい値は静的（Static）のみとし、アラートルールごとの条件は1種類だけに限定する。

　メトリックアラート自体の詳細については都度説明しないので、Microsoft Learnの「Azure Monitor の警告とは」から始まるセクションを参照していただきたい。

■執筆時の各種ツール／APIのバージョン

Azure CLI： Ver. 2.52.0
Bicep CLI： Ver. 0.21.1
Bicepでのデプロイ時のAPIバージョン： 2023-01-01（アクショングループ）、2018-03-01（メトリックアラート）

通知先を設定する「アクショングループ」を作成する

　まずは「アクショングループ」を作成する。メトリックアラートの警告の具体的な通知先は、このアクショングループで設定する必要があるからだ。

　アクショングループでは、通知先として電子メールやSMS、スマートフォン向けに提供されている「Microsoft Azure」アプリのプッシュ通知の他、Azureの各種リソースも指定できる。ここでは電子メールとSMS、Azureアプリのプッシュ通知を例に挙げる。

param location string = 'Global' // 特別な理由がない限り「Global」とする
param actionGroupName string // アクショングループの名前
param actionGroupShortName string // Azure Portalでは「表示名」。SMSのメッセージ冒頭に挿入される

// 電子メールで通知
param emailReceivers array = [
{
    name: 'emailToMyCorpAddr' // このメール通知に付ける名称。他の名称との重複は不可
    emailAddress: 'hiromichi@example.jp' // 通知先のメールアドレス
    useCommonAlertSchema: false
}
]

// スマートフォン向けの「Microsoft Azure」アプリにプッシュ通知
param azureAppPushReceivers array = [
{
    name: 'azureAppToMyCorpAccount' // このアプリ通知に付ける名称
    emailAddress: 'hiromichi@example.jp' // アプリにひも付けているAzureアカウント名
}
]

// SMSで通知
param smsReceivers array = [
{
    name: 'smsToMyPrivateNumber' // このSMS通知に付ける名前
    countryCode: '81' // SMS宛先の国別コード。日本なら「81」
    phoneNumber: '09000000000' // SMS宛先の携帯電話番号
}
]

// リソース生成：アクショングループ（警告などの通知設定）
resource actionGroup 'Microsoft.insights/actionGroups@2023-01-01' = {
name: actionGroupName
location: location
properties: {
    groupShortName: actionGroupShortName
    enabled: true
    emailReceivers: emailReceivers
    smsReceivers: smsReceivers
    azureAppPushReceivers: azureAppPushReceivers
    voiceReceivers: [] // 音声通話による通知。日本（国別コード「81」）は未対応
    armRoleReceivers: [] // 「所有者」などのロール所属ユーザーにメールで通知
    webhookReceivers: [] // WebHookに伝達
    automationRunbookReceivers: [] // Azure AutomationのRunbookに伝達
    azureFunctionReceivers: [] // Azure Functionsに伝達
    eventHubReceivers: [] // Azure Event Hubsに伝達
    logicAppReceivers: [] // Azure Logic Appsに伝達
    itsmReceivers: [] // Log AnalyticsのITSM Connectorに伝達
}
}

【Bicep】通知先を設定する「アクショングループ」を生成する
※Microsoftのレファレンス： Microsoft.Insights actionGroups

　このリストで幾つか注意すべき点を以下で説明しよう。触れていない詳細については、Microsoft Learnの「アクショングループ」を参照していただきたい。

●アクショングループを配置するリージョンは原則「Global」

　まず、アクショングループを配置するリージョンは、特別な理由がない限り「Global」となるだろう。この場合、2つ以上のリージョンをまたいだ冗長構成が自動的に作成される。

　特定リージョンへの配置も可能なものの、執筆時点では日本リージョンには配置できないようだ。またリージョン間の冗長はなく、ゾーン冗長に限られる。

●メトリックアラートに合わせて通知先をグルーピングする

　リソース定義の「properties.＜通知先＞Receivers」キーの値は配列であり、複数の通知先を指定できる。例えば同時に通知したいメールアドレスが複数あるなら、「properties.emailReceivers」キーの値には、その分のメールアドレスを列挙する必要がある。

　その一方で、メトリックアラートの通知先は、アクショングループ単位で指定する点に注意したい。例えば、緊急のアラートは運用グループ用メールアドレス宛てにメールで知らせる一方で、そうでない通知は個人のメールだけにする場合は、メールアドレスごとに別々のアクショングループを用意して、各アラートへ別々に割り当てられるようにする必要がある。

●SMSを利用するなら「actionGroupShortName」に注意

　パラメーター「actionGroupShortName」は、Azure Portalだと「表示名」に該当する短縮名で、以下のようにSMSで届くメッセージの冒頭に挿入される

アラート発生時： ＜actionGroupShortName＞:Fired:……
アラート解消時： ＜actionGroupShortName＞:Resolved:……

　そのため、長い名称にすると、スマートウォッチのようにディスプレイが小さい端末でSMSを受信したとき、後続の文字列が省略されてアラートの実体が確認できないことがあるので注意しよう。

●音声通話による通知は実質的に使えない!?

　アクショングループは、音声通話で通知する機能も備えている（リソース定義の「properties.voiceReceivers」キー）。ただし、執筆時点で「countryCode」キーすなわち国別コードに日本の「81」は指定できなかった。つまり、一般的な日本の電話番号には発信できないようだ。

「メトリックアラート」を作成する

　ここからメトリックアラート自体の生成について説明する。

●メトリックアラートのパラメーターを配列にまとめる

　まずは、メトリックアラートの種類や監視の間隔、しきい値などのパラメーターのセットをオブジェクトにまとめつつ、複数のそれを配列にまとめていく（以下のリストの変数「metricAlertParams」）。

param location string = resourceGroup().location
param vmName string // 仮想マシンの名前
param vmDesc string = '2023/09/13のfwin2k TIPS向け仮想マシン' // メトリックアラートの説明文に挿入

param actionGroupRG string // アクショングループ名
param actionGroupName string // アクショングループのリソースグループ名

param maxCPUUsage int = 80 // CPU使用率（％）の上限値
param minMemory int = 700000000 // 利用可能なメモリ容量（bytes）の下限値
var minMemoryMB = minMemory / 1000 / 1000 // 説明文に挿入

// メトリックアラートの各種パラメーター。コメントの［］内はAzure Portalでの名称
var metricAlertParams = [
{
    // CPU使用率
    name: 'CPU usage is increasing on ${vmName}' // ［アラートルール名］
    description: '${vmDesc}（${location}）でCPU使用率が ${maxCPUUsage}％を超えました。${vmName}です。' // ［アラートルールの説明］
    severity: 2 // ［重大度］。0：重大、1：エラー、2：警告、3：情報、4：詳細
    evaluationFrequency: 'PT1M' // ［確認する間隔］。アラートの条件を満たしているか確認する頻度
    windowSize: 'PT5M' // ［ルックバック期間］。アラートの条件を満たしているか振り返って監視する期間
    metricTitle: 'metric_ave_cpu_usage_gt_${maxCPUUsage}_in_5m' // アラートルールに付けるタイトル
    threshold: maxCPUUsage // ［しきい値］
    metricName: 'Percentage CPU' // ［シグナル名］。事象あるいは測定項目を表す名称
    operator: 'GreaterThan' // ［演算子］。「GreaterThan」は［次の値より大きい］
    timeAggregation: 'Average' // ［集計の頻度］。「Average」「Count」「Maximum」「Minimum」「Total」
}
{
    // 利用可能なメモリ容量
    name: 'Memory Available Bytes is decreasing on ${vmName}'
    description: '${vmDesc}（${location}）で利用可能なメモリ容量が ${minMemoryMB}MB を切りました。${vmName}です。'
    severity: 2
    evaluationFrequency: 'PT5M'
    windowSize: 'PT5M'
    metricTitle: 'metric_ave_memory_available_bytes_lt_${minMemoryMB}MB_in_5m'
    threshold: minMemory
    metricName: 'Available Memory Bytes'
    operator: 'LessThan' // ［次の値より小さい］
    timeAggregation: 'Average'
}
]

【Bicep】「メトリックアラート」生成のためのパラメーターや変数の宣言／定義
※Microsoftのレファレンス： Microsoft.Insights metricAlerts

　メトリックアラートは1つのリソースに対して複数設定することが多いため、1つずつ別々に生成部分を定義するとテンプレートが冗長になる。それよりは、上記のようにパラメーターのセットを配列にまとめつつ、for文で配列の要素ごとに生成を繰り返す方が効率的だ（実際のfor文については後述）。

　メトリックそのものの選択は「metricName」で決定される。これは次のMicrosoft Learnの「 Monitor のサポートされるメトリック」にまとまっている。

　「evaluationFrequency」と「windowSize」の違いは、前者が測定の「間隔」なのに対して後者は測定の「期間」というものだ。例えば「evaluationFrequency」が1分間で「windowSize」が5分間だと以下のようになる。

測定そのものは1分ごとに実行され、1分ごとに測定値は変わる
測定の際には、5分前から現時刻までの間、アラートの条件がずっと満たされていたかどうかが判定される。

　その「evaluationFrequency」「windowSize」に指定する時間は、次のように表記する必要がある

分単位：「PT＜分＞M」。例：「PT1M（1分間）」「PT5M（5分）」「PT15M（15分）」「PT30M（30分）」
時単位：「PT＜時＞H」。例：「PT1H（1時間）」「PT6H（6時間）」「PT12H（12時間）」「PT24H（24時間）」

●アクショングループが作成済みなら既存リソースとして定義

　アクショングループは複数のメトリックアラートや通知を必要とする他のリソースの間で共有されることが多い。共有せずに対象リソースごとに生成していると、通知先のメールアドレスなどが変わったときに変更の手間が増えるからだ。

　ここでは、前述の手順でアクショングループを別のリソースグループに作成済みという前提で、既存リソースとして定義している。

param actionGroupName string // アクショングループ名
param actionGroupRG string // アクショングループのリソースグループ名

// 既存リソース：アクショングループ
resource actionGroup 'Microsoft.Insights/actionGroups@2023-01-01' existing = {
name: actionGroupName
scope: resourceGroup(actionGroupRG) // 他のリソースとスコープ（リソースグループ）が異なる場合はこのように記述
}

【Bicep】作成済みの「アクショングループ」の定義

　リソースグループが他のリソース（ここでは仮想マシンなど）と異なる場合は、上記のように「scope」でリソースグループ名を明記する必要がある。

●複数のメトリックアラートをfor文で繰り返し生成する

　メトリックアラートを実際に生成する以下の「resource metricAlert ……」のセクションでは、前述のパラメーターの配列とfor文を用いることで、単一のセクションで複数のメトリックアラートを生成している。

// リソース生成：仮想マシン
resource vm 'Microsoft.Compute/virtualMachines@2023-03-01' = {
name: vmName
location: location
properties: { /* …… 省略 …… */ }
}

// リソース生成：メトリックアラート
// metricAlertParamsの要素1つずつにメトリックアラートを生成
resource metricAlert 'Microsoft.insights/metricalerts@2018-03-01' = [for ma in metricAlertParams: {
name: ma.name
location: 'global' // 特定リージョンを指定できない
properties: {
    description: ma.description
    severity: ma.severity
    enabled: true
    scopes: [ vm.id ] // 測定対象のリソースIDを指定
    evaluationFrequency: ma.evaluationFrequency
    windowSize: ma.windowSize
    criteria: {
      allOf: [
        {
          threshold: ma.threshold
          name: ma.metricTitle
          metricNamespace: vm.type // 測定対象のリソースタイプを指定
          metricName: ma.metricName
          operator: ma.operator
          timeAggregation: ma.timeAggregation
          criterionType: 'StaticThresholdCriterion'
        }
      ]
      'odata.type': 'Microsoft.Azure.Monitor.MultipleResourceMultipleMetricCriteria'
    }
    autoMitigate: true
    targetResourceType: vm.type // 測定対象のリソースタイプを指定
    actions: [
      {
        actionGroupId: actionGroup.id // 通知に用いるアクショングループのリソースIDを指定
      }
    ]
}
}]

【Bicep】「メトリックアラート」の生成
仮想マシンの生成については、行数を押させるために仮想ネットワークやディスク、ネットワークなどに冠する記述を省いている。必要に応じて追加／変更してほしい。
※Microsoftのレファレンス： Microsoft.Insights metricAlerts

　具体的には「for ma in metricAlertParams: { …… }」とすることで、配列「metricAlertParams」内の各要素（オブジェクト）を順番に変数「ma」に代入しつつ、｛｝内のリソース生成を繰り返している。例えば、繰り返し（ループ）の初回には、「ma」にCPU使用率に関する設定が代入され、2回目には利用可能なメモリ容量に関する設定が代入される。それらの設定の名前は「ma.name」で、メトリックのシグナル名は「ma.metricName」でそれぞれ参照できる。

●特定の値を代入しているキーについて

　上記リストでは、基本的には前述したパラメーターの配列の要素をそのまま1対1で各キーの値に代入している。

　ただ例外もあって、「properties.criteria.allOf」キー内の配列要素内にある「criterionType」は通常「StaticThresholdCriterion」を指定する。同様に「properties.criteria」の「odata.type」キーも、「Microsoft.Azure.Monitor.MultipleResourceMultipleMetricCriteria」を指定する。

　他のリソースとの連携が必要なキーは、以下のように指定する。

「properties.scopes」の配列：測定対象のリソース（ここでは「vm」）のリソースID
「properties.actions」の配列要素内の「actionGroupID」：アクショングループの既存リソース（ここでは「actionGroup」）のリソースID
「properties.criteria.allOf」キー内の配列要素内にある「metricNamespace」：測定対象のリソース（「vm」）のリソースタイプ
「properties.targetResourceType」：測定対象のリソース（「vm」）のリソースタイプ

■関連リンク

アクショングループの概要（Microsoft Learn）
Azure Monitor の警告とは（Microsoft Learn）
Azure Monitor のメトリックアラートでサポートされるリソース（Microsoft Learn）
Monitor メトリックの概要（Microsoft Learn）
Azure CLI で Azure Resource Manager (ARM) のデプロイテンプレートを使用する方法（Microsoft Learn）

「Tech TIPS」