Azure Monitorのメトリクスとアラート設定|Linux VMのCPU・ディスク監視と通知ルールの実践

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Azure > Azure Monitorのメトリクスとアラート設定|Linux VMのCPU・ディスク監視と通知ルールの実践
「Azure上のLinux VMをデプロイしたはいいが、CPUが急騰しても誰も気づかない」「アラートを設定したいが、メトリクスとLog Analyticsのどちらを使えばいいか判断できない」

Azureでの運用監視を始めようとすると、こうした壁にぶつかります。Azure Monitorはメトリクス収集・アラートルール・通知(Action Group)という3つの仕組みを組み合わせて、インフラの異常を自動検知する監視基盤です。エージェント不要のプラットフォームメトリクスを使えば、VMをデプロイした瞬間からCPUやネットワークの監視を開始できます。

この記事では、azure monitor アラートの設定を軸に、Linux VM(Ubuntu 24.04 LTS)のCPU使用率とディスクI/OをAzure Monitorのメトリクスで収集し、Action Groupを使った通知ルールをAzure PortalとAzure CLI(az monitorコマンド)の両方で構築する実践手順を解説します。RHEL 9.4での実機出力も交えて、設定から動作確認まで一気にカバーします。

この記事のポイント

・azure monitor アラートはAction Group+アラートルールの2段構成で設定する
・CPU使用率(Percentage CPU)はエージェント不要のプラットフォームメトリクスで監視できる
・az monitor metrics alert createでCLIからアラートルールを一括作成できる
・Log Analytics(KQL)はログ収集用、メトリクスアラートはリアルタイム閾値監視用と役割が異なる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

メトリクスアラートとLog Analytics(KQL)の棲み分け

Azure Monitorは「メトリクス」と「ログ(Log Analytics)」の2つの監視軸を持っています。この記事で扱うメトリクスアラートは、1分間隔の数値データ(CPU使用率・ディスクI/O等)を監視し、閾値を超えたら即座に通知するリアルタイム監視に特化しています。

一方、Log Analytics(KQL)はOS内部のsyslogやapplicationログを収集・検索するためのログ分析基盤です。複雑なログ相関分析や履歴の長期保存が必要な場合はLog Analyticsを使います。

種別 用途 エージェント クエリ言語
メトリクス(本記事) CPU・ネットワーク・ディスクI/Oのリアルタイム監視・閾値アラート 不要(プラットフォームメトリクス) GUI / az monitor
Log Analytics(KQL) syslog・アプリログの収集・検索・長期保存 Azure Monitor Agent(AMA)必要 KQL(Kusto Query Language)
本記事はメトリクスアラートに絞って解説します。ログ収集(KQL)の手順はLog Analytics記事を参照してください。

Azure Monitorの構成要素——メトリクス・アラートルール・Action Groupの関係

azure monitor アラートの仕組みを理解するには、3つの構成要素の関係を把握することが先決です。

メトリクス(Metrics):VMやディスクから自動収集される時系列の数値データ。CPU使用率(Percentage CPU)、ディスク書き込みバイト(Disk Write Bytes)などが含まれます。エージェント不要でAzureが自動収集します。
アラートルール(Alert Rule):「特定のメトリクスが閾値を超えたら発火する」というルール定義。評価期間(5分・15分など)と評価頻度(1分・5分)を指定します。
Action Group:アラートが発火したときの「通知先」を定義するリソース。メール・SMS・Azure FunctionのWebhook・Logic Appsなどを登録できます。

設定の流れは「Action Groupを作成する → アラートルールを作成してAction Groupを紐づける」の2ステップです。

Azure Portalでメトリクスグラフを確認する

コマンドに入る前に、Azure Portalでメトリクスの生データを目視確認する手順を押さえます。

1. VMのメトリクスページを開く

Azure Portal(portal.azure.com)にサインインし、「仮想マシン」→ 監視対象のVMを選択 → 左メニューの「メトリクス」をクリックします。メトリクスの選択画面が開いたら、以下のように設定します。

スコープ:対象VMのリソースID(自動で選択されています)
メトリクス名前空間:Virtual Machine Host
メトリクス:Percentage CPU
集計:平均

「グラフの追加」で複数メトリクスを同一画面に並べられます。CPU・ネットワーク・ディスクを並べて傾向を把握するのが実務の基本です。

2. ディスクI/Oのメトリクスを確認する

ディスクのI/O監視には以下のメトリクスが使えます。

Disk Write Bytes:1秒あたりのディスク書き込みバイト数(書き込み負荷の把握)
Disk Read Bytes:1秒あたりのディスク読み込みバイト数
OS Disk IOPS Consumed Percentage:OSディスクのIOPS消費率(100%に近いとIOPS枯渇のリスク)
Data Disk IOPS Consumed Percentage:データディスクのIOPS消費率

「ディスク使用率(空き容量%)」はプラットフォームメトリクスには含まれません。ディスク空き容量を監視する場合は、Azure Monitor AgentをVMにインストールしてパフォーマンスカウンターを有効にする必要があります(Log Analytics連携)。

3. メトリクスからアラートルールを直接作成する

メトリクスグラフを表示した状態で「新しいアラートルール」ボタンをクリックすると、現在表示しているメトリクスをベースにアラートルールを作成できます。Portal操作の場合はこの方法が最も直感的です。

az monitorコマンドでアラートルールを作成する(Azure CLI)

複数のVMや環境を管理する場合はAzure CLIを使った自動化が効率的です。ここからはaz monitorコマンドによる設定手順を解説します。

4. 事前準備——変数の定義とVM IDの取得

# 変数定義(環境に合わせて変更する) RESOURCE_GROUP="my-monitor-rg" VM_NAME="mylinuxvm" LOCATION="japaneast" # VM のリソースIDを取得(アラートルールのスコープとして使用) VM_ID=$(az vm show --resource-group $RESOURCE_GROUP --name $VM_NAME --query id --output tsv) echo "VM ID: $VM_ID"

実行結果(RHEL 9.4 / Standard_B2s):

VM ID: /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-monitor-rg/providers/Microsoft.Compute/virtualMachines/mylinuxvm

サブスクリプションIDが正しく取得できていれば準備完了です。

5. Action Groupを作成する(通知先の登録)

Action Groupはアラートが発火したときの通知先を束ねるリソースです。まずこちらを作成しておき、後でアラートルールから参照します。

# Action Group の作成(メール通知の例) az monitor action-group create --name "vm-ops-alert" --resource-group $RESOURCE_GROUP --short-name "vmopsalert" --action email ops-admin admin@example.com # Action Group のリソースIDを取得 ACTION_GROUP_ID=$(az monitor action-group show --name "vm-ops-alert" --resource-group $RESOURCE_GROUP --query id --output tsv) echo "Action Group ID: $ACTION_GROUP_ID"

実行結果:

Action Group ID: /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-monitor-rg/providers/microsoft.insights/actionGroups/vm-ops-alert

`--action email` の後は「アクション名」「表示名」「メールアドレス」の順に指定します。複数の通知先を追加する場合は `--action email` をスペース区切りで列挙できます。

6. CPU使用率のアラートルールを作成する

「CPU使用率が80%を5分以上超えたらメール通知する」アラートルールを作成します。

# CPU使用率アラートルールの作成 az monitor metrics alert create --name "cpu-high-alert" --resource-group $RESOURCE_GROUP --scopes $VM_ID --condition "avg Percentage CPU > 80" --window-size 5m --evaluation-frequency 1m --action $ACTION_GROUP_ID --severity 2 --description "CPU使用率が80%超過(5分平均)で通知"

主なオプションの意味を整理します。

--condition:「avg Percentage CPU > 80」の形式でメトリクス名・集計方法・閾値を指定します。集計方法はavg(平均)、max(最大)、total、min、countから選べます。
--window-size:評価期間。5mは「直近5分間の平均を評価する」という意味です。1m・5m・15m・30m・1h・6h・1dが指定可能です。
--evaluation-frequency:評価を実行する間隔。1mは「1分ごとに評価する」という意味です。window-sizeと同じか小さい値を指定します。
--severity:重要度(0=クリティカル、1=エラー、2=警告、3=情報、4=詳細)。CPU 80%超は警告(2)が適切です。

7. ディスクI/Oのアラートルールを作成する

OSディスクのIOPS消費率が90%を超えた場合に通知するアラートを作成します。IOPS枯渇はLinux VMのパフォーマンス劣化の典型的な原因です。

# OSディスク IOPS消費率アラートの作成 az monitor metrics alert create --name "disk-iops-alert" --resource-group $RESOURCE_GROUP --scopes $VM_ID --condition "avg OS Disk IOPS Consumed Percentage > 90" --window-size 5m --evaluation-frequency 1m --action $ACTION_GROUP_ID --severity 1 --description "OSディスクIOPS消費率90%超過(5分平均)で通知"

メトリクス名にスペースが含まれる場合(OS Disk IOPS Consumed Percentage など)は、そのままスペースを含めて指定します。引用符で囲む必要はありません。

8. アラートルールの一覧確認

作成したアラートルールを確認します。

# リソースグループ内のメトリクスアラート一覧 az monitor metrics alert list --resource-group $RESOURCE_GROUP --output table

実行結果:

Name ResourceGroup Severity Enabled Description ----------------- -------------- -------- ------- ------------------------------------------ cpu-high-alert my-monitor-rg 2 True CPU使用率が80%超過(5分平均)で通知 disk-iops-alert my-monitor-rg 1 True OSディスクIOPS消費率90%超過(5分平均)で通知

Enabled列がTrueになっていればアラートルールは即座に有効です。

Azure運用の基礎をしっかり固めたい方は、現役エンジニアが指導するセミナーもご活用ください。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Azure対応セミナーの詳細を見る >>

メトリクスの確認コマンド——az monitor metrics list

アラートのテストや過去データの確認には `az monitor metrics list` を使います。

# 直近1時間のCPU使用率を1分間隔で取得 az monitor metrics list --resource $VM_ID --metric "Percentage CPU" --interval PT1M --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) --output table

実行結果(Ubuntu 24.04 LTS 実機):

Timestamp Average --------------------------- --------- 2026-07-16 02:00:00+00:00 1.245 2026-07-16 02:01:00+00:00 1.132 2026-07-16 02:02:00+00:00 3.812 2026-07-16 02:03:00+00:00 2.674 2026-07-16 02:04:00+00:00 1.053

`--interval` にはISO 8601の期間形式(PT1M=1分、PT5M=5分、PT1H=1時間)を使います。

実務Tips——本番で使えるアラート設計のポイント

設定方法を学んだあとは、運用で実際に機能するアラート設計のポイントを押さえてください。現場でよく見かける失敗パターンを交えて解説します。

アラート疲れ(Alert Fatigue)を防ぐ閾値設定

CPU使用率のアラートを「50%超えたら通知」に設定すると、アラートが頻発して担当者が無視するようになります(アラート疲れ)。実務での推奨は以下のとおりです。

警告レベル(Severity 2):CPU 80%超が5分継続 → 対応を検討する水準
クリティカル(Severity 1):CPU 90%超が5分継続 → 即座に対応が必要な水準
評価期間(window-size):瞬間的なスパイクで誤検知しないよう5分~15分を推奨

また、バッチ処理やスケジュールジョブが定期的にCPUを高騰させるVMには「アラートの抑制ルール(アクションルール)」を設定して、処理時間帯の通知を抑止するとノイズが減ります。

ディスク空き容量を監視するにはAMAが必要

前述のとおり、ディスク使用率(%)はプラットフォームメトリクスには含まれません。本番VMでディスク空き容量を監視するには以下の手順が必要です。

Azure Monitor Agent(AMA)をVMにインストール:`az vm extension set --publisher Microsoft.Azure.Monitor --name AzureMonitorLinuxAgent`
データ収集ルール(DCR)でパフォーマンスカウンターを設定:Logical Disk % Free Spaceを収集対象に追加
Log Analyticsワークスペースにデータを送信:KQLでクエリまたはアラートルールを作成

この場合はLog Analytics連携となるため、本記事のメトリクスアラートの範囲を超えます。ディスク空き容量監視の詳細はLog Analytics記事(Azure Monitor AgentとKQLの実践手順)を参照してください。

アラートルールの有効・無効を環境別に制御する

開発環境では夜間のアラートは不要なケースが多いです。`az monitor metrics alert update` で有効・無効を切り替えられます。

# アラートルールを無効化する(開発環境の夜間停止など) az monitor metrics alert update --name "cpu-high-alert" --resource-group $RESOURCE_GROUP --enabled false # アラートルールを再有効化する az monitor metrics alert update --name "cpu-high-alert" --resource-group $RESOURCE_GROUP --enabled true

トラブルシュート——アラートが発火しない・通知が届かない場合

設定したはずのアラートが動かない場合は、以下の順に確認してください。

「アラートが発火しない」場合の確認手順

メトリクスのデータが存在するか確認:`az monitor metrics list` でデータが返ってくるかを確認します。データが空の場合はVMが停止中か、スコープ(VM ID)が間違っています。
評価期間と頻度の設定を確認:window-sizeとevaluation-frequencyの組み合わせが正しいか確認します。window-sizeよりevaluation-frequencyが大きい値になっていると設定エラーです。
アラートルールが有効になっているか確認:`az monitor metrics alert show` でEnabled=trueかを確認します。
条件式のメトリクス名が正しいか確認:`az monitor metrics list-definitions --resource $VM_ID` で使用可能なメトリクス名の一覧を確認します。

# 使用可能なメトリクス名の一覧表示 az monitor metrics list-definitions --resource $VM_ID --query "[].name.value" --output table

「通知メールが届かない」場合の確認手順

Action Groupのメールアドレスを確認:`az monitor action-group show --name "vm-ops-alert" --resource-group $RESOURCE_GROUP` でemailActionsのaddressを確認します。
Azure PortalでアラートのFired履歴を確認:Azure Portal → Monitor → アラート → 「アラート履歴」でFired(発火済み)の記録があるかを確認します。記録があれば発火はしているが通知が届いていない状態で、Action Group側の問題です。
迷惑メールフォルダを確認:Azure Monitorのメール通知(azure-noreply@microsoft.com)が迷惑メールに振り分けられているケースがあります。
Action Groupのテスト通知を実行:Azure Portal → Monitor → Action Groups → 対象グループ → 「テスト」ボタンで疎通確認できます。

まとめ

azure monitor アラートの設定手順を整理します。

やること コマンド / 操作
VM IDを取得する az vm show --query id --output tsv
Action Groupを作成する az monitor action-group create --action email
CPUアラートルールを作成する az monitor metrics alert create --condition "avg Percentage CPU > 80"
ディスクIOPSアラートを作成する az monitor metrics alert create --condition "avg OS Disk IOPS Consumed Percentage > 90"
メトリクスの過去データを取得する az monitor metrics list --metric "Percentage CPU" --interval PT1M
アラートルールを有効・無効にする az monitor metrics alert update --enabled false/true
Azure Monitorのメトリクスアラートは「Action Groupで通知先を定義 → アラートルールで閾値を設定」の2ステップで構成されます。エージェント不要のプラットフォームメトリクス(CPU使用率・ディスクIOPS)はVMのデプロイ直後から監視を開始できるため、まずここから始めるのが実務での定石です。ディスク使用率(空き容量%)が必要になった段階でAzure Monitor AgentとLog Analyticsに拡張していくのが自然な運用監視の構成です。

次に読む記事
Linuxのポート確認コマンド(ss・lsof)の使い方
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Azure対応セミナーの詳細を見る >>

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。