Azure Monitorのメトリック・ログ・アクティビティログの違い｜何を調べる？

メトリックは数値の変化、ログは時刻付きの詳しい記録を調べる手がかりです。Activity Log（アクティビティログ）は、リソースの作成や変更など、Azure側の管理操作を記録します。 どれを読むかは、知りたいことから決めると整理しやすくなります。

勉強会の申込アプリで、あおいさんが「午後から反応が遅い気がする」と相談された場面を考えましょう。「いつから数値が変わった？」「その時間に何が起きた？」「直前に構成を変更した？」では、探したい情報が違います。以下では、架空の申込アプリを例に考えてみましょう。

まず、知りたいことを一文にする

この表は、読む目的で分けたものです。Activity Logもログの一種なので、三つが完全に別の箱というわけではありません。 Azure Monitor Logsは、Activity Logやリソースログなどを集めて分析する基盤です。「記録の種類」と「記録を分析する場所」を分けて覚えましょう。Azure Monitorのデータの整理

メトリックでは、数値の変化をつかむ

メトリックは、ある時点の状態を数値で表したものです。Azure Monitor Metricsは数値を時刻とともに扱います。Azureリソースが出す「プラットフォームメトリック」は、Metrics explorerで時間に沿った変化を分析できます。利用できる指標は、リソースの種類などによって異なります。メトリックの公式概要

あおいさんの手元に「午前より午後の値が高くなった」というグラフがあっても、まずは何を測った値かを確かめます。件数なのか、時間なのか、割合なのか。対象と期間もそろえてから比べると、「高い」という印象を具体的な観察に変えられます。

たとえば「申込アプリの応答時間を表す指標で、午後の値が増えている」という説明なら、詳しく調べる時間帯を絞る手がかりになります。これは指標の読み方を示す例で、特定サービスにその名前の指標があると示すものではありません。

数値の上昇だけで、原因までは決まりません。Microsoftの概要でも、原因を調べる際はメトリックとログを組み合わせる考え方が示されています。数値と詳しい記録の役割

ログでは、その時間の記録を読む

ログは、時刻とともに残された出来事の記録です。数値だけでなく、対象や処理の内容などを含むことがあります。ただし、どんな項目が残るかは記録の種類によって違います。ログの考え方

Azure Monitor Logsは、集めたデータをLog Analytics workspaceのテーブルで扱います。分析にはKusto Query Language（KQL）や、KQLを直接書かずに使えるSimple modeなどがあります。まずは名前の関係を押さえれば十分です。Logsとワークスペースの公式説明

• Azure Monitor Logs：ログデータを収集・分析する基盤
• Log Analytics workspace：収集したデータをテーブルに保持する場所
• Log Analytics：ログを調べるための分析ツール

あおいさんが読みたいのは、反応が遅くなった時間帯の記録です。「資料取得の処理でエラーが記録されている」と分かれば、次の調査対象になります。ただし、その記録があることだけで、申込アプリ全体が遅い理由を確定したことにはなりません。

Activity Logでは、Azure側の管理操作を確かめる

Activity Logには、仮想マシンを作成する、リソースの設定を変更する、といった管理操作が記録されます。こうした操作を「コントロールプレーン」の操作と呼びます。Activity Logは既定で収集されますが、読み取り操作は通常記録されません。Activity Logの対象

一方、利用者が申込ボタンを押した、その処理でデータベースへ問い合わせた、といったアプリ内の出来事を、すべてActivity Logで追えるわけではありません。リソース内の操作については、対応するリソースログやアプリ側の記録を調べる話になります。

あおいさんが「遅くなる直前に設定を変更したか」を知りたいなら、Activity Logが手がかりです。操作が成功していたとしても、それはその管理操作の結果であり、利用者の申込が最後まで成功したことを示しません。管理操作とリソース内の操作

Activity Logは、送信設定をするとLog Analytics workspaceに取り込み、ほかのログと一緒に分析できます。最初からすべて同じ場所へ入っている、と考えないようにしましょう。Activity Logの送信先

記録が見つからないときは、収集の前提を確かめる

「Logsに何もないから、エラーは起きていない」とは判断できません。たとえばAzureのリソースログは、既定では収集されず、収集するには診断設定が必要です。内容はリソースの種類で異なり、分析できるようになるまでの時間もサービスや送信先によって変わります。リソースログの収集条件

今の構成を管理する人に確認するなら、次の三つをまとめておくと話が進めやすくなります。

1. 何の出来事を探しているか。対象のアプリやリソース、時刻も添える
2. その出来事に対応するログを収集しているか
3. 収集している場合、どこへ送っているか

これは確認メモです。記録がないときに、すぐ収集範囲や設定を変えるための手順ではありません。実際に収集を始める際は、対象データ、料金、アクセスできる人も含めて、担当者と公式手順を確認します。

三つの観察を、原因と分けて書いてみる

勉強会の架空のメモを、次のように並べてみましょう。

• メトリック：午後に、確認した指標の値が上がった
• ログ：同じ時間帯に、資料取得のエラーが記録されていた
• Activity Log：その前に、対象リソースへの変更操作が記録されていた

ここから言えるのは、調べたい時間帯と、照合する記録が見つかったことです。時刻が近いだけで、その変更が原因だとは決められません。 「分かった事実」と「これから確かめること」を分けておくと、調査を引き継ぐ人も読み取りやすくなります。

Azure側から障害やメンテナンスの情報が出ていないかを知りたいときは、Azure Status・Service Health・Resource Healthの違いも参考になります。対象のリソースやサブスクリプションの整理には、Azureの管理階層の記事を使えます。

まずは「数値の変化」「詳しい出来事」「管理操作」のどれを知りたいか、一文にしてみてください。その問いがあると、似た名前のメニューを見ても、探す情報を選びやすくなります。