Azure Monitorとは？メトリック・ログ・アラートの仕組みと監視の始め方を入門から解説

Azureでリソースやアプリを動かしはじめると、遅かれ早かれ「これ、ちゃんと動いてる？落ちたら気づける？」という不安に行き当たります。その不安に答えるのがAzure Monitorです。CPUが張りついていないか、エラーが増えていないか、誰かが設定を勝手に変えていないか——そういった「見守り」を一手に引き受けてくれる、いわばAzure全体の監視の司令塔ですね。

ところが、いざMicrosoft Learnを開くと「メトリック」「ログ」「診断設定」「Log Analytics」「Application Insights」といった言葉が一気に押し寄せてきて、「どれがどれの一部で、まず何を触ればいいの？」と手が止まってしまう。私自身、Azureの監視まわりを学びはじめた頃、この用語の多さで一度挫折しかけました。

「Azure MonitorとLog AnalyticsとApplication Insightsって、それぞれ別物なの？どういう関係なの？」

この記事では、そのモヤモヤをまず解消するところから始めます。Azure Monitorが何を束ねる傘なのかという全体像を押さえたうえで、メトリック・ログ・アラートの関係、データの入り口であるプラットフォームメトリックとログ（リソースログ／アクティビティログ）、そしてメトリックエクスプローラーでの可視化と基本的なアラートルールの作成までを、公式の正確さは押さえつつ初心者がつまずく所を日本語で噛み砕いて解説します。読み終わるころには「Azureの監視って、まずどこから手をつければいいか」の地図が頭に入っている状態を目指します。

Azure Monitorとは——監視の「傘」であり「司令塔」
メトリック・ログ・アラートの関係を先に整理する
データの入り口——メトリックとログはどこから来るのか
メトリックエクスプローラーで可視化してみる
基本的なアラートルールを作ってみる
まとめ
学んだクラウドスキルを、キャリアに活かす

Azure Monitorとは——監視の「傘」であり「司令塔」

いちばん最初に、いちばん大事な誤解を解いておきます。Log AnalyticsもApplication Insightsも、Azure Monitorの一部です。これらは別々の独立したサービスではなく、Azure Monitorという大きな傘の下にぶら下がっている構成要素なんですね。ここが分かると、あとの用語がぐっと整理されます。

イメージしやすいように、家全体の見守りシステムにたとえてみます。最近のスマートホームには、各部屋に温度センサーや人感センサー、玄関にカメラ、といった具合にいろんなセンサーが付いていますよね。でも家族が実際に見るのは、リビングに置かれた1台の中央モニターだったりします。各部屋のセンサーがバラバラに情報を出していても、中央モニターがそれを集めて「異常があればここに通知する」とまとめてくれる。この中央モニターにあたるのがAzure Monitorです。

そして各部屋の専門センサーが、Azure Monitorの構成要素にあたります。たとえばアプリの中身（応答時間・例外・依存関係など）を細かく測る専門センサーがApplication Insights、集まってきた大量のログをためて検索・分析する倉庫がLog Analytics、という具合です。それぞれ得意分野は違いますが、すべてAzure Monitorという一つの見守りシステムの部品として動いています。

この記事（Azure Monitor編）が扱うのは、その中央モニターそのものの役割——メトリックの収集・アラートの発報・診断設定という監視の統括の部分です。「アプリ内部の細かい計測（APM）」はApplication Insights編、「ためたログをKQLで検索・分析する話」はLog Analytics編にそれぞれ譲ります。まずは司令塔の全体像を押さえましょう。

Azure Monitorが偉いのは、Azureの全リソースに最初から組み込まれている点です。仮想マシンでもApp ServiceでもストレージでもAKSでも、リソースを作った瞬間から基本的な監視データ（後述するプラットフォームメトリック）が勝手に集まりはじめます。「監視を始めるために別途エージェントを入れて…」という準備が要らない部分があるのは、地味ですが大きな利点です。

メトリック・ログ・アラートの関係を先に整理する

Azure Monitorを理解するうえで、この3つの言葉の関係だけは先に頭に入れておくと、以降がスムーズです。ざっくり言うと、メトリックとログが「集めるデータの2種類」で、アラートがそれを見張って「知らせる仕組み」です。

メトリック＝数値の時系列データ

メトリック（Metrics）は、「CPU使用率が今70%」「メモリの空きが2GB」のような、時間とともに変化する数値です。1分ごと、といった一定間隔で自動的に測られ、グラフにするとギザギザの折れ線になる——あの手のデータですね。健康診断でいえば、心拍数や血圧を連続で測ったグラフのようなものです。

メトリックの長所は軽くて速いことです。数値だけなので保存も検索も高速で、リアルタイムに近い監視に向きます。一方で「なぜCPUが上がったのか」という詳しい理由までは分かりません。数値の傾向を見るのは得意でも、原因の中身までは持っていないわけです。

ログ＝詳細なイベントの記録

その「詳しい中身」を担当するのがログ（Logs）です。ログは「何時何分に、誰が、何をして、その結果どうなったか」という1件ごとのイベントの記録です。エラーメッセージ、操作履歴、リクエストの詳細など、テキストや構造化された情報が並びます。健康診断でいえば、数値の裏にある「この日にこういう症状が出た」という診療メモにあたります。

ログは情報が濃いぶん量が多く、そのままでは扱いきれません。そこで、集めたログをLog Analyticsワークスペースという倉庫にためて、KQL（Kusto Query Language）という専用の言語で検索・集計します。「ログを検索して原因を掘る」話の主役はこのLog Analyticsなので、KQLの書き方はLog Analytics編に譲ります。ここでは「詳細な調査はログ、そのためにLog Analyticsがある」という関係だけ押さえてください。

アラート＝条件を見張って知らせる仕組み

メトリックとログをせっかく集めても、人が四六時中グラフを眺めているわけにはいきません。そこでアラート（Alerts）の出番です。アラートは「この条件になったら知らせて」というルールで、たとえば「CPUが5分間90%を超えたらメールを飛ばす」といった見張り役を自動でやってくれます。

ここまでを一本の流れで整理すると、こうなります。

集める：メトリック（数値の時系列）とログ（詳細なイベント）を収集する
見張る：アラートルールが、その数値やログを条件に照らして監視する
知らせる：条件に当てはまったら、メールなどで通知する

Azure Monitorがやっていることは、突き詰めればこの「集める→見張る→知らせる」の繰り返しです。この骨格さえ掴めれば、細かい機能はすべてこのどこかに位置づけて理解できます。

データの入り口——メトリックとログはどこから来るのか

次に、「そのデータ、そもそもどこから集まってくるの？」というデータソースの話です。ここを分かっておくと、監視の設定画面で迷わなくなります。大きく分けて、自動で集まるメトリックと、設定して集めるログがあります。

プラットフォームメトリック——何もしなくても集まる数値

まずプラットフォームメトリック。これはAzureのリソース自身が自動的に発行してくれる数値データで、こちらが何か設定しなくても、リソースを作った瞬間から勝手に集まりはじめます。仮想マシンなら「CPU使用率」「ネットワーク送受信量」、ストレージアカウントなら「トランザクション数」「使用容量」といった具合に、リソースの種類ごとに用意された標準の測定項目です。

「監視の第一歩は無料で、しかも自動」というのがポイントです。しかもプラットフォームメトリックは追加費用なしで一定期間保持されるので、まずはこれを眺めるだけでも「今このリソースが元気かどうか」はかなり分かります。学習を始めたばかりの段階なら、当面はこのプラットフォームメトリックだけで十分に監視の感覚がつかめます。

リソースログ——リソースの「内部で起きたこと」

次にリソースログです。これは個々のリソースの内部で起きた詳細なイベントの記録です。たとえばストレージなら「どのファイルへの読み書きが成功／失敗したか」、Key Vaultなら「どのシークレットにアクセスがあったか」といった、そのリソースの中身の動きを細かく記したログですね。

ここで一つ、初心者がつまずく大事な注意点があります。リソースログは、既定ではどこにも保存されていません。プラットフォームメトリックが「勝手に集まる」のに対し、リソースログは「診断設定」で送り先を指定して初めて集まりはじめるのです。「あとから障害を調べようとしたらログが残っていなかった」というのは、この診断設定をしていなかったのが原因、というのがよくあるパターンです。ただし診断設定は設定項目が多く話も広がるので、具体的な手順は子記事のアラート・自動化編でまとめて扱います。ここでは「リソースの詳細ログは、診断設定をしないと残らない」という一点だけ覚えておいてください。

アクティビティログ——サブスクリプションでの「操作の記録」

もう一つの重要なログがアクティビティログです。リソースログが「リソースの中で何が起きたか」だったのに対し、アクティビティログはサブスクリプションのレベルで、誰が何を操作したかを記録します。「田中さんが仮想マシンを削除した」「その設定を誰がいつ変更した」といった、いわば操作の監査ログですね。

この2つの違いは、家のたとえで言うと分かりやすいです。リソースログは「各部屋の中で何が起きたか（この部屋のエアコンが何時に止まった、など）」、アクティビティログは「家全体で誰が何をしたか（誰が玄関のカギを開け閉めした、誰が家電の設定を変えた、など）」。前者は個別の部屋の話、後者は家全体を俯瞰した操作履歴、というわけです。

アクティビティログは診断設定なしでもポータルから直近90日分を確認できます。「あれ、この設定いつの間に変わった？」というときに、まず開いて犯人（というと物騒ですが、操作の主体）を突き止められる、トラブル時に頼りになる存在です。

メトリックエクスプローラーで可視化してみる

理屈が分かったところで、いちばん手を動かしやすいメトリックの可視化を試してみましょう。使うのはメトリックエクスプローラーという、集まったメトリックをグラフにして眺めるためのツールです。プログラミングは一切要らず、画面のプルダウンを選んでいくだけでグラフが描けます。

入り口は2通りあります。1つはAzure Monitorから横断的に見る方法で、ポータル上部の検索窓に「Monitor」と入れてAzure Monitorを開き、左メニューの「メトリック」を選びます。もう1つは個別リソースから見る方法で、たとえば仮想マシンのページを開き、左メニューの「メトリック」を選ぶと、そのリソースに絞ったメトリック画面が出ます。最初は後者のほうが対象が明確で分かりやすいので、手近なリソースから触ってみるのがおすすめです。

グラフを作る手順はシンプルで、次の3つを選ぶだけです。

スコープ：どのリソースを見るか（個別リソースから開いた場合は最初から入っています）
メトリック：何を見るか（例：「Percentage CPU」＝CPU使用率）
集計：どうまとめるか（平均／最大／合計など。CPU使用率なら「平均」や「最大」が定番）

たとえば仮想マシンで「Percentage CPU」を「平均」で選ぶと、この時間帯のCPU使用率の推移が折れ線グラフで描かれます。画面右上で「過去1時間／過去24時間／過去7日間」といった時間範囲を切り替えられるので、「昨夜のバッチ処理の時間帯だけCPUが跳ねているな」といった傾向がひと目で読み取れます。

まずは1つのリソースで1つのメトリックをグラフにするところから。ここが「監視できてる」という手応えの第一歩です。

作ったグラフは、右上の「ダッシュボードに固定」からダッシュボードに貼り付けておけます。よく見る指標を1画面にまとめておくと、毎回リソースを開き直さずに全体を見渡せるようになります。まずはCPUとメモリ、といった定番から並べてみてください。

基本的なアラートルールを作ってみる

グラフで傾向が見えるようになったら、最後は異常を自動で知らせる仕組み、つまりアラートルールです。ここまで来ると「監視している」感がぐっと増します。例として「仮想マシンのCPU使用率が高くなったらメールで知らせる」という、いちばん基本的なアラートを作ってみましょう。

作成の入り口は、リソースの左メニューの「アラート」→「アラートルールの作成」、またはAzure Monitorの「アラート」からです。設定は、大きく次の3ステップで進みます。

1. 条件（シグナル）を決める

まず「何を、どうなったら」を決めます。シグナルの一覧から「Percentage CPU」を選び、しきい値を設定します。たとえば「平均が5分間で80%を超えたら」という具合ですね。ここで「5分間」という評価の期間を持たせるのが実務のコツです。CPUは一瞬だけ跳ねることがよくあるので、瞬間値で反応させると通知が鳴りっぱなしになります。「一定時間、続けて超えたら」にしておくと、本当に問題があるときだけ鳴るようになります。

2. 通知先（アクション）を決める

次に「条件に当てはまったら誰にどう知らせるか」を決めます。ここでアクショングループという「通知先のセット」を指定するのですが、まずは自分のメールアドレスを1件登録するだけで動きます。アクショングループはメール以外にSMS・Webhook・自動復旧処理の呼び出しなど、かなり奥が深い部分なので、本格的な設計は子記事のアラート・自動化編でまとめて扱います。ここでは「アラートが鳴ったらメールを飛ばす」最小構成で十分です。

3. 重要度と名前を付けて保存

最後に、アラートの重要度（Sev 0＝致命的〜Sev 4＝情報、といった深刻度のレベル分け）と、分かりやすい名前を付けて保存します。名前は「VM-CPU-High」のように「何のアラートか」がひと目で分かるものにしておくと、数が増えたときに自分が助かります。

保存すれば、以降はAzure Monitorが自動でCPUを見張り続け、条件を超えたときだけメールが届きます。ここまでできれば、もう「気づいたら落ちていた」を卒業です。動作確認として、あえてしきい値を低め（例：5%）に設定して負荷をかけ、本当にメールが来るか試しておくと安心です（確認できたら現実的な値に戻すのを忘れずに）。

なお、ここで作ったのは固定のしきい値による、いちばん素直なアラートです。実務では「時間帯によって普段の値が違うので、しきい値を自動で学習してほしい」という動的しきい値や、複数のアクションをまとめる高度なアクショングループを使う場面も出てきます。そのあたりは、この記事の続編で扱います。

まとめ

この記事では、Azureの監視の入り口としてAzure Monitorの全体像と基本操作を見てきました。要点を振り返ります。

Azure Monitorは監視の傘（司令塔）。Log AnalyticsもApplication Insightsも、その一部。中央モニターと各部屋のセンサーの関係。
メトリック＝数値の時系列／ログ＝詳細なイベント／アラート＝条件を見張って知らせる仕組み。「集める→見張る→知らせる」の骨格。
プラットフォームメトリックは何もしなくても自動で集まる。リソースログは診断設定をしないと残らない。アクティビティログはサブスクレベルの操作の監査記録。
メトリックエクスプローラーは、スコープ・メトリック・集計を選ぶだけでグラフ化できる。
基本アラートは、条件（しきい値＋評価期間）→通知先（メール）→重要度・名前、の3ステップ。瞬間値でなく一定時間で評価するのがコツ。

ここまでで、「Azureの監視をまずどこから始めればいいか」の地図は手に入りました。次のステップは、この基本を土台にした実務レベルの監視設計——診断設定でログをきちんと集め、アクショングループで通知を整理し、動的しきい値で誤検知を減らし、Workbooksで見やすいレポートを作り、Autoscaleで負荷に応じて自動でスケールさせる、といった世界です。