Azure Monitor入門｜ログ収集・メトリクス・アラート設定をゼロから学ぶ実践ガイド

オンプレミス環境で、NagiosやZabbixを設定してサーバーの死活監視を組んできた経験のあるエンジニアは多いと思います。監視エージェントのインストールから、チェックスクリプトの記述、アラートメールの設定まで、すべてを手作業でこなしてきたはずです。

Azure移行を検討したとき、真っ先に頭に浮かぶのが「監視はどうなるんだ」という疑問ではないでしょうか。オンプレで使ってきた監視ツールがそのまま使えないなら、代替の監視基盤を一から構築しなければならないのか、と不安になる方もいるかもしれません。

この記事では、Azureの統合監視サービスであるAzure Monitorについて、オンプレ経験者の視点から解説します。メトリクスの収集・確認方法、Log Analyticsを使ったログ集約と分析、アラートルールの設計と運用まで、実務でそのまま使えるレベルで説明します。

なぜAzure Monitorが必要なのか？オンプレ監視との根本的な違い

オンプレ環境での監視を振り返ると、監視サーバー自体の構築・維持が大きな工数になっていたはずです。Nagiosを例に挙げると、監視設定ファイルを手書きして、監視対象が増えるたびに設定を追加して、エージェントのバージョン管理も自分でやって……という作業が延々と続きます。規模が大きくなるほど、監視基盤の運用だけで担当者の時間が食われていきます。

Azureでは、リソースを作成した瞬間からプラットフォームメトリクスが自動で収集されます。Azure Virtual Machinesを立てれば、CPUやネットワーク帯域のメトリクスが追加設定なしで記録される仕組みです。監視の「足場作り」にかかる時間が劇的に短縮されています。

ただし、Azureの監視がすべてゼロコンフィグかというとそうではありません。メモリ使用率や詳細なディスクI/OといったゲストOSのメトリクス、アプリケーションのエラーログやsyslogの収集には追加の設定が必要です。Azure Monitorはその設定の入口を統一したサービスと理解すると、全体像が掴みやすくなります。

Azure Monitorの全体像と主要コンポーネント

Azure Monitorは単体のサービスというより、複数の監視機能を統合したプラットフォームです。用途に応じて使うコンポーネントが変わります。

・メトリクス（Metrics）: CPUやメモリなどの数値データを時系列で収集します。短い間隔でリアルタイムに近い形で記録されるため、性能の瞬間的な変動を捉えるのに適しています。
・ログ（Log Analytics）: イベントログ、診断ログ、アプリケーションログなどテキスト形式のデータを集約します。KQL（Kusto Query Language）で検索・集計・可視化できます。
・アラート（Alerts）: メトリクスやログの条件に基づいて通知を発火するルール設定です。メール、SMS、Webhookなどの通知先を設定できます。
・Application Insights: Webアプリケーションのパフォーマンスと可用性を専門的に監視する機能です。リクエストの応答時間、例外発生数、依存関係の追跡などが可能です。
・Network Watcher: VNetのフロー分析、パケットキャプチャ、VPN接続の診断など、ネットワーク固有の監視機能を提供します。

この記事では、インフラエンジニアが最初に押さえるべきメトリクス・ログ・アラートの3つに絞って解説します。

メトリクスの収集と確認方法

1. 基本メトリクスをAzureポータルで確認する

Azureポータルにログインし、監視対象のリソース（例: Azure Virtual Machine）を開きます。左側のメニューから「監視」→「メトリクス」を選択すると、グラフビューが表示されます。

「メトリクス」のドロップダウンから確認したい指標を選びます。Azure VMで最初に確認すべき代表的なメトリクスは以下の通りです。

・Percentage CPU: CPU使用率（%）。高負荷の兆候を早期に察知するための基本指標です。
・Network In Total / Network Out Total: 受信・送信バイト数の累積値。トラフィック異常の検出や課金の見積もりに使います。
・OS Disk Read Bytes/sec / Write Bytes/sec: ディスクI/O速度。I/Oボトルネックの診断に活用します。
・Available Memory Bytes: 空きメモリ量。ただしこれはゲストOSメトリクスのため、後述のAzure Monitor Agentが必要です。

グラフの時間範囲は右上のメニューから1時間・24時間・7日などに変更できます。複数のメトリクスを同一グラフに重ねることも可能なので、CPUとネットワークを並べて相関を確認するといった使い方ができます。

2. ゲストOSメトリクスとAzure Monitor Agent

メモリ使用率やディスクの空き容量など、OSの内部データは「ゲストOSメトリクス」に分類されます。これらはAzureのハイパーバイザーから取得できないため、VM内部にエージェントを導入する必要があります。

現在推奨されているのはAzure Monitor Agent（AMA）です。以前使われていたLog Analytics Agent（旧称: MMA）は2024年8月に非推奨となっており、新規導入にはAMAを使います。

Azure CLIでのAMAインストール手順は以下の通りです。

# Azure CLIを使ってAzure Monitor Agent（Linux版）をインストールする
az vm extension set \
  --resource-group MyResourceGroup \
  --vm-name MyVM \
  --name AzureMonitorLinuxAgent \
  --publisher Microsoft.Azure.Monitor \
  --version 1.0 \
  --settings '{}'

# Windows VMの場合は --name を AzureMonitorWindowsAgent に変更する

Azureポータルからも導入できます。対象VMの「拡張機能 + アプリケーション」→「追加」から「Azure Monitor Agent」を選択してインストールします。

エージェントインストール後はデータ収集ルール（DCR）を作成して紐づける必要があります。DCRとは「どのデータをどこに送るか」を定義するオブジェクトで、AMAはDCRの設定がないとデータを収集しません。この「AMA ＋ DCR」の2点セットが、オンプレのエージェント設定との主な違いです。

Log Analyticsでログを集約・分析する

1. Log Analyticsワークスペースを作成する

Azureでログを集約・分析するには、まずLog Analyticsワークスペースを作成します。ワークスペースはログデータの保管場所で、複数のリソースのログをひとつにまとめて横断検索できます。オンプレでいうと、全サーバーのsyslogを集めた中央ログサーバーに相当するイメージです。

Azureポータルで「Log Analyticsワークスペース」を検索し、「作成」をクリックします。設定項目はシンプルで、サブスクリプション・リソースグループ・名前・リージョンを指定するだけです。日本のリソースを監視するなら、レイテンシを下げるために東日本リージョン（Japan East）での作成を推奨します。

2. データ収集ルール（DCR）でログ収集を設定する

Log Analyticsワークスペースを作成したら、次はAMAが収集するデータの種類と転送先を定義するDCRを設定します。Azureポータルで「Azure Monitor」→「データ収集ルール」→「作成」から設定できます。

DCR作成時の主な設定項目は以下の通りです。

・データソース: Linuxのsyslog（Severity別に選択可）、Windowsのイベントログ（Application/Security/System等）、パフォーマンスカウンターなどを選択します。
・送信先: 作成済みのLog Analyticsワークスペースを指定します。
・スコープ（リソース）: AMAを導入済みのVMを選択して紐づけます。

ポイントは、収集するsyslogのSeverityを適切に絞ることです。すべてのログ（Debug含む）を取り込むとデータ量が膨らみ、コストに直結します。まずはWarning以上に絞って運用し、必要に応じて範囲を広げる方針が現実的です。

3. KQLでログを検索・分析する

Log Analyticsに収集されたログは、KQL（Kusto Query Language）で検索・分析します。SQLに近い構文で、テーブルを指定してパイプでフィルタ条件をつなぐ書き方です。慣れれば強力なログ分析ができます。

基本的なKQLクエリの例を示します。

# 直近1時間のsyslogをタイムスタンプ降順で確認する
Syslog
| where TimeGenerated > ago(1h)
| order by TimeGenerated desc
| take 100

# Severityがerror以上のsyslogだけを抽出する
Syslog
| where SeverityLevel <= 3  # 0=emerg, 1=alert, 2=crit, 3=err
| project TimeGenerated, Computer, SeverityLevel, SyslogMessage
| order by TimeGenerated desc

# CPUが90%を超えたイベントを一覧する
Perf
| where ObjectName == "Processor"
    and CounterName == "% Processor Time"
    and CounterValue > 90
| project TimeGenerated, Computer, CounterValue
| order by TimeGenerated desc

オンプレ環境でgrepやawkでログを検索していた作業が、KQLではより体系的にできます。特に複数サーバーのログをひとつのクエリで横断検索できる点はAzure環境ならではの強みです。100台のVMのerrorログを同時に引き出すような作業が、ワークスペースひとつで完結します。

アラートルールの設計と運用

Azure Monitorのアラートには3種類があります。

・メトリクスアラート: CPU使用率が80%を超えたら通知、のようにメトリクスの閾値を条件として発火します。評価は1分間隔まで設定可能で、リアルタイムに近い検知ができます。
・ログアラート: KQLクエリの結果が条件を満たしたときに発火します。特定のエラーメッセージが検出されたら通知、といった用途に使います。最短5分間隔での評価となります。
・アクティビティログアラート: AzureリソースのCRUD操作（作成・更新・削除）やサービスの正常性イベントで発火します。「本番VMが誰かに削除された」という事態を検知するセキュリティ用途にも使えます。

アラートの通知先はアクショングループで管理します。メールアドレス、SMS、Azure App Push、Webhook、ITSM連携（ServiceNow等）などを設定でき、ひとつのアクショングループを複数のアラートルールで共有できます。

基本的なメトリクスアラートの設定手順です。

・1. Azureポータルで「Azure Monitor」→「アラート」→「アラートルールの作成」をクリック
・2. スコープで監視対象リソース（例: 特定のVM）を選択する
・3. 条件で「Percentage CPU」を選び、演算子「次の値より大きい」、閾値「80」、評価の粒度「5分」、評価の頻度「5分」に設定する
・4. アクションで通知先のアクショングループを選択（なければ新規作成）
・5. アラートルールの名前・重大度（0＝Critical ～ 4＝Verbose）を設定して「作成」

オンプレのNagiosではcheck_commandを手書きしてサービス定義ファイルを管理していたものが、GUIから数ステップで設定できます。インフラエンジニアとして最初は拍子抜けするかもしれませんが、リソースが数十台に増えたときに、この手軽さが運用効率の差になって現れます。

Azureポータルのダッシュボードで一元監視する

各リソース個別のメトリクス画面だけでなく、Azure MonitorにはWorkbooks（ワークブック）とダッシュボードという可視化機能もあります。

Workbooksは複数のメトリクスやクエリ結果を組み合わせたレポートを作成できる機能で、テンプレートも豊富に用意されています。「VM Insights」テンプレートを使うと、複数VMのCPU・メモリ・ディスク・ネットワークを一画面でまとめて確認できます。

Azureダッシュボードは、よく使うメトリクスグラフやアラート一覧をピン留めして、自分専用のオペレーションビューを作れる機能です。当番者が毎朝確認するための「監視ダッシュボード」として運用するのが典型的な使い方です。

オンプレのGrafanaダッシュボードを手作りしていた経験があれば、類似の使い方と考えると理解しやすいでしょう。AzureとGrafanaはネイティブ連携もサポートしているため、既存のGrafana環境をそのまま活かすことも可能です。

料金の仕組みとコスト最適化

Azure Monitorの料金は複数の要素で構成されています（2026年5月時点・東日本リージョン）。

・プラットフォームメトリクス: 無料。Azure VMのCPUやネットワークなど基本メトリクスの収集・保存はコストなしです。
・Log Analyticsデータ取り込み: 約$3.23/GB（従量課金制）。月5GBまでは無料枠があるため、小規模環境では無料範囲内に収まることが多いです。
・Log Analyticsデータ保持: デフォルトの31日間は無料。それ以降は$0.10/GB/月の追加費用がかかります。
・アラート: 静的なメトリクスアラートは10ルールまで無料。多次元メトリクスアラートやログアラートは有料です。
・Application Insights: データ取り込み量に応じた従量課金。月5GBまで無料枠あり。

コスト最適化の主なポイントは3点です。

・収集するログのSeverityを絞る: DCRでDebug・Infoレベルのログを除外するだけで、取り込みデータ量を数分の1に削減できます。Warningおよびerror以上だけ収集するのが現実的な出発点です。
・データ保持期間を短縮する: ワークスペースのデータ保持期間はデフォルト31日ですが、コンプライアンス要件がない場合は14日に短縮できます。長期保存が必要な場合はアーカイブティア（$0.02/GB/月）を活用します。
・コミットメントティアを活用する: 日次の取り込み量が安定して100GB以上ある大規模環境では、コミットメントティアに切り替えると従量課金より最大30%程度割安になります。

よくあるトラブルと対処法

ゲストOSのメトリクスが収集されない

症状: メモリ使用率やディスク空き容量がメトリクス一覧に表示されない。

原因: Azure Monitor Agent（AMA）が未インストール、またはデータ収集ルール（DCR）がVMに紐づいていないケースがほとんどです。

対処法: VMの「拡張機能 + アプリケーション」でAMAのステータスを確認します。「Provisioning succeeded」以外の状態なら再インストールを試みます。次にAzure Monitorの「データ収集ルール」でスコープに対象VMが含まれているかを確認します。DCRはリソースグループをまたいで適用できますが、リージョンが異なるVMには別途DCRが必要です。

ログアラートが期待通りに発火しない

症状: KQLでは条件に一致するログが取得できているのに、アラートが発火しない。

原因: ログアラートの評価頻度（最短5分）や集計期間の設定が意図と合っていないことが多いです。また、ログがVMから収集されてLog Analyticsに反映されるまで数分の遅延があります。

対処法: アラートルールの「評価の粒度」と「評価の頻度」を確認します。また、Log Analyticsのクエリウィンドウで手動実行し、直近5分以内のデータが取得できているかを検証します。タイムスタンプのずれが怪しい場合は`TimeGenerated`ではなく`_TimeReceived`でフィルタすると原因が絞り込みやすくなります。

AMAを入れたのにLog Analyticsにデータが来ない

症状: DCRも設定したはずなのに、Log Analyticsのテーブルにデータが入らない。

原因: VMのシステム割り当てマネージドIDが無効になっているケースが原因としてよく見られます。AMAはマネージドIDを使ってLog Analyticsに認証を行うため、IDが無効だとデータを送信できません。

対処法: VMの「セキュリティ」→「ID」でシステム割り当てマネージドIDのステータスが「オン」になっているか確認します。「オフ」なら有効化して保存します。その後10分程度待ってからLog Analyticsのクエリでデータが入ってきているかを確認します。

本記事のまとめ

Azure Monitorを使えば、オンプレ監視基盤の構築・維持にかかっていた工数を大幅に削減しながら、クラウドリソースの監視を実現できます。

オンプレで監視基盤の設計・運用経験があるエンジニアほど、Azure Monitorが解決しようとしている問題を肌感覚で理解できます。まずはテスト用VMを1台立て、メトリクスを確認してシンプルなCPUアラートを設定してみることから始めると、全体像が一気に掴めます。

クラウドの監視設計についてさらに深めたい方は、Linuxサーバー上でのパフォーマンス分析の基礎を解説している姉妹サイトLinuxMaster.JPも参考にしてみてください。