Japan Azure Monitoring Support Team Hexo https://jpazmon-integ.github.io/blog/ All rights reserved 2026, Japan Azure Monitoring Support Team 日本マイクロソフトの Azure Monitoring に関するサポート情報のブログです。 Japan Azure Monitoring Support Blog 2026-09-06T00:15:21.630Z Japan Azure Monitoring Support Team [更新履歴]

  • 2026/09/06 ブログ公開

こんにちは、Azure Monitoring サポート チームの北村です。
Azure Monitor のアラート ルールの一つに「ログのメトリック アラート」というアラートが存在することをご存知でしょうか。
名前だけを見るとメトリック アラートの一種に見えますが、Azure Monitor エージェント (AMA) によって収集されたログをメトリックに変換したうえで監視する、少し特殊な仕組みを持っています。

今回は「ログのメトリック アラート」の概要と仕組み、そしてログ アラートとの違いについてご紹介いたします。


目次


1. ログのメトリック アラートとは

ログのメトリック アラート は、Azure Monitor エージェント (AMA) によって Log Analytics のエンドポイントに送信された Heartbeat や Perf などのログをメトリックに変換し、変換後のメトリックを監視するアラート ルールです。

これに対して、ログ アラート ルール は、Log Analytics ワークスペースに収集されたログそのものを KQL クエリで監視するアラート ルールです。

両者は、元となるデータが Log Analytics のエンドポイントに送信されたログである点は共通していますが、実際の監視対象（ログ アラート ルールはログそのもの、ログのメトリック アラートは変換後のメトリック）が異なります。

ログのメトリック アラートは、対応するログをメトリックに変換して監視するため、準リアルタイム性やディメンションによる絞り込みを重視する場合に適しています（3. ログのメトリック アラートの利点 参照）。一方、任意の KQL クエリでログを柔軟に評価したい場合は、ログ アラート ルールが適しています。

例えば、AMA によって収集された Heartbeat を対象にログのメトリック アラートを作成すると、Heartbeat ログがメトリックに変換され、Log Analytics ワークスペースのメトリック エクスプローラー上で以下のように表示されます。ログのメトリック アラートでは、この変換後のメトリックが監視対象となります。

なお、ログのメトリック アラートで監視可能なデータは、公開情報 の「Category: Legacy Log-based metrics」に記載されているメトリックのみです。アラートを作成する前に、監視したいログに対応するメトリック名とディメンションが一覧に含まれていることをご確認ください。

Note

Azure Monitor エージェント (AMA) では、パフォーマンス カウンターを直接メトリックとして収集することが可能です。そのため、ログのメトリック アラートではなく、通常のメトリック アラート ルールでも監視することができます。なお、この方法で収集できるのはパフォーマンス カウンターのみとなり、Heartbeat は対象外となりますのでご注意ください。


2. ログのメトリック アラートの仕組み

ログのメトリック アラートは、以下の 2 つのリソースによって構成されます。

リソースの種類役割
Microsoft.Insights/metricAlerts変換されたメトリックのしきい値を監視し、アラートを発報するルール
Microsoft.Insights/scheduledQueryRulesログをメトリックに変換する特殊なルール

Azure ポータルからログのメトリック アラート (metricAlerts) を作成すると、metricAlerts と同じ名前で scheduledQueryRules がバックグラウンドで自動的に作成されます。Azure ポータル以外（ARM テンプレートや REST API など）でログのメトリック アラートを作成する場合は、手動で scheduledQueryRules を作成する必要がありますのでご注意ください。scheduledQueryRules を作成するサンプルの ARM テンプレートは、こちらの公開情報をご覧ください。

なお、scheduledQueryRules を削除すると、メトリックが生成されず、メトリック アラートで監視することができなくなりますので、scheduledQueryRules は削除しないようにご注意ください。


3. ログのメトリック アラートの利点

ログ アラート ルールと比較したときの、ログのメトリック アラートの主な利点は以下のとおりです。

準リアルタイムの監視

ログのメトリック アラートでは、ログ用のパイプラインとは別に用意されたメトリック用のパイプラインでデータが処理されます。
それぞれのデータの流れは、以下のとおりです。

A. ログが Log Analytics ワークスペースに取り込まれるまでの流れ

  1. ゲスト OS 内の AMA にて、ログが生成される
  2. ゲスト OS 内の AMA が、Log Analytics のエンドポイントに対してログを送信する
  3. Log Analytics のエンドポイントが、AMA からログを受け取る
  4. ログがパイプラインに転送され、処理される
  5. KQL クエリでログが検索できるようになる

B. ログがメトリックに変換されるまでの流れ

  1. ゲスト OS 内の AMA にて、ログが生成される
  2. ゲスト OS 内の AMA が、Log Analytics のエンドポイントに対してログを送信する
  3. Log Analytics のエンドポイントが、AMA からログを受け取る
  4. ログのパイプラインとは別の、メトリック用のパイプラインにデータが転送され、処理される
  5. メトリックとして検索できるようになる

1.～ 3. までは共通ですが、4. 以降で使用する処理パイプラインが分かれます。
ログが KQL で検索可能になるまでの経路（A）よりも、メトリックとして参照可能になるまでの経路（B）の方が所要時間が短いため、ログのメトリック アラートでは、ログ アラート ルールよりもリアルタイムに近い監視が可能です。


ディメンションによるフィルタリング

ログのメトリック アラートでは、ディメンションでコンピューター名や OS の種類などをフィルタリングでき、複雑な KQL クエリを定義せずに特定のマシンや条件に絞った監視を構成できます。

※ 以下は Heartbeat メトリックを指定したときのディメンションです。


4. ログのメトリック アラートの作成方法

それでは、Heartbeat メトリックを監視するログのメトリック アラートを作成してみましょう。
本項では、5 分おきに評価を行い、直近 5 分間に記録された Heartbeat メトリックの合計値が 1 を下回った場合に発報する構成を例に、ログのメトリック アラートの設定手順を紹介します。

1. Log Analytics ワークスペースに Heartbeat ログが収集されていることを確認する
前提として、AMA で Log Analytics ワークスペースに Heartbeat や Perf を収集していなければ、ログのメトリック アラートで監視することはできません。今回は、Heartbeat メトリックを監視するアラートを作成したいので、Log Analytics ワークスペース上で Heartbeat が収集されているかどうかを確認します。

1
2
3
// サンプル クエリ
Heartbeat
| where TimeGenerated > ago(1d)


2. スコープで Log Analytics ワークスペースを指定し、アラートの条件を指定する
Azure ポータル > [モニター (監視)] > [アラート] を開き、画面上部の [+ 作成] > [アラート ルール] を選択します。
スコープを選択する画面が表示されますので、「監視対象のマシンの Heartbeat ログが収集されている Log Analytics ワークスペース」を選択します。

次の画面では、アラートの発報条件を指定します。
シグナル名では [Heartbeat] を選択し、メトリック アラートの評価に関わる項目を設定します。

  • 確認する間隔 : 評価を行う頻度
  • ルックバック期間 : 1 回の評価を行う際に評価の対象となる期間
  • 集計の種類 : [ルックバック期間] で指定した期間のメトリックを集計する方法

今回は、以下のとおり設定します。
マシンごとに監視するため、ディメンションでは [Computer] を指定します。

  • シグナル名 : Heartbeat
  • しきい値の種類 : Static
  • 集計の種類 : 合計
  • 値は : 次の値より小さい
  • 単位 : カウント
  • しきい値 : 1
  • ディメンション名 : Computer
  • 確認する間隔 : 5 分
  • ルックバック期間 : 5 分

Note

メトリック アラートの設定項目につきましては、サポート ブログの Azure Monitor のアラートに関するよくあるご質問 や公開情報をご覧ください。


3. アラートで通知する方法を指定する
Azure Monitor のアラート機能では、アクション グループ というリソースでアラートを通知する方法を定義します。[アクション グループの選択] をクリックすると、既存のアクション グループの一覧が表示されます。新規で作成する場合は、画面右側に表示される [+ アクション グループの作成] を選択します。

例えば、アラートをメールで通知する場合には、[通知のタイプ] で “電子メール/SMS メッセージ/プッシュ/音声” を選択し、通知するメール アドレスを指定します。

また、[アクション] では、アクション グループがトリガーされた際に実行するアクションを選択できます (今回は設定しません)。

Note

アクション グループの概要や設定手順につきましては、公開情報をご覧ください。


4. アラート ルールの名前、アラートの重大度等を設定する
[アラート ルールの詳細] では、重大度、アラート ルール名、アラート ルールの説明を設定します。
[詳細設定オプション] では、アラート ルールの有効化や自動解決を設定します。

[アラートを自動的に解決する] にチェックを入れると、ステートフルなアラート として動作します。条件を満たすと発報し、条件が解消されるまでは同じ時系列に対して新たなアラートは発報されません。メトリック アラートでは、条件を満たさない評価が 3 回連続すると解決済みに移行し、解決通知が行われます。

[アラートを自動的に解決する] でチェックしない場合は、ステートレスなアラートとなり、しきい値を満たす度に発報します。この場合、アラートが解決したとみなされることはないため、解決した旨の通知も行われません。

お客様のご要件に合わせてご設定ください。


手順は以上です。

アラートの履歴は、Azure ポータル > [モニター (監視)] > [アラート] からご確認いただけます。
以下の例では、アラートの評価時点から過去 5 分間の Heartbeat メトリックの合計値が 1 を下回ったため、アラートが発報していることが分かります。


5. ログのメトリック アラートに関するよくあるご質問

最後に、ログのメトリック アラートでよくお問い合わせいただく質問をご紹介いたします。


Q. Heartbeat メトリックを監視するアラートを作成したところ、メトリック アラートとログ アラート ルールが同時に作成されました。ログ アラート ルールは削除してもいいですか。

いいえ、ログをメトリックに変換する scheduledQueryRules は削除しないでください。
作成されたメトリック アラートは、AMA によって収集されたログをメトリックに変換し、メトリックを評価する「ログのメトリック アラート」です。Azure ポータルからログのメトリック アラートを作成した場合、ログをメトリックに変換するための scheduledQueryRules が自動で作成されますが、削除するとメトリックが生成されなくなるため、監視できません。

Q. メトリックに変換する scheduledQueryRules がアラート ルールの一覧に表示されません。

Azure Monitor の通常のアラート ルールは、Azure ポータル > [モニター (監視)] > [アラート] > [アラート ルール] に表示されますが、ログをメトリックに変換する scheduledQueryRules は表示されません。

※ シグナルの種類が「メトリクス」の metricAlerts のみが表示されます。

メトリックに変換する scheduledQueryRules は、対象のリソース グループの [概要] ペインで確認できます。
Azure ポータルからログのメトリック アラートを作成した場合は、metricAlerts と同じ名前の scheduledQueryRules が作成されますので、リソース名で絞り込むと、次の 2 種類のリソースが表示されます。

  • [種類] が「メトリック アラート ルール」: metricAlerts
  • [種類] が「ログ検索警告ルール」: scheduledQueryRules


Q. Azure ポータル上でメトリックに変換する scheduledQueryRules を表示したところ、Cannot read properties of undefined (reading ‘toLowerCase’) と表示されます。

scheduledQueryRules は、ログをメトリックに変換する専用のルールです。
通常のログ アラート ルールの定義を持たないため、Azure ポータル上で開くと以下のエラーが表示されますが、アラートの動作不良を示すものではございません。


Q. Heartbeat メトリックが生成されていることを確認する方法はありますか。

Heartbeat ログを収集している Log Analytics ワークスペース > [監視] > [メトリック] から確認可能です。
Heartbeat ログが収集され、メトリックに変換されている場合は、0 より大きい値が記録されます。


本記事では、ログのメトリック アラートの仕組み、ログ アラート ルールとの違い、作成方法、よくあるご質問をご紹介しました。
上記内容以外でご不明な点や疑問点などございましたら、弊社サポートまでお問い合わせください。
最後までお読みいただきありがとうございました！

]]> https://jpazmon-integ.github.io/blog/AzureMonitorEssential/LogToMetricAlert/ 2026-09-05T15:00:00.000Z [更新履歴]

  • 2026/09/06 ブログ公開

こんにちは、Azure Monitoring サポート チームの北村です。
Azure Monitor のアラート ルールの一つに「ログのメトリック アラート」というアラートが存在することをご存知でしょうか。
名前だけを見るとメトリック アラートの一種に見えますが、Azure Monitor エージェント (AMA) によって収集されたログをメトリックに変換したうえで監視する、少し特殊な仕組みを持っています。

今回は「ログのメトリック アラート」の概要と仕組み、そしてログ アラートとの違いについてご紹介いたします。


]]> ログのメトリック アラートについて 2026-09-06T00:15:21.630Z Japan Azure Monitoring Support Team [更新履歴]

  • 2026/08/07 ブログ公開
  • 2026/08/12 一部リンクを修正しました

こんにちは！Azure Monitoring チームの佐藤です。

本記事は、2026 年 9 月 30 日にサポートを終了いたします ContainerLog テーブルについて、後継の ContainerLogV2 テーブルへ移行いただく方法について案内しております。

目次


1. 本記事の概要

以下の公開情報に記載があります通り、ContainerLog テーブルの使用が 2026 年 9 月 30 日をもってサポートされなくなります。

サポート終了に伴い、ContainerLog テーブルをご利用いただいている場合には後継の ContainerLogV2 テーブルへ移行をいただく必要がございます。
本記事では、Azure Kubernetes Service (AKS) リソースで利用されていることを前提とした移行方法について、いくつか具体的なシナリオを挙げて紹介いたします。

2. 移行の前にご確認ください

2-1. レガシ認証の使用有無

シナリオごとの移行方法の前に、まずは Container Insights における認証方法として現在何が使用されているかを確認いただく必要がございます。
Container Insights の認証方法としては、証明書ベースのローカル認証であるレガシ認証と、マネージド ID 認証の 2 種類がございます。
レガシ認証を使用している場合、レガシ認証も ContainerLog テーブルと同じ 2026 年 9 月 30 日をもってサポートがされなくなります。

そのため、レガシ認証を使用している場合には、まずマネージド ID 認証に移行する必要があります。
(後述いたしますマネージド ID 認証への移行をいただくだけで、ContainerLogV2 テーブルへの移行も完了します。)

レガシ認証を使用しているクラスターは、Azure Resource Graph のクエリを用いて以下の手順で調べることができます。

公開情報

レガシ認証を使用しているクラスターの検索手順

  1. Azure ポータルの検索バーにて、”Resource Graph エクスプローラー” と検索し、サービス項目にある [Resource Graph エクスプローラー] をクリックします。

  2. 以下のクエリを貼り付け、画面上部にあります [実行] をクリックします。

1
2
3
4
5
6
7
8
9
10
resources        
| where type =~ 'Microsoft.ContainerService/managedClusters'       
| project id, name, aksproperties = parse_json(tolower(properties)), location, identity        
| extend isEnabled = aksproperties.addonprofiles.omsagent.enabled         
| extend workspaceResourceId = iif(isEnabled == true, aksproperties.addonprofiles.omsagent.config.loganalyticsworkspaceresourceid, '')        
| extend useAADAuth  = aksproperties.addonprofiles.omsagent.config.useaadauth  
| where isEnabled =~ "true" and useAADAuth != true 
| extend parts = split(tostring(id), "/")
| extend subscriptionId = parts[2], AKSClusterName = parts[-1], resourceGroupName = parts[4] 
| project AKSClusterName, resourceGroupName, subscriptionId, location, AKSClusterId = tolower(id), workspaceResourceId

  1. 実行結果に表示されているクラスターでレガシ認証が使用されております。

2-2. 該当する移行シナリオはどれか

ここから、具体的な移行方法を説明します。
どのシナリオが該当するかについては、以下のフロー チャートが参考になれば幸いです。

2-3. 移行に伴う注意点

ログの格納先が ContainerLog テーブルから ContainerLogV2 テーブルに変更されても、ログ アラート ルールやダッシュボードなど ContainerLog テーブルのデータを活用するサービスで用いるクエリは自動で変更されません。
ContainerLog テーブルを検索しているクエリがある場合には、お客様ご自身で ContainerLogV2 テーブルをクエリするよう変更いただく必要がございます。

例えば、ContainerLog テーブルに対してクエリを行っているアラート ルールが存在するかどうかは、
以下の Azure Resource Graph クエリでご確認いただけます。

Azure Resource Graph クエリの使用方法は、前述の “2-1. レガシ認証の使用有無 “ 内、”レガシ認証を使用しているクラスターの検索手順” に記載しております。 

1
2
3
4
5
6
7
8
9
resources
| where type in~ ('microsoft.insights/scheduledqueryrules') and ['kind'] !in~ ('LogToMetric')
| extend severity = strcat("Sev", properties["severity"])
| extend enabled = tobool(properties["enabled"])
| where enabled in~ ('true')
| where tolower(properties["targetResourceTypes"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["targetResourceType"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["scopes"]) matches regex 'providers/microsoft.operationalinsights/workspaces($|/.*)?'
| where properties contains "ContainerLog"
| project id,name,type,properties,enabled,severity,subscriptionId
| order by tolower(name) asc

また、移行が完了してから ContainerLogV2 テーブルにログが格納されるようになるまで、10 分程度お時間がかかります。

3. レガシ認証を使用した Container Insights の場合の移行方法

レガシ認証からマネージド ID 認証に移行する過程で、ContainerLog テーブルから ContainerLogV2 テーブルへの移行も行われます。
そのため、レガシ認証からマネージド ID 認証への移行のみを実施いただければ十分でございます。

移行手順

Azure CLI (バージョン 2.49.0 以上) で移行いただけます。
具体的な移行方法について、以下の公開情報に記載しております。

マネージド ID 認証に移行した場合に、どのような変更が生じるか、どのような影響があるかなどについては、
以下の公開情報にまとまっております。
よろしければ併せてご参照ください。

4. マネージド ID 認証を使用した Container Insights の場合の移行方法

すでに移行対象のクラスターでマネージド ID 認証を使用している場合には、ConfigMap で ContainerLogV2 テーブルにログを送るような設定を行う、
またはログ プロファイルの設定で ContainerLogV2 テーブルにログを送るような設定を行うことで移行がいただけます。(*)

(*)
ContainerLog テーブルにログが格納される条件は、以下 2 つを両方とも満たす場合でございます。

  • ConfigMap において ContainerLogV2 へのログ送信が明示的にオフにされている
  • ログ プロファイルで ContainerLogV2 へのログ送信が明示的にオフされている

4-1. ConfigMap の yaml を編集することにより移行する

ConfigMap では、パラメーター containerlog_schema_version を使用して、ContainerLog テーブルにログを送信する設定 (v1) になっているか、ContainerLogV2 テーブルにログを送る設定 (v2) になっているかを判断しています。
そのため、使用している yaml 内でこのパラメーターの値を変更いただく必要があります。

(参考) パラメーターの一覧および各パラメーターの説明については、以下をご参照ください。

移行手順

  1. まず、ConfigMap が利用されていること、およびパラメーター container_schema_version の値を確認します。
1
kubectl get configmap container-azm-ms-agentconfig -n kube-system -o yaml

対象の環境で、ConfigMap の使用がない場合には、以下のような出力となります。

1
Error from server (NotFound): configmaps "container-azm-ms-agentconfig" not found

この場合、既存の ConfigMap はありませんので、[4-2. ConfigMap を有効化することにより移行する] または [4-3. ログ プロファイルを設定することにより移行する] のどちらかで移行いただく必要がございます。

  1. ConfigMap が存在し、ConfigMap の設定が出力された場合には、パラメーター container_schema_version の値が “v1” になっていることを確認します。
    この部分を “v2” に変更いただき、kubectl apply によりデプロイしてください。
1
kubectl apply -f container-azm-ms-agentconfig.yaml

4-2. ConfigMap を有効化することにより移行する

移行手順

ConfigMap を有効化することで ContainerLogV2 テーブルに移行する場合の手順は、以下の公開情報に記載しております。

ConfigMap を有効化いただくと、既定で ContainerLogV2 テーブルにログが送られるようになります。

4-3. ログ プロファイルを設定することにより移行する

必要な Azure 組み込みロール

少なくともクラスターへの共同作成者権限が必要でございます。

移行手順

  1. Azure ポータルにて、ContainerLogV2 テーブルへの移行を行う AKS リソースを開きます。
  2. 画面左側にある [モニター (分析情報)] をクリックします。
  3. 画面上部にある [モニターの設定] をクリックします。

  4. [機能] タブ内、”インフラストラクチャの監視” 項目にある [機能のカスタマイズ] をクリックします。

  5. “構成のカスタマイズ” ウィンドウが開いたら、ログとイベント > ログ プリセット 項目に表示されている [コレクション設定の編集] をクリックします。

  6. [ContainerLogV2 を有効にする] にチェックを入れ、下部にある [保存] をクリックします。


設定内容を確認し、もう一度 [保存] をクリックすると、”構成のカスタマイズ” ウィンドウが閉じます。

  1. “モニターの設定” 画面下部にあります [レビューと有効化] をクリックし、設定内容が想定通りである場合には、[有効にする] をクリックします。

(参考)

5. まとめ

2026 年 9 月 30 日に ContainerLog テーブルの使用のサポートが終了するに際し、AKS 環境にて後継の ContainerLogV2 テーブルへ移行する方法を紹介いたしました。
本記事が、少しでも移行を検討される際にお役に立てれば幸いです。

]]> https://jpazmon-integ.github.io/blog/LogAnalytics/MigrationToContainerLogV2/ 2026-08-06T15:00:00.000Z [更新履歴]

  • 2026/08/07 ブログ公開
  • 2026/08/12 一部リンクを修正しました

こんにちは！Azure Monitoring チームの佐藤です。

本記事は、2026 年 9 月 30 日にサポートを終了いたします ContainerLog テーブルについて、後継の ContainerLogV2 テーブルへ移行いただく方法について案内しております。

]]> ContainerLog テーブルのサポート終了に伴う ContainerLogV2 テーブルへの移行について 2026-09-06T00:15:21.903Z Japan Azure Monitoring Support Team [更新履歴]

  • 2026/07/30 : ブログ公開

目次


1. はじめに

この記事はこれから Azure Monitor 製品を利用する方や、追加の監視構成を検討している方への入り口となることを目的にしています。Azure Monitor 製品にはどのような機能があり、構成することで何を行うことができるのかを極力簡潔に記載しています。
また、製品を利用するうえで頻出の用語や、各ソリューションの概念図も載せています。
是非ご覧いただき、Azure Monitor 製品ご利用の一助となれば幸いです。

※本記事は Microsoft Learn の Azure Monitor に関する公開情報を代替するものではありません。各機能の詳細や、最新の情報は Microsoft Learn でご確認ください。
Azure Monitor のドキュメント - Azure Monitor | Microsoft Learn


2. 用語集

本項では Azure Monitor 関連製品でよく使われる用語を記載しています。
本ブログ記事や公開情報を参照する際の参考となれば幸いです。


Azure Monitor 全般に関連する用語

Azure Monitor
Azure リソースやアプリケーションの状態を収集、分析、可視化、通知するための監視サービス ソリューションの総称です。
メトリックやログの収集と可視化、アラートによる通知など、監視に必要な機能をまとめて提供しています。


ログ収集機能に関連する用語

Azure Monitor エージェント (AMA)
OS にインストールされ、ログやメトリック情報を Azure 上に送信するためのエージェントです。
Windows 用と Linux 用があり、Azure VM の場合は拡張機能としてインストールされます。

データ収集ルール (DCR)
Azure Monitor エージェントが収集するデータの種類や送信先を定義するルールです。
Windows イベント ログ、Syslog、パフォーマンス カウンターなどの収集設定に利用します。

データ収集エンドポイント (DCE)
Azure Monitor エージェントやログ インジェスト API のデータ送信先となるエンドポイントです。
ネットワーク制御や Azure Monitor Private Link Scope (AMPLS) を利用する構成で必要になる場合があります。

Azure Monitor Private Link Scope (AMPLS)
Azure Monitor の各リソースへのアクセスをプライベート エンドポイント経由で実現するための構成リソースです。
Log Analytics ワークスペースや Application Insights、DCE などを AMPLS に関連付け、プライベート エンドポイント経由で通信できます。

VM Insights
Azure Monitor で仮想マシンのパフォーマンスや依存関係のデータを収集し監視するための機能です。
CPU、メモリ、ディスク、ネットワークなどの情報を収集し、複数 VM の状態をまとめて確認できます。
Azure Monitor エージェント (AMA) が使用されます。

変更履歴とインベントリ
OS 内のソフトウェア、サービス、ファイル、レジストリなどの変更情報を収集するための機能です。
サービスの起動状態や構成変更を Log Analytics ワークスペースで確認できます。
Change Tracking and Inventory とも呼ばれます。

Application Insights
アプリケーションの可用性、性能、利用状況、例外などを監視するための Azure Monitor の機能です。
アプリケーションから送信されるテレメトリを収集し、ログ検索や可視化に利用できます。

可用性テスト
Application Insights で外部からアプリケーションの応答を定期的に確認する機能です。
Web サイトや API の応答失敗や遅延を検知し、アラートに利用できます。

Container Insights
AKS などのコンテナー環境を監視するための Azure Monitor の機能です。
ノード、Pod、コンテナーのログやパフォーマンス情報を収集し、分析やアラートに利用できます。

Managed Prometheus
Prometheus 形式のメトリックを Azure Monitor ワークスペースに収集するマネージド サービスです。
AKS などのコンテナー環境で、メトリック中心の監視を行う場合に利用します。

診断設定
Azure リソースのプラットフォーム ログやメトリックを送信するための設定です。
Log Analytics ワークスペース、ストレージ アカウント、Event Hubs などを送信先にできます。

Log Analytics ワークスペースのデータ エクスポート機能
Log Analytics ワークスペースに収集されたログを継続的に外部へ送信する機能です。
ストレージ アカウントや Event Hubs にデータを保管、連携したい場合に利用します。

Network Watcher
Azure 仮想ネットワークの接続性や通信経路を診断、監視するためのサービスです。
接続モニターや仮想ネットワーク フロー ログなど、ネットワーク監視に関連する機能を提供します。


データの種類・呼称に関連する用語

Heartbeat ログ
Azure Monitor エージェントが既定で Azure Monitor に定期的に送信するログです。
一定時間 Heartbeat ログが届かないことを条件に、仮想マシンの死活監視を構成できます。

パフォーマンス カウンター
Windows や Linux の OS が持つ CPU、メモリ、ディスクなどの性能値です。
仮想マシン ゲストのパフォーマンス監視で、Log Analytics ワークスペースに収集して分析できます。

アクティビティ ログ
Azure リソースに対する管理操作やサービス正常性イベントを記録するサブスクリプション単位のログです。
誰が、いつ、どのリソースに対して操作したかを確認できます。

プラットフォーム メトリック
Azure リソースから自動的に収集されるメトリックです。
仮想マシンではホスト側の CPU、ディスク、ネットワークなどの状態を追加エージェントなしで確認できます。

カスタム メトリック
利用者やエージェントが任意に送信するメトリックです。
仮想マシンのゲスト OS 内のパフォーマンス情報など、標準のプラットフォーム メトリックでは取得できない値を扱えます。

ゲスト OS メトリック
仮想マシンの OS 内部から収集する CPU、メモリ、ディスクなどのパフォーマンス情報です。
Azure Monitor エージェントとデータ収集ルールを使って収集します。
カスタム メトリックの一種に該当します。

テレメトリ
アプリケーションやサービスから送信される要求、例外、依存関係、トレースなどの監視データです。
Application Insights では、これらのデータをもとに性能分析や障害調査を行います。


データの分析・可視化に関連する用語

Kusto Query Language (KQL)
Log Analytics ワークスペースや Application Insights に収集したログを検索、集計、分析するためのクエリ言語です。
ログ アラート ルールやワークブックで条件判定や可視化を行う際にも利用します。

Log Analytics ワークスペース
Azure Monitor ログを保存し、KQL で検索や分析を行うためのデータ ストアです。
仮想マシン、コンテナー、アプリケーションなど、複数のリソースのログを集約できます。

ストレージ アカウント
Azure のログやメトリックを長期保管するために利用できるストレージ サービスです。
診断設定やデータ エクスポートの送信先として指定できます。

サービス正常性
Azure サービス側の障害、メンテナンス、正常性勧告を確認するための機能です。
利用中のリージョンやサービスに影響するイベントを把握し、通知を構成できます。

リソース正常性
個々の Azure リソースが利用可能な状態かを確認するための機能です。
仮想マシンやストレージ アカウントなど、リソース単位の停止や性能低下の切り分けに利用します。

メトリック エクスプローラー
Azure Monitor メトリック (プラットフォーム メトリック、カスタム メトリック) をグラフで表示し、期間や集計方法を変えて確認するための画面です。
リソースの性能傾向を把握し、メトリック アラートの条件検討にも利用できます。

ワークブック
Azure Monitor のログ、メトリック、テキスト、パラメーターを組み合わせて可視化する機能です。
監視データの分析画面や運用レポートを柔軟に作成できます。

ダッシュボード
Azure ポータル上で複数のリソースや監視グラフをまとめて表示するための画面です。
メトリック、ログ クエリ、ワークブックなどを配置して運用状況を確認できます。

コスト分析
Log Analytics ワークスペースのデータ取り込み量や保存期間を確認し、利用料金を把握する作業です。
テーブルごとのデータ量や課金対象データを確認して、収集設定の見直しに役立てます。


監視・通知に関連する用語

アラート ルール
メトリック、ログ、アクティビティ ログなどの条件を評価し、異常を検知するための機能です。
条件に一致した場合は、アクション グループを通じて通知や自動処理を実行できます。

ログ アラート ルール
Log Analytics ワークスペースや Application Insights の KQL クエリ結果を条件にするアラートです。
ログ内の特定イベント、文字列、集計値などをもとに異常を検知できます。ログ検索アラート ルールとも呼ばれます。

メトリック アラート ルール
Azure Monitor メトリックの値を条件にするアラート ルールです。
CPU 使用率や応答時間など、数値データのしきい値監視に利用します。

アクティビティ ログ アラート
Azure サブスクリプション内の管理操作やサービス正常性イベントを条件にするアラート ルールです。
リソースの作成、削除、停止、障害通知などのイベントを検知・通知できます。

アクション グループ
アラート発生時の通知先や実行するアクションをまとめた設定です。
メール、SMS、Webhook、Azure Functions などへの通知や連携に利用します。


2.1 リタイア済み製品

本項では、Azure Monitor で以前提供していた機能やソリューションのうち 2026 年 7 月 1 日時点で廃止済みまたは非推奨となっているものを記載します。後継機能への移行や対応方法に関する情報をあわせてご紹介しますので、該当する製品を現在もご利用の場合にはご参照ください。なお、本情報は公開情報をもとに Azure Monitor に関連する主なリタイア済み製品を整理したものであり、すべての製品を網羅していることを保証するものではありません。

リタイア日対象機能主な対応
2024 年 2 月 29 日Application Insights クラシック版ワークスペース版 Application Insights へ移行
2024 年 8 月 31 日Log Analytics エージェント (OMS Agent/MMA)Azure Monitor エージェントへ移行
2024 年 8 月 31 日コンテナー監視ソリューションContainer Insights へ移行
2026 年 3 月 31 日Azure Diagnostics 拡張機能 (WAD/LAD)Azure Monitor エージェントへ移行
2026 年 3 月 31 日Log Analytics beta APILog Analytics クエリ API v1 へ移行

Application Insights のクラシック版

2024 年 2 月 29 日に廃止されました。クラシック版 Application Insights リソースは、テレメトリ データを独自のワークスペースに保存していました。ワークスペース版では、Log Analytics ワークスペースにテレメトリ データを保存するため、Log Analytics の機能が使えるようになりました。既にクラシック版リソースへのテレメトリ取り込みは停止されており、廃止後に Application Insights リソースを作成する場合は、必ず 1 つの Log Analytics ワークスペースが必要です。

Application Insights のクラシック リソースをワークスペースベースのリソースに移行する - Azure Monitor | Microsoft Learn
Application Insights クラシック版 (廃止) とワークスペース版との違いについて | Japan Azure Monitoring Support Blog


Log Analytics エージェント (OMS Agent, Microsoft Monitoring Agent/MMA)

2024 年 8 月 31 日に廃止されました。Log Analytics エージェント (OMS/MMA) は、仮想マシンやオンプレミス サーバーからログやパフォーマンス データを収集するために使用されていたレガシー エージェントです。
2026 年 3 月 2 日以降、順次データの収集が停止するため、後継の Azure Monitor エージェントへ移行が必要です。

Log Analytics エージェントから Azure Monitor エージェントへの移行 - Azure Monitor | Microsoft Learn
Log Analytics エージェントから Azure Monitor エージェントへの移行に関するよくあるご質問集 | Japan Azure Monitoring Support Blog
Migrate to Azure Monitor agent–based VM insights by 31 August 2024 について | Japan Azure Monitoring Support Blog


コンテナー監視ソリューション

2024 年 8 月 31 日より非推奨となりました。コンテナー監視ソリューションは、Log Analytics エージェントを利用して Docker や Windows コンテナーのホストとコンテナーを一元的に監視する機能です。後継は Container Insights です。

コンテナー監視ソリューションからコンテナーの分析情報の使用への移行 - Azure Monitor | Microsoft Learn


Azure Diagnostics 拡張機能 (WAD/LAD)

2026 年 3 月 31 日に廃止されました。Azure Diagnostics 拡張機能は、仮想マシンのログやメトリックをストレージ アカウントや Event Hubs に送信する機能です。引き続きログやメトリックを収集する場合は、後継の Azure Monitor エージェントへの移行が必要です。Azure Monitor エージェントは、基本的に Log Analytics ワークスペースへデータを送信します。ストレージ アカウントや Event Hubs にデータを送信する場合は、Log Analytics のデータ エクスポート機能を利用します。

Azure Diagnostic Extensions (WAD/LAD) から Azure Monitor エージェントに移行する - Azure Monitor | Microsoft Learn
Retirement notice ： Migrate to Azure Monitor Agent before 31 March 2026 について | Japan Azure Monitoring Support Blog
Azure Monitor の Log Analytics ワークスペース データ エクスポート - Azure Monitor | Microsoft Learn


Log Analytics beta API

2026 年 3 月 31 日に廃止されました。Log Analytics beta API は、現在公開されている Log Analytics クエリ API のバージョン v1 より前から提供している beta 版の API です。beta API では Log Analytics のクエリが正常に実行できなくなるため、API 呼び出しのパスを beta から v1 に変更する必要があります。

バッチクエリとベータクエリを使用して標準の Log Analytics クエリ API に移行する - Azure Monitor | Microsoft Learn


2.2 リタイア予定の製品

本項では、Azure Monitor で提供している機能やソリューションのうち 2026 年 7 月 1 日時点で今後廃止予定のものを記載しています。本情報は、公開情報をもとに Azure Monitor に関連する主なリタイア予定を整理したものであり、すべての変更を網羅していることを保証するものではありません。また、リタイア日や影響範囲は変更される場合があります。
ご利用の環境がリタイアの影響を受ける場合、原則としてサービス正常性を通じて対象サブスクリプションへ通知される予定です。実際の影響、対応期限、および必要な作業については、Azure ポータル > [モニター (監視)] > [サービスの正常性] > [正常性に関する勧告] に表示される通知を必ずご確認ください。

リタイア予定日対象機能主な対応
2026 年 7 月 31 日Azure Monitor エージェントから Event Hubs／ストレージへ仮想マシンのクライアント データを直接送信する機能 （プレビュー）Log Analytics のデータ エクスポートなど、代替の送信方法へ切り替え
2026 年 9 月 14 日HTTP Data Collector APIDCR ベースのログ インジェスト API へ移行
2026 年 9 月 15 日アクティビティ ログのレガシー転送方式Azure Monitor の診断設定へ移行
2026 年 9 月 30 日Container Insights の ContainerLog テーブルContainerLogV2 テーブルへ移行し、クエリやアラート ルールを更新
2026 年 9 月 30 日Container Insights のレガシー認証マネージド ID 認証へ移行
2026 年 9 月 30 日Application Insights API キーMicrosoft Entra ID 認証へ移行
2026 年 9 月 30 日Application Insights URL Ping テスト（クラシック テスト）標準テストへ移行
2027 年 3 月 31 日Application Insights .NET Classic API SDK 2.xApplication Insights .NET SDK 3.x または Azure Monitor OpenTelemetry Distro へ移行
2028 年 3 月 31 日Log Analytics batch APIバッチ要求を個別の Logs Query API 呼び出しへ変更
2028 年 6 月 30 日VM Insights の Map 機能と Dependency Agentインベントリや変更の追跡には Change Tracking とインベントリを検討し、依存関係の可視化については監視要件に応じた代替手段を検討

仮想マシン クライアント データを Event Hubs とストレージ アカウントに送信する （プレビュー）

2026 年 7 月 31 日に廃止予定です。Azure Monitor エージェントで Event Hubs やストレージ アカウントに仮想マシンのデータを直接送信する機能をプレビューで提供していましたが、廃止までに代替の送信方法 (Log Analytics のデータ エクスポート機能など) への切り替えをご検討ください。

Event Hubs と Storage にデータを送信する (プレビュー) - Azure Monitor | Microsoft Learn
【非推奨】AMA を使用して VM のデータを Event Hub とストレージ アカウントに送信する方法 | Japan Azure Monitoring Support Blog
Azure Monitor の Log Analytics ワークスペース データ エクスポート - Azure Monitor | Microsoft Learn


HTTP Data Collector API

2026 年 9 月 14 日にサポート終了予定です。Data Collector API は、Log Analytics ワークスペースにカスタム ログ データを HTTP 経由で送信するためのレガシー API です。後継のログ インジェスト API では、データ収集ルール (DCR) による取り込み時の変換やフィルタリング、RBAC によるきめ細かなアクセス制御が可能です。サポート終了後も Data Collector API でログを送信できる予定ですが、ログの取り込みに関する処理能力や柔軟性、問題が発生した際のサポートの有無を考慮し、ログ インジェスト API への移行を推奨しております。移行にあたっては、ログ インジェスト API を呼び出すようにスクリプトやアプリケーションの改修が必要です。

HTTP データ コレクター API からログ インジェスト API に移行する - Azure Monitor | Microsoft Learn
Retirement notice ： Transition to DCR-based custom log ingestion by 14 September 2026 について | Japan Azure Monitoring Support Blog


アクティビティ ログのレガシー転送方式

2026 年 9 月 15 日に廃止予定です。アクティビティ ログを Log Analytics ワークスペース、Event Hubs、またはストレージ アカウントへ転送するレガシー方式をご利用されている場合は、廃止期日までに診断設定へ移行をお願いいたします。

従来の収集方法 - Azure Monitor | Microsoft Learn


ContainerLog テーブル

2026 年 9 月 30 日に廃止予定です。ContainerLog テーブルは、Container Insights で使用されてきた旧ログ スキーマです。後継の ContainerLogV2 テーブルでは、ログ エントリの構造化 (LogLevel や ContainerName 等のカラム追加) や複数行のログ取り込みがサポートされています。ContainerLogV2 は、ConfigMap やデータ収集ルール (DCR) で有効化することが可能です。また、既存のクエリやアラート ルールで ContainerLog テーブルを参照している場合は、ContainerLogV2 に合わせた書き換えも必要になります。

Container Insights の ContainerLogV2 スキーマを構成する - Azure Monitor | Microsoft Learn


Container Insights のレガシー認証

2026 年 9 月 30 日にサポート終了予定です。レガシー認証は、証明書と Log Analytics ワークスペース キーを使用して、監視エージェントから Azure Monitor へデータを送信する従来の認証方式です。現在は、より安全なマネージド ID 認証が既定の認証方式となっています。マネージド ID 認証では、クラスターのマネージド ID を使用して Azure Monitor へデータを送信するため、Log Analytics ワークスペース キーを管理する必要がありません。また、Syslog の収集や高スケール モードなど、マネージド ID 認証を前提とする新しい Container Insights の機能も利用できます。
レガシー認証を使用しているクラスターは、廃止日までにマネージド ID 認証へ移行する必要があります。Azure Resource Graph を使用して対象となる AKS クラスターおよび Azure Arc 対応 Kubernetes クラスターを確認できます。移行は Azure ポータルの移行機能に加え、Azure CLI を使用して実施できます。

コンテナーの分析情報のレガシー認証 - Azure Monitor | Microsoft Learn


Application Insights API キー

2026 年 9 月 30 日に廃止予定です。
Application Insights API キーは、api.applicationinsights.io などで Application Insights のテレメトリ データをクエリする際に使用される API キーです。廃止後は API キーによるクエリができなくなるため、Microsoft Entra ID 認証への移行が必要です。
※ 当初案内されていた 2026 年 3 月 31 日から延長されています。

Microsoft Entra ID を使用した Application Insights の認証 - Azure Monitor | Microsoft Learn
Application Insights API キーの廃止と移行について | Japan Azure Monitoring Support Blog


Application Insights URL Ping テスト（クラシック テスト）

2026 年 9 月 30 日に廃止予定です。URL Ping テストは、クラシック テストとも呼ばれ、指定した URL に HTTP リクエストを送信してエンドポイントが応答するかどうかを検証する機能です。後継の標準テストでは、エンドポイントの応答に加え、SSL 証明書の有効性検証や有効期限のチェック、HTTP リクエスト メソッドの指定やカスタム ヘッダーの設定といった機能が追加されています。廃止後は既存の URL Ping テストがリソースから削除されるため、標準テストへの移行が必要です。

Application Insights の可用性テスト - Azure Monitor | Microsoft Learn
Application Insights 可用性テスト の クラシック と 標準 の違いについて | Japan Azure Monitoring Support Blog


Application Insights .NET Classic API SDK 2.x

2027 年 3 月 31 日に廃止予定です。移行先は次のいずれかが挙げられます。

  • Application Insights .NET SDK 3.x
  • Azure Monitor OpenTelemetry Distro

新規アプリケーションでは、Azure Monitor OpenTelemetry Distro が推奨されています。既存の TelemetryClient や Track* 呼び出しへの互換性が必要な場合は、SDK 3.x への移行も検討いただけます。

Application Insights を使用して .NET アプリケーションと Node.js アプリケーションを監視する (クラシック API 2.x) - Azure Monitor | Microsoft Learn
Application Insights クラシック API ソフトウェア開発キット (SDK) を Azure Monitor OpenTelemetry に移行する - Azure Monitor | Microsoft Learn


Log Analytics batch API

2028 年 3 月 31 日に廃止予定です。現在公開されている Log Analytics クエリ API（バージョン v1）に含まれる機能の一つで、複数のクエリをまとめて一回の API 呼び出しで送信します。

廃止後は batch 操作を利用できなくなるため、バッチ要求の requests 配列に含まれている各クエリを分割し、Logs クエリ API の query 操作を個別に実行するよう、アプリケーションやスクリプトを変更する必要があります。Azure SDK のバッチ クエリ メソッドを使用している場合も、個別のクエリ メソッドへ変更する必要があります。

バッチクエリとベータクエリを使用して標準の Log Analytics クエリ API に移行する - Azure Monitor | Microsoft Learn


VM Insights の Map 機能と Dependency Agent

2028 年 6 月 30 日に廃止予定です。VM Insights の Map 機能は、仮想マシン上で動作するプロセスや、TCP 接続によるサーバーや外部サービスへの依存関係をマップとして可視化する機能です。この機能では、Azure Monitor エージェントに加えて Dependency Agent も使用します。

廃止後は、Azure ポータルの VM Insights の Map 機能、マップ データを利用するブック、Dependency Agent によるデータ送信、および Service Map API などが利用できなくなります。

仮想マシン内のソフトウェア、Windows サービス、Linux デーモン、ファイル、Windows レジストリなどのインベントリや変更を把握する用途については、Azure Monitor エージェントを使用する Change Tracking とインベントリが一部の代替となる場合があります。

ただし、Change Tracking とインベントリは、プロセス間の依存関係、TCP 接続、サーバーや外部サービスとの通信関係をマップとして可視化する機能を提供しないため、VM Insights の Map 機能を完全に置き換えるものではありません。これらの依存関係データを引き続き収集する必要がある場合は、現在の利用状況と監視要件を確認し、必要に応じて別の代替手段をご検討ください。

VM Insights Map と Dependency Agent の提供終了に関するガイダンス - Azure Monitor | Microsoft Learn
Azure Monitor エージェントを使用した Azure Change Tracking とインベントリの概要 | Microsoft Learn




3. 概念

ここでは Azure Monitor のソリューション間の関係とデータの流れの概念図を記載します。
図の矢印はデータの流れを示します。




4. 監視シナリオ例

まずは仮想マシンを例に、Azure Monitor での監視方法について記載します。
どのようなデータを利用し、どのような監視を実現することができるか、具体的な例も示しながらご紹介します。
この章を読むことで、Azure Monitor の基本的な監視構成を知ることができます。


4.1 仮想マシンの死活監視

本項では Azure VM が期待どおり稼働しているかを確認し、VM の停止や OS からの応答を検知する死活監視について記載します。
Azure Monitor における Azure VM の死活監視では、Azure 基盤側とゲスト OS 側の 2 つのレイヤーがあり、レイヤーごとに監視対象や方法が異なります。

■ Azure 基盤側の監視
VM の可用性メトリックやリソース正常性の監視を死活監視に利用する方法です。
VM の可用性メトリック (VM Availability Metric) は Azure 基盤側のメトリック情報であり、VM の利用状況を示します。
メトリックの値が 1 の場合は VM が実行中で利用可能な状態です。VM のシャットダウンや再起動を行った場合は、値が 0 となります。

※ VM の可用性メトリックを表示した例

Azure 基盤側のメトリックは、可用性だけでなく CPU 使用率等のパフォーマンス データについても確認することが可能ですが、この点については次項でご紹介します。

リソース正常性は Azure 基盤側から対象のリソースに何らかの問題が起きている場合に知らせる機能であり、この情報をもとに監視を行います。リソース正常性については、本記事 5.2.5 サービス正常性アラートとリソース正常性アラート をご参照ください。


■ Azure VM の OS 側の監視
Azure VM のゲスト OS 内で動作するエージェントが収集する、Heartbeat ログや OS のメトリックを監視する方法です。
Heartbeat ログの収集状況から、一定時間ログが届かない場合にはエージェントの停止やネットワークの異常等の問題が発生している可能性を検知することが可能です。

ワークブックを利用すると、複数の VM の稼働状態や Heartbeat ログの有無を一覧で視覚化することもできます。
ワークブックについては、本記事 5.3 可視化 をご参照ください。

※ Heartbeat ログの収集状況をワークブックで可視化した例

また、Azure 基盤側と OS 側を問わず、前述したシグナルはアラート ルールの条件として設定し、メール通知することもできます。
アラート ルールについては、本記事 4.6 アラート ルールの設定 をご参照ください。

これらの監視方法を組み合わせることで、より信頼性の高い死活監視を構成することが可能です。
Azure VM の死活監視の詳細については、以下のブログをご参照ください。
Azure VM における死活監視の考え方 | Japan Azure Monitoring Support Blog


4.2 仮想マシン ホストのパフォーマンス監視

前項 4.1 仮想マシンの死活監視 で紹介した Azure 基盤側のメトリック情報を利用して、Azure VM のパフォーマンス監視を行うことができます。

※ Azure VM の CPU とメモリの使用率を表示した例

Azure 基盤側で収集されるメトリックはプラットフォーム メトリックと呼ばれます。
プラットフォーム メトリックは Azure 基盤上のハイパーバイザー層から自動的に収集されるため、Azure VM の作成後に追加構成を行うことなく利用できる点が大きな特徴です。
このため、お客様の要件によりゲスト OS にエージェントをインストールできない場合にも有用です。

Azure VM でサポートされているプラットフォーム メトリックの一覧は以下の公開情報をご参照ください。
サポートされているメトリック - Microsoft.Compute/virtualMachines - Azure Monitor | Microsoft Learn

プラットフォーム メトリックは Azure 基盤側から見える CPU、メモリ、ディスク I/O、ネットワークなどの監視に向いています。
例えば Windows OS 内の C ドライブの空き容量を監視したい、といった場合には、各ドライブの空き容量を示すメトリックがプラットフォーム メトリックとして提供されていないため、このシナリオではプラットフォーム メトリックを利用した監視は適しません。

サポートされていないメトリックやより詳細なゲスト OS の情報を監視したい場合には、ゲスト OS 内のエージェントが収集するゲスト OS メトリックやログを利用します。
プラットフォーム メトリックは Azure ポータルの監視画面での確認や、本記事 4.6 アラート ルールの設定 で紹介するアラート ルールを設定することで、特定の条件に一致した場合に利用者へ通知を行うこともできます。


4.3 Azure VM のゲスト OS のパフォーマンス監視

前項 4.2 仮想マシン ホストのパフォーマンス監視 で紹介した Azure VM のプラットフォーム メトリックでは取得できないゲスト OS 内部の詳細なパフォーマンス情報を監視したい場合は、エージェントが収集するゲスト OS のパフォーマンス情報 (ゲスト OS メトリック) を利用して監視を行います。

Azure Monitor エージェント (AMA) と呼ばれるエージェントをゲスト OS にインストールする必要がありますが、Windows の Perfmon で確認できるパフォーマンス カウンターや、Linux OS 内の特定のパフォーマンス カウンターのデータを収集することができます。

Azure VM のプラットフォーム メトリックの場合と同様に、収集した情報は Azure ポータルの監視画面での確認や、アラート ルールによる監視と通知に利用できます。

※ Windows のパフォーマンス カウンター情報を AMA により収集した例


■ プラットフォーム メトリックとゲスト OS メトリックの違い

プラットフォーム メトリックゲスト OS メトリック
データ ソースAzure ハイパーバイザー層で収集される Azure 基盤側のメトリックゲスト OS 内のパフォーマンス カウンターやパフォーマンス データ
収集方法Azure VM の作成後に自動で収集OS にインストールしたエージェントが収集
ゲスト OS へのエージェント インストール不要必要
向いている監視要件VM 全体の CPU、メモリ、ディスク I/O、ネットワークなどを追加構成なしで監視したい場合OS 内のドライブ空き容量、プロセス、アプリケーション固有のパフォーマンス カウンターなどを監視したい場合

例えば以下のようなシナリオではゲスト OS のパフォーマンス監視が有用です。
Azure 基盤側から VM 全体の状態をプラットフォーム メトリックで確認し、さらに OS 内部の詳細な状態や追加で必要な情報をゲスト OS メトリックを利用する、というように監視要件に応じて使い分けたり組み合わせて利用します。

シナリオ利用するデータ例
Windows OS 内の C ドライブの空き容量を監視したい\LogicalDisk(C:)\% Free Space などプラットフォーム メトリックにはドライブ単位の空き容量を示すメトリックがないため、OS 内のパフォーマンス カウンターを収集します。
SQL Server の詳細な性能を監視したい\SQLServer:Buffer Manager\Checkpoint pages/sec、\SQLServer:SQL Statistics\Batch Requests/sec などSQL Server が公開する Perfmon カウンターを収集することで、アプリケーションやミドルウェア固有の性能値を監視できます。
特定プロセスの CPU やメモリ使用量を監視したい\Process(*)\% Processor Time、\Process(*)\Working Set などVM 全体ではなく、OS 内のプロセス単位で負荷を確認したい場合に利用します。

※ SQL Server のパフォーマンス カウンター情報を AMA により収集した例


4.4 仮想マシン ログの監視

前項 4.3 Azure VM のゲスト OS のパフォーマンス監視 で触れた Azure Monitor エージェント (AMA) を利用することで、ゲスト OS のログ情報を収集し、監視することも可能です。

※ Windows OS の C ドライブの空き容量の情報をログとして収集した例

AMA によりゲスト OS の各情報をログとして Log Analytics ワークスペースと呼ばれる Azure 上のデータ ストアに収集し、クエリ言語である KQL により検索します。また、ログ アラート ルールでクエリ検索結果をもとにアラートを構成し、監視を行うことができます。ログ アラート ルールについては、本記事 5.2.2 ログ アラート ルールをご参照ください。

ゲスト OS のログを収集することで、例えば以下のようなシナリオに対応できます。

  • Windows イベント ログに特定のイベント ID のログが出力された場合に通知する
  • Linux の Syslog に特定の Facility のログが出力された場合に通知する
  • アプリケーションが出力するテキスト ログに ERROR や Failed などの任意の文字列が出力された場合に通知する
  • 同じエラー ログが一定時間内に複数回出力された場合のみ通知する
  • 複数の VM から収集したログをクエリにより検索し同じエラーが複数台で発生していないか確認する
  • パフォーマンス情報をログとして収集し複数の VM をまとめて監視する

このように、ログ監視は KQL により条件を記載することで様々な要件に対応することができます。
AMA により収集可能なログ種については、本記事 5.1.3 仮想マシンからのログ収集をご参照ください。


4.5 OS 内のサービス監視

変更履歴とインベントリ機能を有効化することで、OS 内のサービス状態を監視することができます。

※ Windows Update サービスが停止状態であることを示すログを抽出した例

変更履歴とインベントリ機能も、Azure Monitor エージェント (AMA) を利用して情報を Log Analytics ワークスペースに収集します。
Windows サービスや Linux デーモンの状態、構成変更などをログとして確認できるため、ログ アラート ルールを利用することで、特定のサービスが停止状態となった場合に通知を行う等の構成が可能です。

例えば、サービス監視では以下のようなシナリオに対応できます。

  • Azure VM 上の Web サーバーやデータベースなど、業務上重要なサービスが停止した場合に通知する
  • サービスのスタートアップの種類が自動から手動や無効に変更された場合に検知する
  • パッチ適用やアプリケーション更新後に、想定外のサービス停止や状態変更が発生していないか確認する
  • 複数の VM で同じサービスの状態を横断的に確認し停止している VM を特定する

また、変更履歴とインベントリ機能はサービス監視だけでなく、OS 内の構成変更を確認する用途でも利用できます。
例えば、インストール済みソフトウェアの追加や削除、ファイルの変更、Windows のレジストリ キーの変更などを追跡できます。
これにより、監査やガバナンスの向上を目的として構成変更がないかを確認したり、意図しない変更を検知したりすることができます。障害対応においても、例えば事象発生時における構成変更の有無を確認することに利用できます。

Azure Monitor エージェントを使用した Azure Change Tracking とインベントリの概要 | Microsoft Learn
ConfigurationData のログ テーブル クエリの例 - Azure Monitor | Microsoft Learn


4.6 アラート ルールの設定

Azure Monitor には、各種 Azure サービスやリソースを監視する機能があり、異常を検知した際にメールや SMS などの通知や自動アクションを実行できます。

■ アラート ルール
各種 Azure サービスやリソースを監視する機能の総称です。監視対象のデータ（メトリックやログ、アクティビティ ログなど）や監視条件を決め、異常を検知します。監視するデータの種類によってアラート ルールの種類が異なります。

アラート ルールの種類概要
ログ アラート ルールLog Analytics ワークスペースに収集されたログや、Azure Resource Graph や Azure Data Explorer のデータを監視
メトリック アラート ルールAzure リソースのパフォーマンスや状態を示すプラットフォーム メトリックやカスタム メトリックを監視
アクティビティ ログ アラートAzure のアクティビティ ログを監視 （サービス正常性アラートやリソース正常性アラートも含む）

以下はログ アラート ルールの条件を指定する画面の例です。

以下は メトリック アラート ルールの条件を指定する画面の例です。

以下はアクティビティ ログ アラート の条件を指定する画面の例です。


■ アクション グループ
アラートが発報した際の通知方法や実行する自動アクションを設定する機能です。
アラート ルールにアクション グループを関連付けることで、アラートが発報した際にアクション グループがトリガーされ、メールや電話、SMS で通知したり、Webhook などの自動アクションを実行することが可能です。

アクション グループには「共通アラート スキーマ」という設定項目があります。アラート スキーマとはアラートが発生した際に生成される通知データの構造であり、共通アラート スキーマ / 非共通アラート スキーマの 2 種類があります。

共通アラート スキーマは、Azure Monitor のすべてのアラート ルールで統一されたスキーマが提供されます。一方、非共通アラート スキーマでは、アラート ルールの種類ごとに個別に定義された構造となります。アクション グループで Logic Apps や Webhook などの自動アクションを設定する場合、共通アラート スキーマの有効／無効によって連携されるデータ構造が異なるためご留意ください。

また、共通アラート スキーマの設定により、通知メールのフォーマットも変わります。本記事 5.2 分析とレポート では、共通アラート スキーマを有効化した場合の通知メールの例をご紹介しています。非共通アラート スキーマのメール フォーマットを確認されたい場合は、テスト アクション グループにてご確認ください。

アラート ルールの種類やアクション グループの詳細は、以下の公開情報をご参照ください。
Azure Monitor の警告の概要 - Azure Monitor | Microsoft Learn
Azure Monitor アラートの種類 - Azure Monitor | Microsoft Learn
Azure Monitor でアクション グループを作成および管理する - Azure Monitor | Microsoft Learn


4.7 サービス正常性

サービス正常性は、Azure サービス正常性のイベント（サービスに関する問題、計画メンテナンス、正常性の勧告、セキュリティ アドバイザリ、課金情報の更新）の情報を提供する機能です。ご利用いただいている Azure サービスおよびリージョンに影響がある正常性イベントが発生すると、Azure ポータル > [モニター (監視)] > [サービスの正常性] に情報が表示されます。

各イベントには一意の追跡 ID が付与されます。上記画面で各イベントのリンクをクリックすると、より詳細な情報を確認することができます。また、サービス正常性アラートを設定すると、サービス正常性のイベントが発生した際に通知を受け取ることも可能です。サービス正常性アラートについては、本記事 5.2.5 サービス正常性アラートとリソース正常性アラート をご参照ください。

サービス正常性の概要は、以下の公開情報をご参照ください。
Azure Service Health のドキュメント - Azure Service Health | Microsoft Learn
Azure Service Health 通知の概要 - Azure Service Health | Microsoft Learn




5. 各機能とソリューション

ここでは、Azure Monitor の代表的な機能やソリューションについて記載します。
本章を読むことで、監視データの取得、分析、可視化の方法と作業の流れを知ることができます。


5.1 データ収集

本項では、監視に利用するデータの種類とその取得方法をご紹介します。


5.1.1 プラットフォーム メトリックとカスタム メトリック

Azure で扱われるメトリックには以下の 3 種類があります。

  • プラットフォーム メトリック
  • カスタム メトリック
  • Prometheus メトリック (本項ではこちらの説明は割愛します)

■ プラットフォーム メトリックとは
プラットフォーム メトリックとは、各 Azure リソースから既定で (ユーザーによる追加構成を必要とせず) 収集されるメトリックで、主に Azure リソースの正常性やパフォーマンスを示すデータです。プラットフォーム メトリックの収集・保持に費用はかかりません。Azure ポータル > 対象の Azure リソース > [監視] > [メトリック] のページ (メトリック エクスプローラー) で確認ができます。

どのようなメトリックが収集できるかは Azure リソースの種類によって異なります。
各種リソースでどのようなメトリックが収集されるかは、以下の公開情報の表内のリンクから確認いただけます。
Azure Monitor supported metrics by resource type - Azure Monitor | Microsoft Learn


■ カスタム メトリックとは
カスタム メトリックとはユーザーが収集を構成することで収集されるメトリックです。
例えば、Azure Monitor エージェントによって仮想マシンのゲスト OS から収集されるメトリック（ゲスト OS メトリック）や、Application Insights によって Web アプリケーションから収集されるメトリックはカスタム メトリックとして扱われます。カスタム メトリックも、プラットフォーム メトリックと同様に Azure ポータル > 対象の Azure リソース > [監視] > [メトリック] から確認できます。

カスタム メトリックの収集にかかる費用や各種メトリックの詳細な説明は、以下の公開情報をご参照ください。
価格 - Azure Monitor [メトリック] タブ | Microsoft Azure
Azure Monitor のメトリック - Azure Monitor | Microsoft Learn


5.1.2 アクティビティ ログ

アクティビティ ログには各 Azure リソースの操作等のログ、サービス正常性、リソース正常性があります。

■ アクティビティ ログ (操作等のログ)
Azure ポータル > [モニター (監視)] > [アクティビティ ログ] にてサブスクリプション内の Azure リソースに対して実行された操作等のログの一覧を確認できます。

既定ではアクティビティ ログの保持期間は 90 日間です。
90 日以上さかのぼって確認するためには、上図の [診断設定] からサブスクリプション スコープで診断設定を作成します。

Azure Monitor アクティビティ ログ - Azure Monitor | Microsoft Learn
Azure Monitor の各種データの保持期間について | Japan Azure Monitoring Support Blog


■ サービス正常性
サービス正常性ではご利用の Azure サービスの障害や計画メンテナンス、サービスの廃止などのイベントについて表示します。
Azure ポータル > [モニター (監視)] > [サービスの正常性] > [有効なイベント] もしくは [履歴] をクリックして確認します。
[有効なイベント] には現時点でアクティブなサービス正常性が表示され、[履歴] には過去のサービス正常性イベントが表示されます。

Azure Service Health ポータル - Azure Service Health | Microsoft Learn


■ リソース正常性
リソース正常性では、ご利用の Azure リソースが正常であるかどうかを評価し、リソースの状態が [利用可能 (Available)]、[使用不可 (Unavailable)]、[不明 (Unknown)]、[低下 (Degraded)] のいずれかの状態と表示します。
Azure ポータル > [モニター (監視)] > [サービスの正常性] > [リソース正常性] にて、確認したいリソースの種類を指定して確認します。

Azure Resource Health の概要 - Azure Service Health | Microsoft Learn.


5.1.3 仮想マシンからのログ収集

■ Azure Monitor エージェント (AMA) とデータ収集ルール (DCR) とは
Azure 仮想マシン (Azure VM) からログを収集するための主な手段は、Azure Monitor エージェントとデータ収集ルールを使用する方法です。それぞれを一言で表現すると、Azure Monitor エージェント (AMA) とは VM 上でデータを集めて送信するもので、データ収集ルール (DCR) とは AMA が収集するデータとその送信先を指定するものです。


■ Azure Monitor エージェント (AMA) とデータ収集ルールによるログ収集の流れ
ログ収集を構成してからログが閲覧できるようになるまでの大まかな流れは以下のとおりです。

  • AMA を VM にインストールする、VM と DCR を関連付ける
    ↓
  • 関連付けられた DCR の内容を AMA が認識する
    ↓
  • AMA が DCR で指定されたログを指定された宛先に送信する
    ↓
  • 送信されたログが Azure 基盤側に到着し、処理され、指定の宛先に格納される
    ↓
  • Azure ポータル等でログが閲覧できるようになる

■ Azure Monitor エージェント (AMA) とデータ収集ルール (DCR) で収集できるデータの種類
上記のとおり、収集したいログと送信先に応じて DCR を作成し、VM に関連付ける必要があります。
AMA と DCR を使用して収集できるデータの種類と、指定できる収集先は以下のとおりです。

データ ソース説明オペレーティング システム収集先
Windows イベントWindows イベント ログ システムによって出力される情報WindowsLog Analytics ワークスペース (Event テーブル)
パフォーマンス カウンターオペレーティング システムとワークロードのパフォーマンスを測定する数値Windows, LinuxLog Analytics ワークスペース (Perf テーブル), Azure Monitor メトリック（プレビュー）
SyslogLinux イベント ログ システムによって出力される情報LinuxLog Analytics ワークスペース (Syslog テーブル)
テキスト ログローカル ディスクのテキスト ログ ファイルに出力される情報Windows, LinuxLog Analytics ワークスペース (任意のカスタム テーブル)
JSON ログローカル ディスクの JSON ログ ファイルに出力される情報Windows, LinuxLog Analytics ワークスペース (任意のカスタム テーブル)
IIS ログインターネット インフォメーション サービス (IIS) によりローカル ディスク上のファイルに出力される情報WindowsLog Analytics ワークスペース (W3CIISLog テーブル)

Log Analytics ワークスペースに収集されたログはワークスペース内の特定のテーブル内に格納されます。
テーブルについては以下の公開情報をご参照ください。
Log Analytics ワークスペースの概要 - Azure Monitor | Microsoft Learn


■ Azure Monitor エージェント (AMA) とデータ収集ルール (DCR) によるログ収集を構成する
AMA と DCR を使用してログ収集を行う場合、収集するデータ ソースの種類に関わらず、以下の前提条件を満たしているかご確認ください。

  • OS がサポートされているか
  • ネットワーク要件を満たしているか
  • 十分なディスク領域が確保されているか

Azure Monitor エージェントのネットワーク構成 - Azure Monitor | Microsoft Learn
Azure Monitor エージェントでサポートされるオペレーティング システム - Azure Monitor | Microsoft Learn
Azure Monitor エージェントの要件 - Azure Monitor | Microsoft Learn

前提条件が確認できたら、次に DCR の作成を行います。
それぞれの作業は、Azure ポータル、コマンドライン (Azure CLI, Azure PowerShell)、ARM テンプレート等を使用して実施できます。
ここでは、Azure ポータルを使用した方法について具体的にご紹介します。

Azure ポータルでの DCR の作成方法や、DCR と VM を関連付ける方法は以下の公開情報をご参照ください。
なお、Azure ポータルで DCR を関連付けた場合、(VM に AMA が未インストールの場合は) AMA のインストールも自動で実施されます。
Azure Monitor を使用して仮想マシンからログ データを収集する - Azure Monitor | Microsoft Learn
Azure Monitor でデータ収集ルールの関連付けを管理する - Azure Monitor | Microsoft Learn

Azure ポータル以外の方法で DCR を作成する方法、および DCR と VM を関連付ける方法については以下の公開情報をご参照ください。
Azure Monitor でデータ収集ルール (DCR) を作成する - Azure Monitor | Microsoft Learn
Azure Monitor でデータ収集ルールの関連付けを管理する - Azure Monitor | Microsoft Learn

Log Analytics ワークスペースに収集された各種ログは、KQL を使用してクエリすることで確認が可能です。
例えば、パフォーマンス カウンターを収集した場合、そのログは Perf テーブルに収集されるため、以下のようなクエリ結果が得られます。

はじめてクエリを実施される方は、以下の公開情報をご参照ください。
Azure Monitor ログでログ クエリの使用を開始する - Azure Monitor | Microsoft Learn
Azure Monitor の Log Analytics の概要 - Azure Monitor | Microsoft Learn


■ Azure Monitor エージェント (AMA) の管理
AMA を VM にインストールする方法として、Azure PowerShell および Azure CLI コマンドを使用する方法や、ARM テンプレートを使用する方法もございます。AMA のアンインストールも、インストールと同様に、Azure ポータル, Azure PowerShell や Azure CLI, ARM テンプレートを使用した方法で実施できます。
Azure Monitor エージェントのインストールと管理 - Azure Monitor | Microsoft Learn

AMA の自動アップグレードを有効化することで、最新バージョンが利用可能となった場合に、自動でアップグレードを適用するように構成することが可能です。自動アップグレードの有効化は、インストール時・インストール後のどちらでも設定できます。
Azure の仮想マシンとスケール セットの拡張機能の自動アップグレード - Azure Monitor | Microsoft Learn

AMA の自動アップグレード機能に関するよくあるご質問については以下のブログをご参照ください。
Azure Monitor エージェントの自動アップグレード機能に関するよくあるご質問集 | Japan Azure Monitoring Support Blog


5.1.4 コンテナーからのログ収集

AKS などのコンテナー環境の、ノード、Pod、コンテナー、Kubernetes イベント、アプリケーションの状態を継続的に監視するための機能がいくつか提供されています。主な使い分けとしては、ログや Kubernetes イベントの確認には Container Insights、Prometheus 形式のメトリック監視には Managed Prometheus を使用します。

  1. Container Insights: コンテナー ログ、Kubernetes イベント、インベントリ情報などを Log Analytics ワークスペースに収集するログ収集機能
  2. Managed Prometheus (Azure Monitor managed service for Prometheus) : Prometheus 形式のメトリックを Azure Monitor ワークスペースに収集するメトリック収集機能

Azure Monitor での Kubernetes の監視 - Azure Monitor | Microsoft Learn


1. Container Insights について
Container Insights は Azure Kubernetes Service (AKS) などのコンテナー環境から、コンテナー ログ、Kubernetes イベント、インベントリ情報などを収集し、Azure ポータルや Log Analytics で確認できるログ収集機能です。

ノード、Pod、コンテナーなどの状態やイベントを確認し、必要に応じて Log Analytics の KQL クエリや Azure Monitor のアラートを用いた調査・監視を行うことが可能です。以下は、AKS リソースの [モニター (分析情報)] で [Log Analytics の視覚化（クラシック）] を選択し、収集されたログ情報を確認している例です。


■ Container Insights によるデータ収集の流れ
Container Insights の構成とデータ収集を行う基本的な流れは以下のとおりです。

  • Azure ポータルもしくは Azure CLI 等により対象クラスターで Container Insights を有効化する
    ↓
  • コンテナー化された Azure Monitor エージェント (AMA) がデプロイされる
    ↓
  • コンテナー化された AMA により Log Analytics ワークスペースに各ログ データが収集される
    ↓
  • Azure ポータル > 対象のクラスター リソース > [モニター (分析情報)] の画面や、Log Analytics の KQL により分析や可視化を行う

Container Insights の有効化方法については以下の公開情報やブログをご参照ください。
Azure Kubernetes Service (AKS) クラスターの監視を有効にする - Azure Monitor | Microsoft Learn
Container Insights のご紹介 | Japan Azure Monitoring Support Blog


■ Container Insights で収集されるログ
Container Insights で収集される主なログには、コンテナーの標準出力 / 標準エラー出力、Kubernetes イベント、Pod やコンテナーのインベントリ情報などがあります。収集されたログは Log Analytics ワークスペースに保存され、Azure ポータル > 対象の AKS リソース > [モニター (分析情報)] の画面や Log Analytics の KQL クエリから確認できます。

Log Analytics では、用途に応じて複数のテーブルにデータが格納されます。
例えば、コンテナーの標準出力 / 標準エラー出力は主に ContainerLogV2 テーブルに格納され、Kubernetes イベントは KubeEvents、Pod の状態やインベントリ情報は KubePodInventory で確認できます。

Container Insights に関連するテーブルの一覧や各テーブルの詳細については、以下の公開情報で、ソリューションが ContainerInsights と記載されているテーブルをご確認ください。
microsoft.containerservice/managedclusters の Azure Monitor テーブル - Azure Monitor | Microsoft Learn


2. Managed Prometheus について
Managed Prometheus では、Prometheus 形式のメトリックを Azure Monitor ワークスペースに収集します。収集したメトリックは、Azure Monitor ワークスペースのメトリック エクスプローラーや Prometheus エクスプローラー、Azure Managed Grafana などから、PromQL により分析・可視化できます。

以下は、AKS リソースの [モニター (分析情報)] で [マネージド Prometheus の視覚化] を選択し、収集されたメトリック情報を確認している例です。


■ Managed Prometheus によるデータ収集の流れ
Managed Prometheus の構成とデータ収集を行う基本的な流れは以下のとおりです。

  • Azure ポータルもしくは Azure CLI 等により対象クラスターで Managed Prometheus を有効化する
    ↓
  • Azure Monitor Agent のメトリック アドオンが構成される
    ↓
  • メトリック アドオンにより Prometheus 形式のメトリックが Azure Monitor ワークスペースに収集される
    ↓
  • Azure ポータル > 対象のクラスター リソース > [モニター (分析情報)] の画面や、Azure Monitor ワークスペースのメトリック エクスプローラーなどから PromQL を用いて分析や可視化を行う

Prometheus メトリックの有効化方法については以下の公開情報をご参照ください。
Azure Kubernetes Service (AKS) クラスターの監視を有効にする - Azure Monitor | Microsoft Learn


■ Managed Prometheus で収集されるメトリック
Managed Prometheus で既定収集される Prometheus メトリックには、kubelet、cAdvisor、kube-state-metrics、node exporter などから取得されるノード、Pod、コンテナー、Kubernetes オブジェクトのメトリックが含まれます。

収集対象の詳細は、以下の Azure Monitor の既定 Prometheus メトリック構成に記載されています。
Azure Monitor での既定の Prometheus メトリック構成 - Azure Monitor | Microsoft Learn

Arc 対応 Kubernetes クラスターでの Container Insights によるログ収集、および Managed Prometheus による Prometheus メトリック収集の有効化手順については、以下の公開情報をご参照ください。
Arc 対応 Kubernetes クラスターの監視を有効にする - Azure Monitor | Microsoft Learn


5.1.5 アプリケーションからのログ収集

Application Insights は、アプリケーションのパフォーマンスを監視するサービスです。
Web アプリや API が

  • 正常に動いているか
  • エラーが発生していないか
  • レスポンスが遅くなっていないか

といったことを、Application Insights を有効化することで、自動的にデータを収集し可視化できます。

収集したデータは下図のように Azure ポータルの画面ですぐに閲覧できます。
前述の
「正常に動いているか」は [有効] グラフ (右側の緑色グラフ)、
「エラーが発生していないか」は [失敗した要求] グラフ (左側の赤色グラフ)、
「レスポンスが遅くなっていないか」は [サーバー応答時間] グラフ (左側の青色グラフ)
にて確認できます。

収集したデータの分析方法および可視化方法の詳細は、
本記事 5.2.8 Application Insights のクエリ と 5.3.4 Application Insights の可視化 をご参照ください。

また、Azure App Service や Azure VM などの Azure サービスに加えて、オンプレミスのサーバーで動作するアプリケーションからもログを収集できます。Application Insights の詳細については、以下の公開情報をご参照ください。
Application Insights OpenTelemetry の可観測性の概要 - Azure Monitor | Microsoft Learn


アプリケーションで Application Insights を有効化する方法は 2 つあります。

■ 自動インストルメンテーション
自動インストルメンテーションはソース コードの変更なしで、Application Insights を有効にできます。
手動インストルメンテーションと比較して、簡単に有効化できる一方で一部の機能が制限されます。

自動インストルメンテーションを利用できるシナリオは以下の公開情報をご参照ください。
Azure Monitor Application Insights の自動インストルメンテーション - Azure Monitor | Microsoft Learn

例えば、Azure App Service では Azure ポータル > 対象の App Service > [監視] > [Application Insights] から自動インストルメンテーションを有効化します。


■ 手動インストルメンテーション
アプリケーションのソース コードに Application Insights SDK (クラシックまたは Azure Monitor OpenTelemetry Distro) をインストールして、Application Insights を有効にします。ソース コードの変更は必要ですが、自動インストルメンテーションより多くの情報を取得でき、カスタム テレメトリの収集も可能です。

利用方法はアプリケーションの開発言語ごとに異なるため、詳細は以下の公開情報をご参照ください。
Application Insights で OpenTelemetry を有効にする - Azure Monitor | Microsoft Learn
Application Insights を使用して .NET アプリケーションと Node.js アプリケーションを監視する (クラシック API) - Azure Monitor | Microsoft Learn

また、Application Insights の可用性テストを使って、アプリケーションの死活監視も可能です。
可用性テストでは、世界中のさまざまな場所から Web リクエストをアプリケーションに定期的に送信します。
アラート ルールの設定も可能で、アプリケーションの応答がない場合や応答が遅い場合はユーザーに警告も可能です。

可用性テストは Azure ポータル > 対象の Application Insights > [調査] > [有効] から設定と結果の確認ができます。

詳細な利用方法は、以下の公開情報をご参照ください。
Application Insights 可用性テスト - Azure Monitor | Microsoft Learn


5.1.6 診断設定

■ 診断設定とは
診断設定を使用することで、各 Azure リソースから出力される以下のデータを指定した宛先に送信することができます。

  • アクティビティ ログ
  • リソース ログ
  • プラットフォーム メトリック

宛先には、以下を指定することが可能です。

  • Log Analytics ワークスペース
  • ストレージ アカウント
  • Event Hubs
  • Azure Monitor パートナー ソリューション

■ 診断設定の主な利用シナリオ
リソース ログは既定では収集されません。
そのため、リソース ログを収集し監視や分析を行う必要がある場合は診断設定をご利用ください。

アクティビティ ログおよびプラットフォーム メトリックは既定で収集されます。
ただし、そのままではそれぞれを監視したり分析したりする方法は限られています。診断設定を利用することで、Log Analytics ワークスペース、ストレージ アカウント、Event Hubs などの宛先にデータを送信し、監視、分析、長期保管、外部連携といった用途に活用できます。

また、既定で収集されるアクティビティ ログおよびプラットフォーム メトリックの保持期間はそれぞれ 90 日と 93 日です。
診断設定を用いて任意の宛先に収集することで、この保持期間を延長することが可能です。

プラットフォーム メトリックとアクティビティ ログについては、本記事 5.1.1 プラットフォーム メトリックとカスタム メトリック と 5.1.2 アクティビティ ログ をご参照ください。


■ 診断設定の作成方法 (リソース ログ・プラットフォーム メトリック)
診断設定は Azure ポータル上、Azure PowerShell や Azure CLI のコマンド、ARM テンプレートなどを用いて作成することが可能です。Azure ポータル上での作成方法としては、大きく Azure リソースのページから行う方法と、[モニター (監視)] のページから行う方法があります。ここでは、Azure ポータル > 対象の Azure リソース > [監視] > [診断設定] からの作成方法をご紹介します。

Azure ポータル > 対象の Azure リソース > [監視] > [診断設定] > [診断設定を追加] をクリックすると、以下のような作成画面が表示されます。画像のように、収集対象のデータ (ログおよびメトリック) と宛先を選択することが可能です。

※ Web App リソースの診断設定作成画面

なお、ログはカテゴリ単位で選択することが可能ですが、このカテゴリについてはリソースの種類によって異なります。
また、メトリックについても、どのような種類のメトリックが収集されるかは、リソースの種類によって異なります。
各種リソースからどのようなログおよびメトリックが収集されるかは、以下の公開情報の表内のリンクから確認いただけます。
Supported Resource log categories for Azure Monitor - Azure Monitor | Microsoft Learn


Log Analytics ワークスペースに収集した場合は以下のように確認が可能です。

※ Log Analytics ワークスペースの AzureDiagnostics テーブルにクエリしたときのサンプル

リソース ログは Log Analytics ワークスペースの AzureDiagnostics テーブルに収集されます。
ただし、一部のリソース種では設定によりリソース固有のテーブルに収集することも可能です。

※ Event Hubs のリソース固有テーブルへクエリしたときの例

リソース ログのテーブルの詳細は以下の公開情報をご参照ください。
Azure Monitor のリソース ログ - Azure Monitor | Microsoft Learn
Azure リソース ログでサポートされているサービスとスキーマ - Azure Monitor | Microsoft Learn


■ 診断設定の作成方法 (アクティビティ ログ)
アクティビティ ログ用の診断設定はサブスクリプションのスコープでのみ作成が可能です。
そのため、リソース ログ用の診断設定のように対象リソースの画面から診断設定を作成するのではなく、Azure ポータル > サブスクリプション > [アクティビティ ログ] > [診断設定] から作成します。

例えば、Log Analytics ワークスペースに送信した場合は、AzureActivity テーブルに収集され、ストレージ アカウントに送信した場合は以下の形式の JSON にログが収集されます。
insights-activity-logs/resourceId=/SUBSCRIPTIONS/{subscription ID}/y={four-digit numeric year}/m={two-digit numeric month}/d={two-digit numeric day}/h={two-digit 24-hour clock hour}/m=00/PT1H.json

※ Log Analytics ワークスペースの AzureActivity テーブルにクエリしたときの例

※ ストレージ アカウントにエクスポートされたアクティビティ ログの例

アクティビティ ログ用の診断設定の詳細については以下の公開情報をご参照ください。
Azure Monitor のアクティビティ ログ | アクティビティ ログのエクスポート - Azure Monitor | Microsoft Learn


5.1.7 データ エクスポート

■ データ エクスポートとは
Log Analytics ワークスペースのデータ エクスポート機能を使用することで、Log Analytics ワークスペースのテーブルに格納されるログを他の宛先 (ストレージ アカウントまたは Event Hubs) にエクスポートすることが可能です。データ エクスポート ルールを作成し、その中で対象となるテーブルと宛先を指定します。

データ エクスポート ルールを作成すると、対象のデータが Azure Monitor のパイプラインに到着次第、Log Analytics ワークスペースのテーブルに取り込まれるのと並行して、指定した宛先へのエクスポートが実施されます。


■ データ エクスポート機能の主な利用シナリオ - ストレージ アカウント

改ざん防止に関するコンプライアンス
Log Analytics ワークスペースに取り込まれたデータを変更することはできません。しかし、以下の手順で消去することは可能です。
一方で、不変ポリシーが設定されたストレージ アカウントに格納されたデータは、設定した保持期間を超えるまでは変更、削除いずれもできません。そのため、データの改ざん (消去) 防止の要件がある場合は、不変ポリシーが設定されたストレージ アカウントにエクスポートすることをご検討ください。
Log Analytics ワークスペースのデータを削除する方法 | Japan Azure Monitoring Support Blog

データの冗長化および長期保管
監査データやセキュリティ データ等、冗長化や長期保管が必要であるデータについて、Log Analytics ワークスペースと同一リージョンにあるストレージ アカウントへのエクスポートをご利用いただけます。GRS、GZRS など、ストレージ アカウントの冗長オプションを使用することで、他のリージョンにデータをレプリケートすることができます。

また、ストレージ アカウントにエクスポートされたデータは、Log Analytics ワークスペースに設定された保持期間の影響は受けないため、ストレージ アカウントにログをエクスポートし、ストレージ アカウントで長期保管することが可能です。さらに、ストレージ アカウントのライフサイクル管理ポリシーを利用することで、ストレージ アカウントにエクスポートされたデータを管理する (一定期間を過ぎた後に自動で削除する等) ことが可能です。

ストレージ アカウントのライフサイクル管理については、以下の公開情報をご参照ください。
Azure Blob Storage ライフサイクル管理の概要 - Azure Blob Storage | Microsoft Learn
ライフサイクル管理ポリシーを構成する - Azure Blob Storage | Microsoft Learn

なお、ストレージ アカウント上にエクスポートされた JSON ファイル内のデータは、KQL の externaldata operator を使用することでクエリすることが可能です。詳細は、本記事 5.2.7 ストレージ アカウントに収集したデータの可視化 をご参照ください。


■ データ エクスポート機能の主な利用シナリオ - Event Hubs
Azure サービスおよびその他のツールとの統合: Event Hubs にエクスポートすることで、他 Azure サービスやツールとの統合が実現可能です。


■ データ エクスポート機能の利用開始方法
データ エクスポート ルールの必要な権限や制限、作成手順の詳細については以下の公開情報をご参照ください。
Azure Monitor の Log Analytics データ エクスポート - Azure Monitor | Microsoft Learn

一部のテーブルはデータ エクスポート機能がサポートされていないため、ご注意ください。
サポート対象外のテーブルは以下より確認いただけます。
Log Analytics workspace data export in Azure Monitor | Unsupported tables - Azure Monitor | Microsoft Learn


5.1.8 ネットワークの監視

Network Watcher は、仮想マシン (VM)、仮想ネットワーク (VNet)、アプリケーション ゲートウェイ、ロード バランサーなどの IaaS 製品のネットワーク正常性の監視や修復が可能なサービスです。
Azure Network Watcher の概要 | Microsoft Learn

Network Watcher の機能の一つであるネットワークの分析情報は、Azure ポータル > [モニター (監視)] > [分析情報] > [ネットワーク] にて確認できます。

ネットワークの分析情報 | Microsoft Learn


お問い合わせに関するご留意事項
ネットワークの分析情報を含め Network Watcher については、Japan Azure Monitoring サポート チームではなく、Japan Azure Networking サポート チームにて対応しております。これらに関するお困りごとやご質問はネットワーク製品観点でお問い合わせを発行してください。Japan Azure Networking サポート チームのブログは以下のリンクよりご確認ください。
Japan Azure IaaS Core Support Blog




5.2 分析とレポート

本項では、取得した監視データの利用方法をご紹介します。

5.2.1 Log Analytics ワークスペースのクエリ

各種の Azure リソースやマシンから Log Analytics ワークスペースに収集したデータはクエリを実行して確認します。

■ クエリのモード
クエリを実行する 2 種類のモードがあります。簡易モードでは Azure ポータル > 対象の Log Analytics ワークスペース > [ログ] > [テーブル] > [対象テーブルの実行] をクリックすることで、簡単にクエリを実行可能です。

KQL モードではより詳細なクエリを指定して実行することでカスタマイズしたクエリ実行結果を取得することが可能です。

Azure Monitor ログでログ クエリの使用を開始する - Azure Monitor | Microsoft Learn


■ 共有機能
クエリの実行結果は [共有] から Excel 等のファイルに出力可能です。

Log Analytics と Excel を統合する - Azure Monitor | Microsoft Learn


■ アクセス制御モード
Log Analytics ワークスペースのアクセス制御モードには 2 種類あります。
ワークスペース コンテキスト アクセス制御モードでは Log Analytics ワークスペースの [ログ] からアクセスすることで、複数のリソースから Log Analytics ワークスペースに収集されたすべてのログを参照します。

※ ワークスペース コンテキスト アクセス制御モードの場合の例

リソース コンテキスト アクセス制御モードでは Azure ポータル > 対象の Azure リソース > [監視] > [ログ] からアクセスすることで、対象のリソースから Log Analytics ワークスペースに収集されたログのみを参照します。

※ リソース コンテキスト アクセス制御モードの場合の例

Log Analytics ワークスペースのアクセス制御モードの違いについて | Japan Azure Monitoring Support Blog

Log Analytics ワークスペース内の各テーブルや、各テーブルのサンプル クエリは、以下の公開情報をご参照ください。
Azure Monitor Resource log / log analytics tables - Azure Monitor | Microsoft Learn
Azure Monitor log analytics queries by tables - Azure Monitor | Microsoft Learn


5.2.2 ログ アラート ルール

ログ アラート ルールは、Azure リソースやお客様のアプリケーションなどから収集されたログを監視する機能です。
Log Analytics ワークスペースに収集されたログに加え、Azure Resource Graph や Azure Data Explorer のデータを監視することもできます。

1. 定期的にクエリを実行してログを評価する
KQL (Kusto Query Language) という Log Analytics のクエリ言語を使って監視する条件を定義します。
例 : 仮想マシンが停止していないかどうか (過去 10 分間の Heartbeat のレコードが 0 件かどうか)

ログ アラート ルールは、指定された評価期間のログを対象に、定期的にクエリを実行します。クエリの実行結果がしきい値（例：過去 10 分間の Heartbeat のレコード数 < 1）を満たすと、アラートが発報します。

2. 通知や自動アクションを実行する
アラートが発報した時に通知する方法や、実行するアクションは「アクション グループ」で設定します。
アラート ルールにアクション グループを関連付けると、メールや電話、SMS で通知したり、Webhook などの自動アクションを実行することが可能です。

※ 以下例はアクション グループで共通アラート スキーマを有効化した時に通知されたメールです。

ログ アラート ルールの設定手順などは、以下の公開情報やブログをご参照ください。
Azure Monitor のログ検索アラート ルールを作成する - Azure Monitor | Microsoft Learn
Azure Monitor でアクション グループを作成および管理する - Azure Monitor | Microsoft Learn
Azure Monitor のアラートに関するよくあるご質問 | Japan Azure Monitoring Support Blog


5.2.3 メトリック アラート ルール

メトリック アラート ルールは、Azure リソースのパフォーマンスや状態を示すメトリックを監視する機能です。
既定で収集されるプラットフォーム メトリックや、既定では収集されないカスタム メトリックを監視することが可能です。

1. 定期的にメトリックの値を評価する
監視する Azure リソースやメトリックを決め、しきい値などの監視条件を指定します。
例 : Azure VM の CPU 使用率が 80% を超えているかどうか

メトリック アラート ルールは、指定されたルックバック期間（評価期間）のメトリックを対象に、しきい値を満たしているかどうかを定期的に評価します。メトリックの値がしきい値（例：PercentageCpu > 80）を満たすと、アラートが発報します。

2. 通知や自動アクションを実行する
アラートが発報した時に通知する方法や、実行するアクションは「アクション グループ」で設定します。
アラート ルールにアクション グループを関連付けると、メールや電話、SMS で通知したり、Webhook などの自動アクションを実行することが可能です。

※ 以下例はアクション グループで共通アラート スキーマを有効化した時に通知されたメールです。

メトリック アラート ルールの設定手順などは、以下の公開情報やブログをご参照ください。
Azure Monitor のメトリック警告ルールを作成する - Azure Monitor | Microsoft Learn
Azure Monitor でアクション グループを作成および管理する - Azure Monitor | Microsoft Learn
Azure Monitor のアラートに関するよくあるご質問 | Japan Azure Monitoring Support Blog


5.2.4 アクティビティ ログ アラート

アクティビティ ログ アラートは、Azure リソースのアクティビティ ログを監視する機能です。
アクティビティ ログ アラートには、サービス正常性アラートやリソース正常性アラートも含まれます。

1. 条件に一致するアクティビティ ログが記録されているかどうかを評価する
監視する Azure リソースやアクティビティ ログの条件を決めます。
例 : Azure VM の割り当て解除 (Deallocate Virtual Machine)

アクティビティ ログ アラートは、指定した条件に一致するアクティビティ ログ イベントが発生しているかどうかを評価します。監視対象の Azure リソースで条件に一致するアクティビティ ログが記録されると、アラートが発報します。

2. 通知や自動アクションを実行する
アラートが発報した時に通知する方法や、実行するアクションは「アクション グループ」で設定します。
アラート ルールにアクション グループを関連付けると、メールや電話、SMS で通知したり、Webhook などの自動アクションを実行することが可能です。

※ 以下例はアクション グループで共通アラート スキーマを有効化した時に通知されたメールです。

アクティビティ ログ アラートの設定手順などは、以下の公開情報やブログをご参照ください。
アクティビティ ログ、サービス正常性、またはリソース正常性の警告ルールを作成する - Azure Monitor | Microsoft Learn
Azure Monitor でアクション グループを作成および管理する - Azure Monitor | Microsoft Learn
Azure Monitor のアラートに関するよくあるご質問 | Japan Azure Monitoring Support Blog


5.2.5 サービス正常性アラートとリソース正常性アラート

■ サービス正常性アラート
サービス正常性アラートは、お客様環境にてご利用いただいている Azure サービスおよびリージョンを監視対象とし、Azure サービス自体の正常性を監視する機能です。Azure サービスの障害や計画メンテナンス、サービスの廃止などのイベントが発生した際に、メールや SMS 等の方法で通知することが可能です。

1. 条件に一致するアクティビティ ログが記録されているかどうかを評価する
監視する Azure サービス、リージョン、イベントの種類を指定します。サービス正常性アラートは、ご利用いただいているサービスおよびリージョンを対象としたイベントが発生した場合にのみ通知が行われる仕組みのため、”サービス” や “リージョン” はすべて選択いただくことを推奨しております。

例. Azure OpenAI Service の正常性の勧告

サービス正常性アラート（アクティビティ ログ アラート）は、指定した条件に一致するアクティビティ ログ イベントが発生しているかどうかを評価します。監視対象のサービスやリージョンに関するサービス正常性イベントのアクティビティ ログが記録されると、アラートが発報します。

2. 通知や自動アクションを実行する
アラートが発報した時に通知する方法や、実行するアクションは「アクション グループ」で設定します。
アラート ルールにアクション グループを関連付けると、メールや電話、SMS で通知したり、Webhook などの自動アクションを実行することが可能です。

※ 以下例は Azure Monitor のアクション グループによって通知されたメールです。

サービス正常性アラートの設定手順などは、以下の公開情報やブログをご参照ください。
Azure ポータル で Azure サービス通知の Service Health アラートを作成する - Azure Service Health | Microsoft Learn
Azure Monitor でアクション グループを作成および管理する - Azure Monitor | Microsoft Learn
サービス正常性アラートの設定手順と推奨設定について | Japan Azure Monitoring Support Blog


■ リソース正常性アラート
リソース正常性アラートは、Azure リソースの正常性を監視する機能です。
リソースの正常性に変化が生じた際に、メールや SMS 等の方法で通知することが可能です。サービス正常性アラートは Azure サービスおよびリージョンを監視対象としますが、リソース正常性アラートはお客様環境の固有のリソースを監視します。監視対象のスコープが異なるとご認識ください。

1. 条件に一致するアクティビティ ログが記録されているかどうかを評価する
監視する Azure リソースや監視条件を決めます。

例 : Azure VM のリソース正常性（以下はリソース正常性が解消した際のアクティビティ ログの一例）

リソース正常性アラート（アクティビティ ログ アラート）は、指定した条件に一致するアクティビティ ログ イベントが発生しているかどうかを評価します。監視対象のリソースで条件に一致したリソース正常性イベントのアクティビティ ログが記録されると、アラートが発報します。

2. 通知や自動アクションを実行する
アラートが発報した時に通知する方法や、実行するアクションは「アクション グループ」で設定します。
アラート ルールにアクション グループを関連付けると、メールや電話、SMS で通知したり、Webhook などの自動アクションを実行することが可能です。

※ 以下例は Azure Monitor のアクション グループで共通アラート スキーマを有効化した時に通知されたメールです。

リソース正常性アラートの設定手順などは、以下の公開情報やブログをご参照ください。
Resource Health アラートを作成する方法 - Azure Service Health | Microsoft Learn
リソース正常性アラートに関するよくあるご質問 | Japan Azure Monitoring Support Blog


5.2.6 Log Analytics ワークスペースのコスト分析

Log Analytics ワークスペースのコストは収集するデータの量によって変動します。

1. ログの料金について
Log Analytics ワークスペースのコストは主に以下 3 点によって決まります。

  • データのインジェスト量 (取り込んだログの量)
  • データの保有量と保有期間
  • Log Analytics ワークスペースが存在するリージョン

■ データ インジェストに対するコストについて
インジェストに対するコストは、取り込み先テーブルのテーブル プラン (Analytics (分析) / Basic (基本) / Auxiliary (補助)) により異なり、既定は Analytics プランで設定されています。また、既定の価格モデルは「従量課金制」です。
金額の詳細は以下の公開情報をご参照ください。
価格 - Azure Monitor | Microsoft Azure

プランを変更する場合はテーブル単位で設定変更が可能です。詳細は以下の公開情報をご参照ください。
Log Analytics ワークスペースでのデータ使用状況に基づいてテーブル プランを選択する - Azure Monitor | Microsoft Learn

■ データ保持に対するコストについて
Log Analytics ワークスペースに取り込まれたデータは 31 日間無料で保持されます。
データ保持期間を 31 日にご設定いただいている場合はデータ保持料金の費用は発生しません。
既定のデータ保持期間は 30 日です。


2. 現在のコストを確認する方法
[Log Analytics ワークスペース] - [設定] - [使用料と推定コスト] のページ右側に “使用状況のグラフ” として、過去 31 日間の、課金対象のテーブルごとのデータ インジェスト量が表示されます。

使用料と推定コストについては以下の公開情報をご参照ください。
Azure Monitor のコストと使用量 - Azure Monitor | Microsoft Learn


3. クエリを用いてコストを確認する方法
Log Analytics ワークスペース内の各テーブルの使用状況データは Usage テーブルに集計されています。Usage の Quantity は MB（Mbytes）単位です。以下は、過去 31 日間の「テーブル (DataType) 別・日別」の課金対象データ量 (MB) を集計する例です。

1
2
3
4
5
6
Usage 
| where TimeGenerated > ago(32d) 
| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now()) 
| where IsBillable == true 
| summarize BillableDataMB = sum(Quantity) by bin(StartTime, 1d), DataType
| render columnchart

また、特定のテーブルで課金対象データ量を確認する場合は以下の標準列を使用します。

  • _IsBillable：そのレコードが課金対象かどうか （true / false）
  • _BilledSize：そのレコードのサイズ（Bytes）

以下は Event テーブルの Event ID ごとの課金対象データ量（MB）を日別に集計する例です。

1
2
3
4
Event 
| where TimeGenerated > startofday(ago(31d)) and TimeGenerated < startofday(now()) 
| where _IsBillable == true 
| summarize count(), BillableDataMB =sum(_BilledSize) / 1000 / 1000 by EventID, bin(TimeGenerated, 1d)

Log Analytics のコスト分析の詳細は、以下の公開情報をご参照ください。
Azure Monitor の Log Analytics ワークスペースでの使用量を分析します - Azure Monitor | Microsoft Learn


4. コストを分析し削減を検討する
コスト分析と削減についての検討については以下のブログをご参照ください。
Log Analytics ワークスペースのコスト増加の原因を分析しコスト削減を検討する | Japan Azure Monitoring Support Blog


5.2.7 ストレージ アカウントに収集したデータの可視化

本記事 5.1.6 診断設定 や 5.1.7 データ エクスポート にて、ストレージ アカウントに出力したログ ファイルに対してもクエリを実行することが可能です。本項では次の 2 つのアプローチを紹介します。

1 つは Azure Data Explorer に BLOB（ログ ファイル）を取り込んで分析する方法、もう 1 つは Log Analytics ワークスペースで externaldata 演算子を使ってクエリを実行する方法です。なお、頻繁にデータにクエリしたり、アラートを発報する必要がある場合は、診断設定ではストレージ アカウントではなく Log Analytics ワークスペースへ収集することをご検討ください。

■ Azure Data Explorer を使う方法
以下に Azure Data Explorer に BLOB を取り込んで、クエリする方法を簡単にご紹介します。

  1. 以下の公開情報の手順に沿ってクラスターとデータ ベースを作成します。
    クイック スタート: Azure Data Explorer クラスターとデータベースを作成する - Azure Data Explorer | Microsoft Learn

  2. Azure Data Explorer のクラスターに Azure Data Explorer または下図の ADX の [概要] の [URI] からアクセスします。

  3. クエリを実行したいファイルがあるコンテナーからログを取り込みます。
    Azure Storage からデータを取得する - Azure Data Explorer | Microsoft Learn

  4. 3 で作成したテーブルに対して、下図のように Log Analytics ワークスペースと同じクエリでデータを参照できます。
    ※ Azure Data Explorer のクエリ結果（テーブル名は手順 3 にて設定できます）

    ※ Log Analytics ワークスペースのクエリ結果

Azure Data Explorer の概要については、以下の公開情報をご参照ください。
なお、Azure Data Explorer リソースの利用にはコストが発生する点をご留意ください。
Azure Data Explorer とは - Azure Data Explorer | Microsoft Learn
Azure Data Explorer の取り込まれたデータの GB あたりのコスト - Azure Data Explorer | Microsoft Learn


■ externaldata 演算子を使う方法
Log Analytics ワークスペースの [ログ] から externaldata 演算子にて、ストレージ アカウントの BLOB に対してクエリを実行できます。externaldata 演算子の使い方を簡単にご紹介します。

  1. クエリを実行したい BLOB の SAS を取得します。
    ストレージ コンテナーと BLOB の共有アクセス署名 (SAS) トークンを作成する - Foundry Tools | Microsoft Learn

  2. [BLOB SAS URL] をコピーします。

  3. Log Analytics ワークスペースの [ログ] にて、2 でコピーした [BLOB SAS URL] を以下クエリの <BLOB SAS URL> に設定すると、BLOB のデータに対してクエリを実行できます。

    1
    2
    3
    4
    let Testdata = externaldata(TimeGenerated:datetime, Computer:string, Category:string, OSType:string)[
    h@"<BLOB SAS URL>"  
    ] with (format='multijson');  
    Testdata

    ※ externaldata 演算子の実行例

    なお、txt 形式で 1 行のレコードを dynamic として取り込むことで、全プロパティを取得することもできます。

    1
    2
    3
    4
    5
    let Testdata = externaldata(RawData:dynamic) [
    h@"<BLOB SAS URL>"  
    ] with (format='txt');  
    Testdata  
    | evaluate bag_unpack(RawData)

    ※ externaldata 演算子ですべてのプロパティを取得する実行例

externaldata 演算子については、以下の公開情報をご参照ください。
エクスターナルデータ演算子 - Kusto | Microsoft Learn


5.2.8 Application Insights のクエリ

Application Insights に記録されたログは、Application Insights が Log Analytics ワークスペースと統合されているため、Application Insights と Log Analytics ワークスペースの両方から参照できます。

Application Insights は Azure ポータル > Application Insights / Log Analytics ワークスペース > [監視] > [ログ] からクエリを実行します。UI の構成や機能は同じであるため、クエリの実行方法については本記事 5.2.1 Log Analytics ワークスペースのクエリ をご参照ください。ただし、ご留意いただく点が 2 つあります。

1. Application Insights と Log Analytics ワークスペースで同じデータを参照する場合のテーブルとカラムが異なります。
Application Insights と Log Analytics ワークスペースのテーブルとカラムの対応は以下の公開情報でご案内しております。
テーブルは [テーブル構造] にてご案内しており、Application Insights では [レガシー テーブル名] が利用されています。Log Analytics ワークスペースでは、[新しいテーブル名] が利用されています。カラムは [テーブル スキーマ] にてご案内しております。
例えばリクエスト ログを取得するには、Application Insights では requests テーブルを参照し、Log Analytics ワークスペースでは AppRequests テーブルを参照します。

Application Insights のクラシック リソースをワークスペースベースのリソースに移行する - Azure Monitor - Azure Monitor | Microsoft Learn


2. Log Analytics ワークスペースからは関連付いたすべての Application Insights のログが参照されます。
Application Insights の [ログ] からクエリを実行すると、対象の Application Insights のログのみを参照します。

一方で、Log Analytics ワークスペースの [ログ] からクエリを実行すると、対象の Log Analytics ワークスペースに関連付いたすべての Application Insights のログを参照できます。下図の赤枠は上図の Application Insights とは別の Application Insights のログです。
他の Application Insights からのログも同時に参照できることが分かります。


5.3 可視化

本項では、取得データを可視化する方法についてご紹介します。


5.3.1 ワークブック

1. Azure ワークブックの概要
Azure ワークブックを利用することで、様々な Azure リソースから得られるデータをもとに、視覚的なレポートを作成することができます。ワークブックは単なるグラフ表示にとどまらず、以下のような内容を組み合わせることで、分析・調査・状況説明に適したレポートを作成できる点が特徴です。

  • テキストによる説明
  • グラフ、表、タイルなどのビジュアル表示
  • パラメーターを用いた対話型操作

2. Azure ワークブックが対応するデータ ソース
Azure ワークブックは、さまざまなデータ ソースから情報を取得できます。

  • ログ (Log Analytics ワークスペース、Application Insights)
  • メトリック
  • Azure Resource Graph
  • Azure Resource Manager
  • Azure Data Explorer
  • JSON

サポートされているデータ ソースの詳細については、以下の公開情報をご参照ください。
Azure Workbooks のデータ ソース - Azure Monitor | Microsoft Learn


3. Azure ワークブックの可視化機能
ワークブックには、Azure Monitor のデータを視覚化するための豊富なビジュアル コンポーネントが用意されています。
使用できる機能はデータ ソースや結果セットに依存しますが、以下のような代表的なコンポーネントがあります。


4. Azure ワークブックのパラメーター機能
Azure ワークブックの大きな特徴の一つが、パラメーター機能です。
パラメーターを使用すると、利用者からの入力を受け取り、その値をワークブック内の他のクエリやビジュアルで参照できます。
具体的には以下のような対話型のレポートを作成することができます。

  • 表示対象の時間範囲を切り替える
  • クエリ結果を動的に変更する

5. パラメーターの表示方法と入力形式
ワークブックでは、パラメーターを次のような形式で表示できます。

  • テキスト ボックス
  • ドロップダウン リスト
  • 単一選択／複数選択
  • JSON、KQL、Azure Resource Graph による値の動的生成

6. Azure ワークブックの作成

  1. Azure ワークブックへのアクセス
    Azure ワークブックには Azure ポータル > [モニター (監視)] > [ブック] よりアクセスすると、[ギャラリー] に Azure ワークブックのテンプレートが一覧表示されます。

  2. テンプレートの表示・編集
    [ギャラリー] に表示されているテンプレートを開き、パラメーターを選択してグラフや表をカスタマイズできます。さらに、画面上部の [編集] を選択すると編集モードに切り替わります。編集モードでは、グラフや表の設定変更、パラメーターの追加・並べ替えが可能です。

  3. パラメーターの作成
    パラメーターにより表示時間を切り替えるブックの作成方法について以下にご紹介します。
    ⅰ. パラメーターを追加します。

    ⅱ. パラメーターの型では「時間の範囲の選択」を選びます。

    ⅲ. つづいてブックにクエリを追加し、[時間範囲] で先に作成したパラメーター名を指定します。

    ⅳ. 編集完了後、パラメーターの値を変更すると自動でグラフが変化します。

テンプレートやブックのパラメーター、ブックの作成・編集の詳細については、以下の公開情報をご参照ください。
Azure Workbooks テンプレート - Azure Monitor | Microsoft Learn
ブックのパラメーターを作成する - Azure Monitor | Microsoft Learn
Azure ワークブックを作成または編集する - Azure Monitor | Microsoft Learn


5.3.2 ダッシュボード

Log Analytics ワークスペース内のログに対して実行したクエリをグラフ等に可視化し、ダッシュボードにピン留めすることで、Log Analytics ワークスペースに保存されたデータをリアルタイムで確認できます。

■ ログ クエリの可視化手順
Log Analytics ワークスペースにてクエリを実行します。
クエリの実行方法については、本記事 5.2.1 Log Analytics ワークスペースのクエリ をご参照ください。

1
2
3
4
5
<サンプル クエリ>
AzureMetrics
| where MetricName contains "Percentage CPU"
| summarize AggregatedValue = avg(Average) by bin(TimeGenerated, 1m), _ResourceId
| render timechart

[保存] > [ピン留め先 Azure ダッシュボード] をクリックします。

Azure Monitor ログのデータを視覚化するダッシュボードを作成して共有する - Azure Monitor | Microsoft Learn


■ Azure ワークブックとの違い
ダッシュボードと類似機能の Azure ワークブックとの違いについて説明します。
Azure ワークブックの詳細は、本記事 5.3.1 ワークブック をご参照ください。

Azure ワークブック

  • テンプレートが充実している
  • 分析内容のカスタマイズ性が高い (KQL 等にて分析内容を要件に合わせて変更できます。) 
  • 設定が比較的難しいため利用難度が高い

※ Azure ワークブックは Azure ポータル > [モニター (監視)] > [ブック] からアクセスできます。


ダッシュボード

  • 画面の表示方法 (レイアウト) を容易に変更できる

  • Azure ワークブックをダッシュボードにピン留めすることができる

  • 分析グラフ以外にもリソースやソリューション ページ等よく使う項目のリンクとしても活用できる

  • ダッシュボードは Azure ポータル上のポータル メニュー (画面左上の三本線アイコン) > [ダッシュボード] からアクセスできます。

Azure portal でダッシュボードを作成する - Azure portal | Microsoft Learn


5.3.3 メトリック エクスプローラー

メトリック エクスプローラーではメトリックを時系列のグラフとして可視化します。
Azure ポータル > 対象の Azure リソース > [監視] > [メトリック] からメトリック エクスプローラーにアクセスします。
以下は Azure VM のプラットフォーム メトリック (ホスト メトリック) とゲスト OS メトリックの表示の例です。

■ プラットフォーム メトリック
プラットフォーム メトリックは Azure VM を作成すると自動的に収集が開始され、[メトリック名前空間] を “仮想マシンホスト” に設定すると確認できます。

■ ゲスト OS メトリック
ゲスト OS メトリックはゲスト OS にインストールした Azure Monitor エージェントにより収集され、[メトリック名前空間] を “仮想マシンのゲスト” に設定すると確認できます。

メトリック エクスプローラーの詳細や、プラットフォーム メトリックとゲスト OS メトリックの違いについては、以下の公開情報とブログをご参照ください。
Azure Monitor メトリックス エクスプローラーを使用してメトリックを分析する - Azure Monitor | Microsoft Learn
Azure VM の監視について | Japan Azure Monitoring Support Blog


5.3.4 Application Insights の可視化

Application Insights に収集されたデータは、クエリを利用しなくても Azure ポータルの UI から可視化・分析できます。
もちろん Log Analytics ワークスペースへ記録した他のログと同様に、クエリを利用した分析やアラート ルールの構成も可能です。

はじめに Application Insights の [調査] タブ内の各メニューを簡単に紹介します。詳細な使い方は以下の公開情報をご参照ください。

ポータルの表示内容公開情報のリンク
アプリケーション マップアプリケーションの依存関係を可視化し、各コンポーネント間のパフォーマンスを表示します。公開情報
スマート検出機械学習によってアプリケーションの異常を検知します。アラート ルールによる通知も設定できます。公開情報
ライブ メトリックアプリケーションから収集されるテレメトリをリアルタイムに表示します。公開情報
検索記録されたテレメトリを検索します。後述の [失敗] と [パフォーマンス] では表示されない、ページ ビュー、例外、カスタム イベントなどの個々のテレメトリ項目を検索できます。公開情報
有効可用性テストを作成し、その結果を表示します。公開情報 ブログ
障害アプリケーションのエラー状況を分析します。公開情報
パフォーマンス応答時間とリクエスト数からアプリケーションのパフォーマンスを分析します。公開情報
Agents (Preview)AI エージェントの監視データを可視化します。公開情報

また、[使用状況] タブ内の各メニューではアプリケーションの利用状況 (ユーザー、セッションなど) を分析できます。

詳細は以下の公開情報をご参照ください。
Application Insights による利用状況分析 - Azure Monitor | Microsoft Learn




6. セキュリティ

本章では Azure Monitor のセキュリティ機能に関してご紹介します。
すべてのセキュリティ設定を網羅するのではなく、利用者様が疑問を持ちやすく、よくお問い合わせをいただく項目に絞ってご紹介します。

Azure Monitor では、サービス側のセキュリティ対策として、既定でログの送信やクエリなどの転送中のデータが TLS 1.2 以降で保護され、保存されるすべてのデータとクエリは Microsoft マネージド キーで暗号化されます。
また、Microsoft Entra ID による認証や Azure RBAC によるアクセス制御が提供されています。
パブリック エンドポイントへの接続についてもエンドツーエンドで暗号化されるため、後述の Azure Monitor Private Link Scope (AMPLS) を構成しない場合にも、通信や保存データは暗号化されますのでご安心ください。


1. AMPLS の概要
AMPLS（Azure Monitor Private Link）を構成することで、Azure Monitor（Log Analytics や Application Insights など）への通信をパブリック インターネットを経由せず、プライベート ネットワーク経由で行うことが可能になります。

仮想ネットワーク (VNet) にプライベート エンドポイント (PE) を作成して AMPLS に接続し、AMPLS に関連付けた Log Analytics / Application Insights などに対するインジェスト（送信） および クエリ（参照）の通信を、インターネットを経由せず Private Link 経由にする構成です。基本的には VNet ごとに 1 つの PE を作成し構成します。

AMPLS の基本的な概念や概要については、以下の公開情報をご参照ください。
基本的な概念 - Azure Monitor | Microsoft Learn
Azure Private Link を使用して、ネットワークを Azure Monitor に接続する - Azure Monitor | Microsoft Learn


■ AMPLS を構成するとできること
例えば、次のような要件に対応できます。

  • インターネットへの outbound を厳しく制限したまま、VM から Log Analytics にログを送信したい

    VNet 内の PE 経由で Azure Monitor のエンドポイントへ到達できるため、監視データがパブリック インターネットを経由しない設計が可能です。

  • 特定のネットワークからのみ Log Analytics ワークスペースに対するクエリ（KQL）を許可したい

    AMPLS では、クエリ / インジェスト それぞれについて、アクセス モード (Open / PrivateOnly) を設計できます。


■ AMPLS 環境下で扱う通信の種類

  • データの参照（クエリ）：Log Analytics のログ クエリ、Application Insights のクエリ等
  • データの送信（インジェスト）：エージェントや Application Insights SDK 等からのログ/テレメトリ送信

2. AMPLS の構成設計について
AMPLS の構成においては、DNS の名前解決設計が重要なポイントとなります。

■ AMPLS のプライベート DNS ゾーンについて
AMPLS を作ると、Azure Monitor のエンドポイントは DNS ゾーンでプライベート IP にマップされ、通信が Private Link 経由になります。Azure Monitor はリソース固有エンドポイントだけでなく、共有 (グローバル/リージョン) エンドポイントも使います。

そのため、たとえ 1 つのリソースに Private Link を構成しただけでも DNS 構成が変更され、“すべてのリソース” 向けトラフィックに影響が出る可能性があります。さらに、同じ DNS を共有するネットワークで複数 AMPLS を作ると DNS が上書き (override) され、既存環境に影響が出る可能性があるため、設計段階での整理が重要となります。

AMPLS のプライベート DNS ゾーンの詳細については、以下の公開情報をご参照ください。
グローバルおよびリージョンエンドポイントの共有 - Azure Monitor | Microsoft Learn
Azure Monitor Private Link の構成を設計する - Azure Monitor | Microsoft Learn


■ AMPLS のサブネット サイズ / 必要 IP アドレス数について
Azure Monitor Private Link の構成では、サポートされる最小の IPv4 サブネットは /27 です。
Azure Monitor プライベート リンク エンドポイントの一覧については、エンドポイントの DNS 設定を確認してください。
また、より詳しい IP 消費の考え方（目安・計算方法の例）は、以下のブログをご参照ください。
Azure Monitor のプライベート リンクを構成する - Azure Monitor | Microsoft Learn
AMPLS で必要な IP アドレスの個数について | Japan Azure Monitoring Support Blog


■ AMPLS 利用時の注意点（制限事項 / 例外）
AMPLS は以下の例外、制限事項があります。

  • 診断ログ 
    診断設定で Log Analytics ワークスペースに送信されるログやメトリックは、Azure 基盤側で管理されているセキュアなプライベート Microsoft チャネル経由で送信されるため、AMPLS のネットワーク制御の影響を受けません。

  • ゲスト OS メトリック
    Azure Monitor エージェント (AMA) により送信されるゲスト OS メトリックは、AMPLS 経由で収集することができません。


3. AMPLS の構成について
構成手順の概要は以下のとおりです。詳細は以下の公開情報をご参照ください。

  1. AMPLS を作成します。
  2. Azure Monitor リソースを AMPLS に接続します。
  3. PE を作成し AMPLS に接続します。

PE の IP 割り当てを静的にすると、作成後に PE 側へ割り当てる IP（＝プライベート DNS で解決される各エンドポイントの宛先）を増やせません。そのため、後から AMPLS にデータ収集エンドポイント (DCE) や Application Insights などのリソースを追加して到達先エンドポイントが増える場合、既存の PE では対応できず作り直しが必要になります。将来的に追加で AMPLS にリソースを接続させる可能性がある場合は 動的割り当てを推奨します。


6.2 データ削除

Log Analytics ワークスペースのログは、保持期間を超えると自動的に削除されます。
一方、保持期間を迎える前にログを削除する場合は、REST API を利用いただく必要がございます (Azure ポータルから手動でログを削除することはできません)。ログを削除するための REST API は用途の異なる 2 種類があり、目的に応じて使い分けていただく必要があります。

■ Purge API
Log Analytics ワークスペースから対象データを完全に削除します。このため、GDPR（EU 一般データ保護規則）に準拠しています。
Workspace Purge - Purge - REST API (Azure Log Analytics) | Microsoft Learn

■ Delete Data API
対象データを削除済みとしてマークし、物理的にデータを削除しません。このため、GDPR に準拠していません。
Log Analytics ワークスペースのデータを削除する - Azure Monitor | Microsoft Learn

GDPR の要件に準拠する必要がある場合は Purge API、それ以外の場合は基本的に Delete Data API をご利用ください。
REST API の実行手順や前提条件は、以下の公開情報やブログをご参照ください。
Azure Monitor ログで個人データを管理する - Azure Monitor | Microsoft Learn
Log Analytics ワークスペースのデータを削除する方法 | Japan Azure Monitoring Support Blog


]]> https://jpazmon-integ.github.io/blog/AzureMonitorEssential/StartUpGuide/ 2026-07-29T15:00:00.000Z [更新履歴]

  • 2026/07/30 : ブログ公開
]]> Azure Monitor スタートアップ ガイド 2026-09-06T00:15:21.663Z Japan Azure Monitoring Support Team [更新履歴]

  • 2026/04/24 ブログ公開

こんにちは、Azure Monitoring サポート チームの佐々木です。
近日発表された以下の API キーの廃止と移行について Q&A 形式でご紹介させていただきます。

https://azure.microsoft.com/ja-jp/updates?id=transition-to-azure-ad-to-query-data-from-azure-monitor-application-insights-by-31-march-2026

API キーの廃止について

以下ページにて Application Insights の API キーの廃止と、Entra ID 認証への移行が案内されています。

https://azure.microsoft.com/ja-jp/updates?id=transition-to-azure-ad-to-query-data-from-azure-monitor-application-insights-by-31-march-2026

サービス正常性やメールにて、過去にも同様の廃止通知を受け取っていたお客様もいるかと思います。

Q&A

インストルメンテーションキー(InstrumentationKey または ikey)や接続文字列を使っています。移行の必要がありますか?

ikey(および接続文字列) と 廃止通知が行われた API Key は異なりますので、それぞれ以下の様にご理解いただけますと幸いです。

区分用途今回の記事の対象か
Instrumentation Key / Connection Stringアプリから Application Insights へテレメトリを送信するための識別・取り込み設定対象ではない
Application Insights API keyapi.applicationinsights.io などで Application Insights のデータをクエリ取得するための API key対象
Microsoft Entra ID 認証上記 API key の代替として、クエリ API 呼び出し時に使う認証方式API Key を使用している場合の移行先

より簡潔にしますと、以下の様に使用方法も異なる別の機能であると言えます。

  • ikeyおよび接続文字列 … ログを送信する際に使用されます。
  • API keyおよびMicrosoft Entra ID … ログを検索する際に使用されます。

また、これらは使用方法が異なるため、Application Insights へログを送信するアプリケーション(ikeyおよび接続文字列を使用)とは別のアプリケーションで使用されている事があります。

複数のアプリケーションを実装・管理されている場合にはご留意ください。

API キーを使用しているか確認するにはどうすればいいですか?

Azure ポータル > Application Insights > API アクセス に API キーが表示されるかご確認ください。

  • API キーが作成されていない場合の表示例
image

API キーが表示される場合には、お客様のアプリケーションが API キーを利用して、ログ検索を行っている可能性がありますので、
お客様がお持ちのアプリケーションソースコードで API キー 認証によるクエリ等が実装されていないかをご確認ください。

コードは開発言語、フレームワーク等により全く異なります。また、Azure および Azure サポートでは Azure VM や App Service/Function App 等に配置された任意のファイルの読み取りができません。

原則として、該当するアプリケーションの有無はお客様にてご確認いただく必要がある事をご理解いただけますと幸いです。

API キーから Microsoft Entra ID 認証へ移行するにはどの様にすればいいですか?

例えば、API キー による認証から Microsoft Entra ID 認証に移行する場合は以下の様な PowerShell へ置き換えいただく事も可能です。

この様な Connect-AzAccount + Get-AzAccessToken により取得されたトークンによるクエリ実行は Microsoft Entra ID 認証です。

ご利用される場合には冒頭の以下の値を書き換えいただく必要があります。

  • $tenantId
  • $appId
  • $query
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
# Install-Module Az.Accounts -Scope CurrentUser
$tenantId = "<Tenant ID>"
$appId = "<Application Insights の Application ID>" # API Access ブレードの Application ID
$query    = @"
requests
| where timestamp >= ago(12h) //過去12時間のログを探します。
| order by timestamp desc
"@

Connect-AzAccount -Tenant $tenantId
# Application Insights API 用のアクセストークンを取得
$tokenObject = Get-AzAccessToken -ResourceUrl "https://api.applicationinsights.io"
# Az.Accounts のバージョンにより Token が SecureString の場合があるため平文化
if ($tokenObject.Token -is [System.Security.SecureString]) {
   $accessToken = [System.Net.NetworkCredential]::new("", $tokenObject.Token).Password
} else {
   $accessToken = $tokenObject.Token
}
$uri = "https://api.applicationinsights.io/v1/apps/$appId/query"
$headers = @{
   Authorization  = "Bearer $accessToken"
   "Content-Type" = "application/json"
}
$body = @{
   query    = $query
} | ConvertTo-Json -Depth 5
$response = Invoke-RestMethod `
   -Method Post `
   -Uri $uri `
   -Headers $headers `
   -Body $body
# 結果を PowerShell オブジェクトに変換して表示
$table = $response.tables[0]
$columns = $table.columns.name
$results = foreach ($row in $table.rows) {
   $obj = [ordered]@{}
   for ($i = 0; $i -lt $columns.Count; $i++) {
       $obj[$columns[$i]] = $row[$i]
   }
   [pscustomobject]$obj
}
$results | Format-Table -AutoSize

このスクリプトの $tenantId と $appId のみを書き換えた実行結果サンプルは以下の様になります。

(保管されているログの内容により表示結果は異なりますので、ご留意ください。)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
省略
> $results | Format-Table -AutoSize

timestamp                    id               source name                  url                                                                  success resultCode   duration performanceBucket itemType
---------                    --               ------ ----                  ---                                                                  ------- ----------   -------- ----------------- --------
2026-04-24T05:54:56.975431Z  beabe5acf40edd43        GET /                 https://dasasaki-appservice-aienable.azurewebsites.net/              True    200            4.0036 <250ms            request
2026-04-24T05:54:56.975431Z  beabe5acf40edd43        GET /                 https://dasasaki-appservice-aienable.azurewebsites.net/              True    200            4.0036 <250ms            request
2026-04-24T05:54:56.975431Z  beabe5acf40edd43        GET /                 https://dasasaki-appservice-aienable.azurewebsites.net/              True    200            4.0036 <250ms            request
2026-04-24T05:54:00.7867403Z 650e9970e17fd645        GET /                 https://dasasaki-appservice-aienable.azurewebsites.net/              True    200           10.3806 <250ms            request
2026-04-24T05:54:00.7867403Z 650e9970e17fd645        GET /                 https://dasasaki-appservice-aienable.azurewebsites.net/              True    200           10.3806 <250ms            request
2026-04-24T05:54:00.7867403Z 650e9970e17fd645        GET /                 https://dasasaki-appservice-aienable.azurewebsites.net/              True    200           10.3806 <250ms            request
2026-04-24T05:52:16.6158311Z 1ec0c6f4d80ec740        GET /                 http://app-codex-profiler-jpe-20260424-b.azurewebsites.net/          True    200           20.2825 <250ms            request
2026-04-24T05:52:16.6158311Z 1ec0c6f4d80ec740        GET /                 http://app-codex-profiler-jpe-20260424-b.azurewebsites.net/          True    200           20.2825 <250ms            request
2026-04-24T05:52:16.6158311Z 1ec0c6f4d80ec740        GET /                 http://app-codex-profiler-jpe-20260424-b.azurewebsites.net/          True    200           20.2825 <250ms            request
2026-04-24T05:51:49.215188Z  db3281a511fc7a4f        GET /                 https://dasasaki-appservice-aienable.azurewebsites.net/              True    200            6.7112 <250ms            request
2026-04-24T05:51:49.215188Z  db3281a511fc7a4f        GET /                 https://dasasaki-appservice-aienable.azurewebsites.net/              True    200            6.7112 <250ms            request
2026-04-24T05:51:49.215188Z  db3281a511fc7a4f        GET /                 https://dasasaki-appservice-aienable.azurewebsites.net/              True    200            6.7112 <250ms            request
2026-04-24T05:51:47.7188839Z cff6ba3ad9d44a72        GET /                 http://app-codex-profiler-jpe-20260424.azurewebsites.net/            True    200          151.2283 <250ms            request
2026-04-24T05:51:47.7188839Z cff6ba3ad9d44a72        GET /                 http://app-codex-profiler-jpe-20260424.azurewebsites.net/            True    200          151.2283 <250ms            request
2026-04-24T05:51:47.7188839Z cff6ba3ad9d44a72        GET /                 http://app-codex-profiler-jpe-20260424.azurewebsites.net/            True    200          151.2283 <250ms            request
]]> https://jpazmon-integ.github.io/blog/applicationInsights/api-key-deprecate-and-migration/ 2026-04-23T15:00:00.000Z [更新履歴]

  • 2026/04/24 ブログ公開

こんにちは、Azure Monitoring サポート チームの佐々木です。
近日発表された以下の API キーの廃止と移行について Q&A 形式でご紹介させていただきます。

https://azure.microsoft.com/ja-jp/updates?id=transition-to-azure-ad-to-query-data-from-azure-monitor-application-insights-by-31-march-2026

]]> Application Insights API キーの廃止と移行について 2026-09-06T00:15:21.967Z Japan Azure Monitoring Support Team [更新履歴]
-2025/12/22 ブログ公開
-2025/12/23 目次と各項目の修正

こんにちは、Azure Monitoring サポート チームの佐々木です。

今回の記事では、Azure Monitor Private Link Scope 利用の際に必要になる IP レンジについてご説明します。

目次

計算方法について

下記の計算式で算出できます。

1
8 + Application Insights の接続文字列に定義されたエンドポイント数 + データ収集エンドポイント*3 + Log Analytics ワークスペースのリージョン数*3

8 個の内訳

  1. api.monitor.azure.com
  2. global.in.ai.monitor.azure.com
  3. profiler.monitor.azure.com
  4. live.monitor.azure.com
  5. diagservices-query.monitor.azure.com
  6. snapshot.monitor.azure.com
  7. scadvisorcontentpl.blob.core.windows.net
  8. global.handler.control.monitor.azure.com

例えば、AMPLS に 1 つの LA を接続する場合は 最低 11 個の IP アドレスが必要です。

次の項目ではより詳細に、追加される FQDN と IP をご紹介します。

8以外の各リソース追加によって追加される IP

以下ドキュメントに概要が記載されています。

エンドポイントの DNS 設定を確認する

Log Analytics

Log Analytics は AMPLS へ追加された Log Analytics のリージョン1つにつき3つのIPアドレスを消費します。

以下の 3 個のエンドポイントはワークスペース毎に作られますが、リージョンごとに同じ IP が割り当てられます。

  1. <ワークスペース ID>.privatelink-oms-opinsights-azure-com
  2. <ワークスペース ID>.privatelink-ods-opinsights-azure-com
  3. <ワークスペース ID>.privatelink-agentsvc-azure-automation-net

以下の様に同じリージョンのエンドポイントは同じ IP に割り当てられます。

image

データ収集エンドポイント

データ収集エンドポイント(DCE) は AMPLS へ追加された データ収集エンドポイント 1つにつき3つのIPアドレスを消費します。

以下のエンドポイントにそれぞれ IP アドレスが割り当てられます。

  1. <unique-dce-identifier>.<regionname>.handler.control
  2. <unique-dce-identifier>.<regionname>.ingest
  3. <unique-dce-identifier>.<regionname>.metrics.ingest

ワークスペースとは異なり、同じリージョンの DCE を AMPLS に 2 つ以上を追加した場合でも、 IP はそれぞれ追加されます。
例えば2つの DCE を追加した時、同じリージョンか異なるリージョンかに関わらず、IP は 6 つ追加されます。

Application Insights

Application Insights は AMPLS へ追加された Application Insights のインジェストエンドポイントとライブメトリックエンドポイントのIPアドレスを消費します。

以下のエンドポイントにそれぞれ IP アドレスが割り当てられます。

  1. <リージョン>-<ID>.in.ai.monitor.azure.com
  2. <リージョン>.livediagnostics.monitor.azure.com

基本的に Application Insights 1 リージョンに対して 2 つの IP アドレスが消費される認識で問題ありませんが、
1 つのリージョンに対して 2 つのインジェスト エンドポイントが定義されるケースもあります。

つまり、同じリージョンの Application Insights が既に追加されていた場合でも 1つ の IP アドレスが追加されたり、されない場合があります。

具体的に以下の様に、同じリージョンであっても <ID> 部分が異なる場合があります。

この2つの Application Insights を AMPLS へ追加した場合、3つの IP が追加されます。

  • 例1: InstrumentationKey=;IngestionEndpoint=https://japaneast-0.in.applicationinsights.azure.com/;LiveEndpoint=https://japaneast.livediagnostics.monitor.azure.com/;ApplicationId=
  • 例2: InstrumentationKey=;IngestionEndpoint=https://japaneast-1.in.applicationinsights.azure.com/;LiveEndpoint=https://japaneast.livediagnostics.monitor.azure.com/;ApplicationId=

接続文字列および <ID> 部は Application Insights リソース作成時に自動的に決められます。

Application Insights > 概要 より確認いただけます。
image

そのため、Application Insights では接続文字列内のエンドポイントを確認ください。

Q&A

Q. どの程度のIPレンジが必要になりますか？

A. お客様が将来的に AMPLS へ紐づけるリソースの数やそれらのリージョンによって必要な IP レンジは異なります。

追加される IP に対して、割り当て可能な IP レンジが不足した場合には、サブネットの再作成や VNET の再作成が必要になるケースもあります。

そのため冒頭に記載した計算式で計算いただき、その上で余裕のある数の IP レンジをご設定いただく事を推奨します。

]]> https://jpazmon-integ.github.io/blog/AMPLS/ampls-ip-ranges/ 2025-12-21T15:00:00.000Z [更新履歴]
-2025/12/22 ブログ公開
-2025/12/23 目次と各項目の修正

こんにちは、Azure Monitoring サポート チームの佐々木です。

今回の記事で]]>

AMPLS で必要な IP アドレスの個数について 2026-09-06T00:15:21.520Z Japan Azure Monitoring Support Team こんにちは、Azure Monitoring サポート チームの江口です。

今回は 2025 年 8 月に一般提供となった、ネットワーク セキュリティ境界 (Network Security Perimeter) についてこちらの記事を参考にご紹介します。

「ネットワーク セキュリティ境界とは何？どんなことができるの？」という方にぜひ読んでいただきたいです。


目次


ネットワーク セキュリティ境界とは

ネットワーク セキュリティ境界とは、仮想ネットワークの外部にデプロイされる PaaS リソースの周囲に確立できる論理ネットワーク境界で、複数の PaaS リソースに対して統一したパブリック ネットワークからのアクセス制御が行えます。

ネットワーク セキュリティ境界を作成することで、境界の内部と外部がネットワーク レベルで明確に区別され、セキュリティ保護された境界を確立することができます。

境界内部のリソース同士のアクセスはネットワーク レベルでは制御されず、従来通り、マネージド ID やロールベースのアクセス制御 (RBAC) によるアクセス管理が必要となります。

ネットワーク セキュリティ境界でサポートされている Azure Monitor のリソースを以下の表に示します。
詳細はこちら から確認できます。

リソースリソースの種類
データ収集エンドポイント (DCE)Microsoft.Insights/dataCollectionEndpoints
Log Analytics ワークスペースMicrosoft.OperationalInsights/workspaces
ログ クエリ アラートMicrosoft.Insights/ScheduledQueryRules
アクション グループMicrosoft.Insights/actionGroups
診断設定Microsoft.Insights/diagnosticSettings

Note

ネットワーク セキュリティ境界に Application Insights を関連付ける場合、作成時の [リソース] の選択で Application Insights リソースを直接選択することはできません。

代わりに、Application Insights リソースに使用される Log Analytics ワークスペースのネットワーク セキュリティ境界を構成します。

詳細については、下記の弊社公開情報をご参照ください。

ネットワーク セキュリティ境界で Azure Monitor を構成する


Azure Monitor リソース以外でサポートされているコンポーネントは、こちら から確認できます。


設定項目

このセクションでは、ネットワーク セキュリティ境界を作成する際に設定する内容を Azure Portal の画面で説明します。

設定する主要項目は以下の 3 つです。

1. 関連付けるリソース

ネットワーク セキュリティ境界に関連付ける PaaS リソースを選択します。

2. 受信アクセス規則

ネットワーク セキュリティ境界の外部から内部リソースへのアクセスに関する規則を定めます。

IP アドレスに基づくアクセス規則と、サブスクリプションに基づくアクセス規則を作成することができます。

IP アドレスに基づくアクセス規則は、下記のように受信トラフィックを許可するパブリック IP アドレス範囲を CIDR 形式で入力します。

例 ) 198.168.99.0/24
(IPv4 アドレス範囲で、198.168.99.0 から 198.168.99.255 までの 256 個の IP アドレスを含む)

3. 送信アクセス規則

ネットワーク セキュリティ境界の内部リソースから外部へのアクセスに関する規則を定めます。

下記のように FQDNs に基づくアクセス規則を作成します。

例 ) www.contoso.com

構成例

仮想マシン A から、ネットワーク セキュリティ境界に関連付けた Log Analytics ワークスペース X にログを送信し、そのログに基づいてログ検索アラート Y を発報する

1. 関連付けるリソースで Log Analytics ワークスペース X とログ検索アラート Y のアラート ルールを選択すると、それらのリソースがネットワーク セキュリティ境界に関連付けられ、境界内部のリソースとなります。

2. 受信アクセス規則で仮想マシン A のパブリック IP アドレスを入力することで、仮想マシン A からネットワーク セキュリティ境界へのアクセスがネットワーク レベルで許可されます。

仮想マシン A の Azure Monitor エージェントおよびロールベースのアクセス制限を従来通り正しく設定できていれば、以下が可能です。

  1. 仮想マシン A から Log Analytics ワークスペース X にログを送信する。

  2. ログ検索アラート Y が Log Analytics ワークスペース X を対象にクエリ検索し、条件に応じてアラートを発報する。

また、この場合、3. 送信アクセス規則を定めていないため、境界内部のリソースからパブリック ネットワークへのトラフィックはデフォルトでブロックされます。

ネットワーク セキュリティ境界を利用するその他のシナリオについてはこちらをご覧ください。


ネットワーク セキュリティ境界と Azure Monitor プライベート リンク スコープのできること/できないこと

Azure Monitor プライベート リンク スコープ (AMPLS) は、Azure Monitor の複数のリソースをまとめて、仮想ネットワークからプライベート接続するためのスコープです。

ネットワーク セキュリティ境界と AMPLS はいずれも Azure Monitor のリソースに対するセキュリティを高めるサービスですが、それぞれの役割が異なります。

簡潔に言えば、ネットワーク セキュリティ境界はパブリック ネットワークからのアクセスを制限し、AMPLS はプライベート ネットワークを構築します。

このセクションでは、ネットワーク セキュリティ境界と AMPLS のそれぞれのサービスで、できること/できないことを整理します。

ネットワーク セキュリティ境界

  • できること

セキュリティの強化と詳細なアクセス制御

明示的に受信アクセスと送信アクセスの規則を定義することで、境界内のリソースに対するパブリック ネットワークからの不正なアクセスを防止することができます。

特に、受信アクセス制御を IP アドレス範囲で、送信アクセス制御を特定の FQDNs に指定できるので、柔軟で詳細な制御が可能です。

一元的な管理

境界内のリソース同士の通信は制限されないため、境界内に複数の PaaS リソースをまとめて配置することで、明確で一元的なアクセス管理ができます。

ログの管理

ネットワーク セキュリティ境界によって許可または拒否されたすべての接続はログに記録されます。

これらのログは Log Analytics ワークスペースやストレージに送信でき、監査やコンプライアンス対応に有用です。

  • できないこと

ネットワーク セキュリティ境界だけでは、仮想ネットワークから PaaS リソースへのパブリック ネットワークを介さないプライベートな接続を構成することはできません。


AMPLS

  • できること

プライベートな接続の構築

仮想ネットワークから複数の Azure Monitor リソースへのプライベートなアクセスをまとめて構成し、すべてのトラフィックを Azure のバックボーン ネットワーク内に完結することができます。

  • できないこと

仮想ネットワークから Azure Monitor リソースへのアクセスは保護されるものの、Azure Monitor のサービス エンドポイント自体は依然としてパブリック ネットワーク経由でアクセス可能です。

また、AMPLS に紐づけることができるリソースは Log Analytics ワークスペース、Application Insights、データ収集エンドポイント (DCE) の Azure Monitor リソースに限られています。

AMPLS に接続するリソースについての詳細は、こちらをご参照ください。


上記のように、ネットワーク セキュリティ境界と AMPLS では役割や利用する目的が異なります。

両者を併用することで、防御の多層化を実現し、より安全なネットワークを構成することもできます。

まとめ

この記事では、以下の 3 点についてまとめました。

  • ネットワーク セキュリティ境界とは何か
  • 作成する際に何を設定するのか
  • ネットワーク セキュリティ境界と Azure Monitor プライベート リンク スコープはそれぞれ何ができるのか

本記事がご理解の助けとして、お役立ていただければ幸いです。

最後までお読みいただきありがとうございました。

]]> https://jpazmon-integ.github.io/blog/LogAnalytics/NetworkSecurityPerimeter/ 2025-09-19T07:00:00.000Z こんにちは、Azure Monitoring サポート チームの江口です。

今回は 2025 年 8 月に一般提供となった、ネットワーク セキュリティ境界 (Network Security Perimeter) についてこちらの記事を参考にご紹介します。

「ネットワーク セキュリティ境界とは何？どんなことができるの？」という方にぜひ読んでいただきたいです。

]]> ネットワーク セキュリティ境界とは 2026-09-06T00:15:21.928Z Japan Azure Monitoring Support Team こんにちは、Azure Monitoring サポート チームの江口です。

今回はログ検索アラートのマネージド ID についてご紹介します。

「ログ検索アラートではマネージド ID の設定ができるけど、これはなんのためにあるの？」 こんな疑問を持っている方にぜひ読んでいただきたいです。

目次

マネージド ID とは

マネージド ID は、Azure が提供する自動管理された認証システムで、Azure リソースから他のリソースへのアクセスを管理するために使用されます。

アラート ルールをはじめとする一部の Azure リソースにマネージド ID を割り当てることで、他のリソースへのアクセス権限をリソースごとに管理できます。

ログ検索アラートにマネージド ID を割り当てる

このセクションでは、アラートルールを作成/編集する際にどこでマネージド ID を設定するのかについて、Azure Portal での操作を説明します。

クエリによる検索を必要とするログ検索アラートに対しては、他のリソースへのアクセスを管理するため、マネージド ID を割り当てることができます。

  1. アラート ルールの作成の [条件] で以下のように [カスタムログ検索] を選択します。

  1. [詳細] の [ID] の項目に、以下の画面が表示されます。ここでマネージド ID についての設定を行うことができます。

[既定]、[システム割り当てマネージド ID]、[ユーザー割り当てマネージド ID] の違い

このセクションでは、マネージド ID の設定の際に選択する [既定]、[システム割り当てマネージド ID]、[ユーザー割り当てマネージド ID] の 3 つの項目について説明します。

1. 既定

アラート ルールのアクセス権限は、アラート ルールを編集した最後のユーザーのアクセス権限に基づきます。 マネージド ID は割り当てられません。

例として以下のシナリオを考えます。

シナリオ

A さんと B さんがいて、ID の設定で [既定] を選択しているログ検索アラート X を編集したいと考えている。

それぞれに割り当てられているアクセス権限のロールは以下である。

A さん： 「ログ検索アラート X の共同作成者ロール」および、「クエリ検索を行う Log Analytics ワークスペース Y の閲覧者ロール」。

B さん： 「ログ検索アラート X の共同作成者ロール」のみ。

A さんが編集

まず初めに、A さんがログ検索アラート X を編集すると、ログ検索アラート X のアクセス権限は A さんのアクセス権限に基づきます。

つまり、ログ検索アラート X は「ログ検索アラート X の共同作成者ロール」および、「Log Analytics ワークスペース Y の閲覧者ロール」が割り当てられます。

そのため、ログ検索アラート X は Log Analytics ワークスペース Y に対してクエリ検索を行う権限があり、ログ検索アラートはアラート条件に従って期待通り発報します。

B さんが編集

その後、B さんがログ検索アラート X を編集すると、ログ検索アラート X のアクセス権限は B さんのアクセス権限に基づくように変更されます。

つまり、ログ検索アラート X は「ログ検索アラート X の共同作成者ロール」のみが割り当てることになり、「Log Analytics ワークスペース Y の閲覧者ロール」を失います。

そのため、ログ検索アラート X は Log Analytics ワークスペース Y に対してクエリ検索を行う権限がなくなり、その後はログ検索アラートが期待通りに発報しなくなります。

2. システム割り当てマネージド ID

作成/編集しているアラート ルールに対して専用のマネージド ID が割り振られます。

割り振られたマネージド ID のライフサイクルはアラート ルールのそれと対応するため、アラート ルールが削除されると紐づけられたマネージド ID も削除されます。

アラート ルールの作成/編集後、システム割り当てマネージド ID に対して、Log Analytics ワークスペースのクエリ検索の権限を付与する必要があります。

マネージド ID に対するロールの割り当ては、該当の Log Analytics ワークスペースの アクセス制御 > ロール割り当ての追加 から行えます。

[メンバー] の [アクセス割り当て先] の項目で [マネージド ID] を選び、メンバーを選択することで、特定のマネージド ID に対して特定のロールを付与することができます。

Log Analytics ワークスペースにクエリ検索を行う場合に付与するロールとしては、[Log Analytics 閲覧者] などが該当します。

Azure Monitor に関するそれぞれのロールの詳細についてはこちらをご参照ください。

3. ユーザー割り当てマネージド ID

1 つ以上のリソースに対して同一のマネージド ID を割り振ることができます。

アラート ルールとは独立したリソースとしてマネージド ID を事前に作成し、マネージド ID に対して Log Analytics ワークスペースのクエリ検索可能な権限を付与した後に、アラート ルールのマネージド ID の設定項目で該当のユーザー割り当てマネージド ID を選択する必要があります。

独立したリソースであるため、アラート ルールが削除されても、ユーザー割り当てマネージド ID は削除されません。

ユーザー割り当てマネージド ID は、ホームから マネージド ID > 作成 にて作成できます。

ただし、ユーザー割り当てマネージド ID を作成するためには、作成者に [マネージド ID 共同作成者] のロールが付与されていることが必要です。

マネージド ID に対するロールの割り当てについては、2. システム割り当てマネージド ID を参照してください。



以上 3 つの項目については以下の弊社公開情報にも記載がございますので、ご参照ください。

  • ログ検索アラート ルールを作成または編集する # アラート ルールの詳細を構成する

https://learn.microsoft.com/ja-jp/azure/azure-monitor/alerts/alerts-create-log-alert-rule#configure-alert-rule-details

  • Azure リソースのマネージド ID とは # マネージド ID の種類

https://learn.microsoft.com/ja-jp/entra/identity/managed-identities-azure-resources/overview#managed-identity-types

マネージド ID を使うメリット

ここまでの内容を踏まえ、マネージド ID を利用することの利点を以下の 3 点に分けて説明します。

1. アクセス権限の明確化

マネージド ID を使用することで、他のリソースへのアクセス制御を ID 単位で一元管理できます。

[既定] の例で紹介したように、アラート ルールのアクセス権限が最終編集者の権限に依存すると、編集するたびにアラート ルールのアクセス権限が変更される可能性があります。

割り当てられたロールによっては Log Analytics ワークスペースのクエリ検索が行えなくなり、アラートが期待通り発報しなくなってしまうこともあります。

マネージド ID ごとにロールを付与することで、各リソースのアクセス権限を一貫して明確なものとすることができます。

2. 最小権限の原則の実装

マネージド ID を使用することで、各リソースの他のリソースに対するアクセス権限を必要最低限とし、セキュリティ リスクを軽減することができます。

各リソースに対するロールの割り当てとして、最小権限を実現するように柔軟に設定することで、「何のリソースが」「どのスコープに」「何ができるのか」を管理できます。

3. 他のサービスとの統合

Azure Data Explorer または Resource Graph にクエリを送信する場合は、マネージド IDが必須です。

各サービスからマネージド ID に対して適切なロールを割り当てることで、他のサービスとの統合によってよりシームレスな利用が可能となります。

Azure Data Explorer と Resource Graph に対するマネージド ID の利用については下記の弊社公開情報をご参照ください。

  • マネージド ID の概要

https://learn.microsoft.com/ja-jp/azure/data-explorer/managed-identities-overview

  • クイックスタート: Azure Resource Graph と Log Analytics を使用してアラートを作成する

https://learn.microsoft.com/ja-jp/azure/governance/resource-graph/alerts-query-quickstart?tabs=azure-resource-graph

まとめ

この記事では、以下の 3 点についてまとめました。

  • ログ検索アラートにマネージド ID を割り当てる方法
  • マネージド ID の設定による権限管理方法の違い
  • マネージド ID を利用するメリット

本記事がご理解の助けとして、お役立ていただければ幸いです。

最後までお読みいただきありがとうございました。

]]> https://jpazmon-integ.github.io/blog/AzureMonitorEssential/LogAlert_ManagedId/ 2025-09-12T07:00:00.000Z こんにちは、Azure Monitoring サポート チームの江口です。

今回はログ検索アラートのマネージド ID についてご紹介します。

「ログ検索アラートではマネージド ID の設定ができるけど、これはなんのためにあるの？」 こんな疑問を持っている方にぜひ読んでいただきたいです。

]]> ログ検索アラートのマネージド ID について 2026-09-06T00:15:21.627Z Japan Azure Monitoring Support Team [更新履歴]

  • 2025/9/12 ブログ公開
  • 2025/11/25 代替機能に関する追記

重要

今後は本機能ではなく、代替機能のご利用を推奨しております。

コスト削減を目的にストレージ アカウントへの直接的なデータ送信をご検討される場合、代わりに、Log Analytics ワークスペースの補助プラン の活用をご検討ください。

また、Event Hub への直接的なデータ送信については、VM ウォッチを用いたEvent Hub へのデータ送信 をご検討ください。

こんにちは、Azure Monitoring チームの徳田です。
本記事では、Azure Monitor Agent (AMA) を使用することで、仮想マシン (VM) から収集したデータを Event Hub やストレージ アカウントに直接データを送信する方法についてご紹介します。

仮想マシン クライアント データを Event Hubs と Storage に送信する (プレビュー)

目次

概要

Azure Monitor Agent (AMA) を使用することで、仮想マシン (VM) から収集したデータを Event Hub やストレージ アカウントに直接データを送信できます。
この機能により、Azure Monitor Logs (Log Analytics ワークスペース) 以外の外部システムにもデータを転送することが可能になります。


なお、この機能は従来の Windows Azure Diagnostics (WAD) や Linux Azure Diagnostics (LAD) の後継として提供されています。

本ブログでは、以下弊社公開情報に記載の内容を含め、当該機能の利用手順およびログが収集できない場合の主なトラブルシューティング方法についてご紹介します。

仮想マシン クライアント データを Event Hubs と Storage に送信する (プレビュー)

Note

WAD/LAD からの移行に関しては、こちらのブログ「Retirement notice ： Migrate to Azure Monitor Agent before 31 March 2026 について」 をご参照ください。

※ 本機能は 2025 年 9 月時点でパブリック プレビュー段階となっております。
そのため、今後、手順や機能の詳細が変更される可能性がございます。
また、ごくまれに GA できずそのまま廃止される可能性もあること、予めご留意いただきますようお願いいたします。

前提条件

以降の手順を実行する前に、以下をご確認ください。

  • 送信先となる Event Hub または Storage Account がある。
  • ログ収集対象となる VM がある。
  • ログ収集対象となる VM にマネージド ID (システム割り当てまたはユーザー割り当て) が割り当てられている。

手順

1. VM のマネージド ID への必要なロールの割り当て

必要なロールの確認

AMA が Event Hub やストレージ アカウントにデータを送信するために、VM に割り当てられているマネージド ID に適切なロールを割り当てる必要があります。

各宛先へのログ収集に必要なロールは以下の通りです。


宛先必要な組み込みロール
ストレージ テーブルStorage Table Data Contributor (ストレージ テーブル データ共同作成者)
ストレージ BLOBStorage Blob Data Contributor (ストレージ BLOB データ共同作成者)
Event HubAzure Event Hubs Data Sender (Azure Event Hubs のデータ送信者)

ロールの割り当て手順

1-1. Azure portal でロールを割り当てる宛先またはその宛先を含むスコープ (リソース グループやサブスクリプション) を開きます。


1-2. 左ペインの [アクセス制御 (IAM)] を開き、[追加] > [ロールの割り当ての追加] を押下します。


1-3. [ロール] タブで、先ほど確認した必要なロールを検索し、押下します。


1-4. [メンバー] タブに移動し、”アクセスの割り当て先” に “マネージド ID” を選択し、その下の [メンバーの追加] を押下します。


1-5. 右ペインに “マネージド ID の選択” が表示されるため、ここで、ログ収集対象の VM に割り当てられているマネージド ID を選択し、[選択] を押下します。

※ 上記の通り、マネージド ID ごとにロールを付与する必要があるため、多数台の VM で当該機能を利用される場合は、ユーザー割り当てマネージド ID のご利用が効果的です。


1-6.
必要に応じて [条件] および [割り当てのタイプ] タブを編集し、[レビューと割り当て] タブで問題がないことを確認したら、[レビューと割り当て] を押下し、割り当てが完了するまでお待ちください。



2. データ収集ルール (DCR) の作成

DCR で、どのデータをどこに送信するかを定義します。
2025 年 9 月段階では、当該機能を使用するための DCR は ARM テンプレートからのみ作成可能です。

重要

既存の DCR (Log Analytics ワークスペースや Azure Monitor Metrics に収集するための DCR) と、当該機能を利用するための DCR は分けてご用意ください。

以下弊社公開情報にて、Windows および Linux 用の ARM テンプレートのサンプルをご紹介しております。
こちらをもとに、収集したいログの種類および宛先のご要件に合わせて修正し、ARM テンプレートをデプロイしてください。


仮想マシン クライアント データを Event Hubs と Storage に送信する (プレビュー) | データ収集ルールを作成する


参考: ARM テンプレートの詳細な記述方法については、以下弊社公開情報も併せてご参照ください。
Microsoft.Insights dataCollectionRules



3. VM と DCR の関連付け

作成した DCR と VM を関連付けます。
以下の 2 つのパターンに分けて説明します。
Azure Monitor エージェントのインストール状況に合わせていずれかの手順をご確認ください。

3-1. AMA インストール済みの場合

以下の順番で進めてください。

  • Azure Monitor エージェントの認証設定
  • データ収集ルール (DCR) と VM の関連付けのデプロイ

3-1-1. Azure Monitor エージェントの認証設定

はじめに、Azure Monitor エージェントに認証情報が設定されている必要があります。
現在の設定状況は、Azure portal でエージェントがインストールされている VM を開き、[概要] > [JSON ビュー] で確認することができます。

(ユーザー割り当てマネージド ID での認証設定が行われている場合の例)

(認証設定が追加されていない場合の例)

また、以下のコマンドでも確認が可能です。

1
2
3
4
Get-AzVMExtension `
-ResourceGroupName <リソース グループ名> `
-VMName <VM 名> `
-Name "<拡張機能名>" # AzureMonitorWindowsAgent や AzureMonitorLinuxAgent

(ユーザー割り当てマネージド ID での認証設定が行われている場合の例)

認証情報が追加されていない場合は、ログ収集元の VM が使用しているマネージド ID の種類に合わせ、認証情報を設定してください。
例として、以下の Azure PowerShell コマンドのように SettingString パラメーターを指定し、認証情報を追加することができます。

ユーザー割り当てマネージド ID を使用する場合 (Windows)

1
2
3
4
5
6
7
8
9
10
Set-AzVMExtension `
-Name AzureMonitorWindowsAgent `
-ExtensionType AzureMonitorWindowsAgent `
-Publisher Microsoft.Azure.Monitor `
-ResourceGroupName <リソース グループ名> `
-VMName <VM 名> `
-Location <リージョン名> `
-TypeHandlerVersion <バージョン> `
-EnableAutomaticUpgrade $true `
-SettingString '{"authentication": {"managedIdentity": {"identifier-name": "mi_res_id", "identifier-value": "<ユーザー割り当てマネージド ID のリソース ID>"}}}'

システム割り当てマネージド ID を使用する場合 (Windows)

1
2
3
4
5
6
7
8
9
10
Set-AzVMExtension `
-Name AzureMonitorWindowsAgent `
-ExtensionType AzureMonitorWindowsAgent `
-Publisher Microsoft.Azure.Monitor `
-ResourceGroupName <リソース グループ名> `
-VMName <VM 名> `
-Location <リージョン名> `
-TypeHandlerVersion <バージョン> `
-EnableAutomaticUpgrade $true `
-SettingString '{"authentication": {"managedIdentity": {"identifier-name": "client_id", "identifier-value": "<アプリケーション ID>"}}}'

※ Linux の場合は、-Name AzureMonitorLinuxAgent, -ExtensionType AzureMonitorLinuxAgent とご変更ください。
※ 上記コマンドの <ユーザー割り当てマネージド ID のリソース ID> は、Azure portal で対象のユーザー割り当てマネージド ID を開き、[概要] ページ右上の [JSON ビュー] の “リソース ID” よりご確認いただけます。
こちらの点については以下弊社公開情報も併せてご参照ください。
サブスクリプション ID とリソース ID の確認について

※ 上記コマンドの <アプリケーション ID> の箇所は、以下の方法で確認可能です。

  1. Azure portal で “Entra ID” を検索し、[エンタープライズ アプリケーション] を開きます。

  2. [管理] > [すべてのアプリケーション] を開き、”アプリケーションの種類” を “マネージド ID” でフィルタリングします。

  3. 確認対象のマネージド ID が割り当てられている VM 名を検索し、押下してください。

  4. “アプリケーション ID” に表示されている値をご確認ください。


3-1-2. データ収集ルール (DCR) と VM の関連付けのデプロイ

Azure Monitor エージェントの認証情報の設定が完了したら、ARM テンプレートを使用して DCR と VM の関連付けをデプロイしてください。
以下は関連付けのためのサンプルのテンプレートとなるため、内容についてはご要件に合わせて適宜変更ください。

サンプル ARM テンプレート

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
    "vmName": {
    "defaultValue": "[concat(resourceGroup().name, 'vm')]",
    "type": "String"
    },
    "dataCollectionRulesName": {
    "defaultValue": "[concat(resourceGroup().name, 'DCR')]",
    "type": "String",
    "metadata": {
        "description": "Data Collection Rule Name"
    }
    },
    "dcraName": {
    "type": "string",
    "defaultValue": "[concat(uniquestring(resourceGroup().id), 'DCRLink')]",
    "metadata": {
        "description": "Name of the association."
    }
    }
},
"resources": [
    {
    "type": "Microsoft.Compute/virtualMachines/providers/dataCollectionRuleAssociations",
    "name": "[concat(parameters('vmName'),'/microsoft.insights/', parameters('dcraName'))]",
    "apiVersion": "2021-04-01",
    "properties": {
        "description": "Association of data collection rule. Deleting this association will break the data collection for this virtual machine.",
        "dataCollectionRuleId": "[resourceID('Microsoft.Insights/dataCollectionRules',parameters('dataCollectionRulesName'))]"
    }
    }
]
}

3-2. AMA 未インストールの場合

以下サンプルのような ARM テンプレートをデプロイすることで、DCR と VM の関連付けと、VM への Azure Monitor エージェントのインストールを両方行うことができます。
サンプルのテンプレートとなるため、内容についてはご要件に合わせて適宜変更ください。

ユーザー割り当てマネージド ID を使用する場合
- Windows の場合

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
    "vmName": {
    "defaultValue": "[concat(resourceGroup().name, 'vm')]",
    "type": "String"
    },
    "location": {
    "type": "string",
    "defaultValue": "[resourceGroup().location]",
    "metadata": {
        "description": "Location for all resources."
    }
    },
    "dataCollectionRulesName": {
    "defaultValue": "[concat(resourceGroup().name, 'DCR')]",
    "type": "String",
    "metadata": {
        "description": "Data Collection Rule Name"
    }
    },
    "dcraName": {
    "type": "string",
    "defaultValue": "[concat(uniquestring(resourceGroup().id), 'DCRLink')]",
    "metadata": {
        "description": "Name of the association."
    }
    },
    "identityName": {
    "type": "string",
    "metadata": {
        "description": "Name of User-assigned Managed Identity"
    }
    }
},
"resources": [
    {
    "type": "Microsoft.Compute/virtualMachines/providers/dataCollectionRuleAssociations",
    "name": "[concat(parameters('vmName'),'/microsoft.insights/', parameters('dcraName'))]",
    "apiVersion": "2021-04-01",
    "properties": {
        "description": "Association of data collection rule. Deleting this association will break the data collection for this virtual machine.",
        "dataCollectionRuleId": "[resourceID('Microsoft.Insights/dataCollectionRules',parameters('dataCollectionRulesName'))]"
    }
    },
    {
    "type": "Microsoft.Compute/virtualMachines/extensions",
    "name": "[concat(parameters('vmName'), '/AzureMonitorWindowsAgent')]",
    "apiVersion": "2020-06-01",
    "location": "[parameters('location')]",
    "dependsOn": [
        "[resourceId('Microsoft.Compute/virtualMachines/providers/dataCollectionRuleAssociations', parameters('vmName'), 'Microsoft.Insights', parameters('dcraName'))]"
    ],
    "properties": {
        "publisher": "Microsoft.Azure.Monitor",
        "type": "AzureMonitorWindowsAgent",
        "typeHandlerVersion": "1.0",
        "autoUpgradeMinorVersion": true,
        "settings": {
        "authentication": {
            "managedIdentity": {
            "identifier-name": "mi_res_id",
            "identifier-value": "[resourceID('Microsoft.ManagedIdentity/userAssignedIdentities/',parameters('identityName'))]"
            }
        }
        }
    }
    }
]
}

- Linux の場合

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
    "vmName": {
    "defaultValue": "[concat(resourceGroup().name, 'vm')]",
    "type": "String"
    },
    "location": {
    "type": "string",
    "defaultValue": "[resourceGroup().location]",
    "metadata": {
        "description": "Location for all resources."
    }
    },
    "dataCollectionRulesName": {
    "defaultValue": "[concat(resourceGroup().name, 'DCR')]",
    "type": "String",
    "metadata": {
        "description": "Data Collection Rule Name"
    }
    },
    "dcraName": {
    "type": "string",
    "defaultValue": "[concat(uniquestring(resourceGroup().id), 'DCRLink')]",
    "metadata": {
        "description": "Name of the association."
    }
    },
    "identityName": {
    "type": "string",
    "metadata": {
        "description": "Name of User-assigned Managed Identity"
    }
    }
},
"resources": [
    {
    "type": "Microsoft.Compute/virtualMachines/providers/dataCollectionRuleAssociations",
    "name": "[concat(parameters('vmName'),'/microsoft.insights/', parameters('dcraName'))]",
    "apiVersion": "2021-04-01",
    "properties": {
        "description": "Association of data collection rule. Deleting this association will break the data collection for this virtual machine.",
        "dataCollectionRuleId": "[resourceID('Microsoft.Insights/dataCollectionRules',parameters('dataCollectionRulesName'))]"
    }
    },
    {
    "type": "Microsoft.Compute/virtualMachines/extensions",
    "name": "[concat(parameters('vmName'), '/AzureMonitorLinuxAgent')]",
    "apiVersion": "2020-06-01",
    "location": "[parameters('location')]",
    "dependsOn": [
        "[resourceId('Microsoft.Compute/virtualMachines/providers/dataCollectionRuleAssociations', parameters('vmName'), 'Microsoft.Insights', parameters('dcraName'))]"
    ],
    "properties": {
        "publisher": "Microsoft.Azure.Monitor",
        "type": "AzureMonitorLinuxAgent",
        "typeHandlerVersion": "1.0",
        "autoUpgradeMinorVersion": true,
        "settings": {
        "authentication": {
            "managedIdentity": {
            "identifier-name": "mi_res_id",
            "identifier-value": "[resourceID('Microsoft.ManagedIdentity/userAssignedIdentities/',parameters('identityName'))]"
            }
        }
        }
    }
    }
]
}

システム割り当てマネージド ID を使用する場合
- Windows の場合

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
    "vmName": {
    "defaultValue": "[concat(resourceGroup().name, 'vm')]",
    "type": "String"
    },
    "location": {
    "type": "string",
    "defaultValue": "[resourceGroup().location]",
    "metadata": {
        "description": "Location for all resources."
    }
    },
    "dataCollectionRulesName": {
    "defaultValue": "[concat(resourceGroup().name, 'DCR')]",
    "type": "String",
    "metadata": {
        "description": "Data Collection Rule Name"
    }
    },
    "dcraName": {
    "type": "string",
    "defaultValue": "[concat(uniquestring(resourceGroup().id), 'DCRLink')]",
    "metadata": {
        "description": "Name of the association."
    }
    },
    "applicationId": {
    "type": "string",
    "metadata": {
        "description": "System Assigned Managed Identity"
    }
    }
},
"resources": [
    {
    "type": "Microsoft.Compute/virtualMachines/providers/dataCollectionRuleAssociations",
    "name": "[concat(parameters('vmName'),'/microsoft.insights/', parameters('dcraName'))]",
    "apiVersion": "2021-04-01",
    "properties": {
        "description": "Association of data collection rule. Deleting this association will break the data collection for this virtual machine.",
        "dataCollectionRuleId": "[resourceID('Microsoft.Insights/dataCollectionRules',parameters('dataCollectionRulesName'))]"
    }
    },
    {
    "type": "Microsoft.Compute/virtualMachines/extensions",
    "name": "[concat(parameters('vmName'), '/AzureMonitorWindowsAgent')]",
    "apiVersion": "2020-06-01",
    "location": "[parameters('location')]",
    "dependsOn": [
        "[resourceId('Microsoft.Compute/virtualMachines/providers/dataCollectionRuleAssociations', parameters('vmName'), 'Microsoft.Insights', parameters('dcraName'))]"
    ],
    "properties": {
        "publisher": "Microsoft.Azure.Monitor",
        "type": "AzureMonitorWindowsAgent",
        "typeHandlerVersion": "1.0",
        "autoUpgradeMinorVersion": true,
        "settings": {
        "authentication": {
            "managedIdentity": {
            "identifier-name": "client_id",
            "identifier-value": "parameters('applicationId')"
            }
        }
        }
    }
    }
]
}

- Linux の場合

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
    "vmName": {
    "defaultValue": "[concat(resourceGroup().name, 'vm')]",
    "type": "String"
    },
    "location": {
    "type": "string",
    "defaultValue": "[resourceGroup().location]",
    "metadata": {
        "description": "Location for all resources."
    }
    },
    "dataCollectionRulesName": {
    "defaultValue": "[concat(resourceGroup().name, 'DCR')]",
    "type": "String",
    "metadata": {
        "description": "Data Collection Rule Name"
    }
    },
    "dcraName": {
    "type": "string",
    "defaultValue": "[concat(uniquestring(resourceGroup().id), 'DCRLink')]",
    "metadata": {
        "description": "Name of the association."
    }
    },
    "applicationId": {
    "type": "string",
    "metadata": {
        "description": "System Assigned Managed Identity"
    }
    }
},
"resources": [
    {
    "type": "Microsoft.Compute/virtualMachines/providers/dataCollectionRuleAssociations",
    "name": "[concat(parameters('vmName'),'/microsoft.insights/', parameters('dcraName'))]",
    "apiVersion": "2021-04-01",
    "properties": {
        "description": "Association of data collection rule. Deleting this association will break the data collection for this virtual machine.",
        "dataCollectionRuleId": "[resourceID('Microsoft.Insights/dataCollectionRules',parameters('dataCollectionRulesName'))]"
    }
    },
    {
    "type": "Microsoft.Compute/virtualMachines/extensions",
    "name": "[concat(parameters('vmName'), '/AzureMonitorLinuxAgent')]",
    "apiVersion": "2020-06-01",
    "location": "[parameters('location')]",
    "dependsOn": [
        "[resourceId('Microsoft.Compute/virtualMachines/providers/dataCollectionRuleAssociations', parameters('vmName'), 'Microsoft.Insights', parameters('dcraName'))]"
    ],
    "properties": {
        "publisher": "Microsoft.Azure.Monitor",
        "type": "AzureMonitorLinuxAgent",
        "typeHandlerVersion": "1.0",
        "autoUpgradeMinorVersion": true,
        "settings": {
        "authentication": {
            "managedIdentity": {
            "identifier-name": "client_id",
            "identifier-value": "parameters('applicationId')"
            }
        }
        }
    }
    }
]
}

トラブルシューティング

当該機能によるログ収集が行われない場合のよくある要因は以下です。
もしログ収集が行われない場合、まずは以下の状況に当てはまらないかをご確認ください。

適切なロールがマネージド ID に付与されていない
1. VM のマネージド ID への必要なロールの割り当て に記載の通り、VM のマネージド ID に、宛先に応じたロールを付与する必要があります。
付与されているかどうかは、宛先リソースを Azure portal で開き、[アクセス制御 (IAM)] より、[ロールの割り当て] タブで確認することが可能です。

(ストレージ アカウントのロールの割り当て一覧の例)

必要なロールがマネージド ID に割り当てられていなかった場合は、1. VM のマネージド ID への必要なロールの割り当て を参照の上、ロールの割り当てを行ってください。


Azure Monitor エージェントに認証設定が行われていない
Azure Monitor エージェントに認証設定が追加されていない場合、ログを送信することができません。
Azure Monitor エージェントの認証設定 を参照の上、認証設定されているかの確認、およびされていない場合は設定の追加を実施してください。

ログの収集が開始していない/ログが出力されていない
必要な手順の実施が完了してから、実際にエージェントから各種宛先にログが収集されるまでに多少の時差が生じます。
念のため、手順から 30 分 ~ 1 時間ほどお待ちいただいた上でログの収集状況をご確認ください。
また、カスタム ログや Windows イベント ログなど、定期的に出力されないログについては、出力元で収集対象のログが出力されているかをご確認ください。


まとめ

Azure Monitor Agent (AMA) を使用し、従来の WAD/LAD に代わって VM のデータをEvent Hub や Storage Account に送信する方法についてご紹介しました。
本記事が WAD および LAD から AMA への移行を検討される方のお役に立てば幸いです。

]]> https://jpazmon-integ.github.io/blog/LogAnalytics/HowToSendVMDataToEventHubAndStorage/ 2025-09-11T15:00:00.000Z [更新履歴]

  • 2025/9/12 ブログ公開
  • 2025/11/25 代替機能に関する追記

[!IMPORTANT]
今後は本機能ではなく、代替機能のご利用を推奨しております。
コスト削減を目的にストレージ アカウントへの直接的なデータ送信をご検討される場合、代わりに、Log Analytics ワークスペースの補助プラン の活用をご検討ください。
また、Event Hub への直接的なデータ送信については、VM ウォッチを用いたEvent Hub へのデータ送信 をご検討ください。

こんにちは、Azure Monitoring チームの徳田です。
本記事では、Azure Monitor Agent (AMA) を使用することで、仮想マシン (VM) から収集したデータを Event Hub やストレージ アカウントに直接データを送信する方法についてご紹介します。

仮想マシン クライアント データを Event Hubs と Storage に送信する (プレビュー)

]]> 【非推奨】AMA を使用して VM のデータを Event Hub とストレージ アカウントに送信する方法 2026-09-06T00:15:21.855Z Japan Azure Monitoring Support Team こんにちは、Azure Monitoring サポート チームの六浦です。

今回は Log Analytics でクエリを実行する際のコストについてご説明します。

目次


1. クエリ実行のコストに関わる設定の確認

Azure ポータルの Log Analytics ワークスペースの [設定] > [テーブル] より、クエリを実行するテーブルの以下の設定を確認します。

設定設定可能な値
プランAnalytics、基本、補助 のいずれかです。
Analytics のリテンション期間最大 2 年まで設定できます。
保有期間の合計最大 12 年まで設定できます。

これらの設定によって、クエリ実行時のコストが決まります。


2. Analytics のリテンション期間のログに対してクエリを実行する場合

1. クエリ実行のコストに関わる設定の確認 の [プラン] によってクエリの実行コストは異なります。


2-1. Analytics テーブル プランの場合

無料でクエリを実行できます。
Analytics テーブル プランはデフォルトのテーブル プランのため、多くのテーブルに該当します。


2-2. 基本 (Basic) テーブル プランと補助 (Auxiliary) テーブル プランの場合

クエリ実行時にスキャンしたデータ量に応じたコストが発生します。
料金は価格についての公開情報の [クエリ] からご確認ください。

例えば、2 GB のデータに対してクエリを実行した際のコストは以下の式で算出できます。
$0.00725 * 2 GB = $0.0145
※ 計算には東日本リージョンの従量課金制の USD 価格を利用しています

なお、基本および補助テーブルのログに対して実行できるクエリには制限があります。
制限については、こちらをご確認ください。

Note

Basic テーブル プランは一部のテーブルで利用できます。対象のテーブルはこちらを確認ください。

Auxiliary テーブル プランは DCR ベースのカスタム テーブルのみで利用できます。

テーブル プランの詳細についてはこちらの公開情報もご確認ください。


3. 長期保持 (アーカイブ) 期間のログに対してクエリを実行する場合

長期保持期間は、1. クエリ実行のコストに関わる設定の確認の [保有期間の合計] から [Analytics のリテンション期間] を引いた期間です。
長期保持期間のログに対するクエリ実行には、テーブル プランに関わらず、検索ジョブの実行、またはログの復元のコストがかかります。
なお、検索ジョブで作成される結果テーブルのログと復元されたログは、Analytics テーブル プランのログのため、クエリ実行による追加のコストは発生しません。

Note

現在 Auxiliary テーブル プランは復元をサポートしません。Auxiliary テーブルから長期保持されているデータを取得するには、検索ジョブをご利用ください。


3-1. 検索ジョブのコスト

検索ジョブは、「スキャンされたデータのコスト」と「検索結果の取り込みのコスト」が発生します。
「スキャンされたデータのコスト」は、価格についての公開情報の [ジョブの検索] の価格です。
「検索結果の取り込みのコスト」は価格についての公開情報 の [インジェスト] の Analytics ログの価格です。

例えば、1000 GB のログを検索ジョブでスキャンして、100 GB の結果を得た際のコストは以下のように計算できます。
$0.00725 * 1000 GB + $3.34 * 100 GB = $341.25

※ 計算には東日本リージョンの従量課金制の USD 価格を利用しています。


3-2. 復元のコスト

復元のコストは、価格についての公開情報の [復元] をご確認ください。

復元のコストの計算には 2 つの注意点があります。

  • 復元したデータを 12 時間未満保持した際、12 時間に保持したとして計算します。
  • 2 TB 未満のデータを復元した際、データ量は 2 TB に切り上げて計算します。

つまり、復元には少なくとも 2 TB (2000 GB) を 12 時間保持する下記のコストが発生します。
$0.145 * 2000 GB * 12/24 (日) = $145

他にもいくつか例をご紹介します。

  • 1 TB のデータを 1 日保持した場合
    $0.145 * 2000 GB * 1 (日) = $290
    1 TB は 2 TB に切り上げられます。

  • 2 TB のデータを 13 時間保持した場合
    $0.145 * 2000 GB * 13/24 (日) = $157.09
    復元したデータを保持する期間は時間単位で課金されます。

  • 3 TB のデータを 2 日間保持した場合
    $0.145 * 3000 GB * 2 (日) = $870

※ 計算には東日本リージョンの従量課金制の USD 価格を利用しています


4. まとめ

本記事では、クエリ実行時のコストについてご案内いたしましたが、いかがでしたでしょうか。
Log Analytics ワークスペースのその他のコストについてはこれらの公開情報にてご案内しておりますので、合わせてご覧ください。
Azure Monitor ログのコストの計算とオプション
Log Analytics ワークスペースのコスト増加の原因を分析しコスト削減を検討する

最後までお読みいただきありがとうございました！

]]> https://jpazmon-integ.github.io/blog/LogAnalytics/LogAnalyticsQueryPricing/ 2025-09-02T15:00:00.000Z こんにちは、Azure Monitoring サポート チームの六浦です。

今回は Log Analytics でクエリを実行する際のコストについてご説明します。

]]> Log Analytics のクエリの実行コストについて 2026-09-06T00:15:21.864Z Japan Azure Monitoring Support Team こんにちは、Azure Monitoring サポート チームの北村、徳田です。
今回は Azure Monitor のアラート ルールが発報した原因の調査をご依頼いただく際に、事前にご確認いただきたいポイントをご紹介します。

目次


1. はじめに

「Azure Monitor のアラート ルールが発報した原因を調査してほしい」というお問い合わせをよくいただきますが、
アラート ルールの閾値を満たして発報したのか、それとも閾値を満たしていないにもかかわらず発報されたのかによって、
調査の観点が異なります。

アラート ルールが発報した経緯調査観点
アラート ルールが閾値を満たして発報した場合Azure リソース観点
アラート ルールが閾値を満たしていないものの発報した場合アラート ルール観点

閾値を満たして発報した場合は、監視している Azure リソースに何らかの問題が発生していた可能性があるため、Azure リソース観点での調査が必要です。一方で、閾値を満たしていないにもかかわらず発報した場合は、アラート ルールの動作に問題があった可能性があるため、アラート ルール観点（Azure Monitor 製品観点）で調査を実施する必要があります。

つまり、アラートが発報した状況によって、お問い合わせの起票時に選択いただく製品カテゴリ (監視している Azure リソース or アラート ルール) が異なります。例えば、閾値を満たしている状況であったものの Azure Monitor 製品を選択してお問い合わせを起票された場合、Azure Monitor チームでは内容を確認したうえで、適切なチームを探すところから対応が始まります。逆に、閾値を満たしていないのに Azure リソースを選択された場合も同様です。そのため、**「閾値を満たして発報したかどうか」**を事前にご確認いただくことで、適切な製品・カテゴリを選択してお問い合わせを起票いただけるようになり、弊社での対応もよりスムーズに進みます。

本記事では、アラート ルールの発報条件を確認する方法や、実際に閾値を満たしていたかどうかを確認する手順についてご紹介します。



2. メトリック アラート ルール

2-1. 確認するポイント

**メトリック アラート ルールの場合は、アラート ルールが実行された時にメトリックの値が閾値を満たしていたかどうかを確認します。**メトリック アラート ルールは、Azure プラットフォームから既定で収集されるプラットフォーム メトリックやカスタム メトリックを、一定の間隔で監視します。アラート ルールの閾値を満たして発報したかどうかを確認するためには、アラートが評価した期間と、当該期間におけるメトリックの値を確認する必要があります。


2-2. メトリック アラート ルールの発報条件を確認する

メトリック アラート ルールの発報条件は、下記の手順でご確認いただけます。

  1. Azure ポータル > モニター > [アラート] を開き、画面上部の [アラート ルール] を選択します。

  2. メトリック アラート ルールを選択し、[概要] ページを開きます。赤枠部分が発報条件、青枠部分がアラートのスコープです。下記の設定の場合は、Azure VM の VmAvailabilityMetric を監視し、0.8 を下回った場合に発報することが分かります。

  3. [概要] ページ の [編集] を押下し、[条件] タブを選択します。
    この画面では、メトリック アラート ルールの “集計の種類” や “確認する間隔”、”ルックバック期間” を確認できます。
    下記例では “集計の種類” が 平均、 “確認する間隔” と “ルックバック期間” が 5 分と設定されています。従って、このアラート ルール では 5 分毎に、直近 5 分間における VmAvailabilityMetric の平均を評価し、0.8 を下回っていた場合に発報します。

Note

メトリック アラート ルールの設定項目につきましては、Azure Monitor のアラートに関するよくあるご質問のブログをご覧ください。また、アラートの [条件] タブでディメンションが設定されている場合には、そのディメンションで集計されたデータが監視されます。ディメンションは、メトリック値に関する追加のデータ (名前と値のペア) です。 メトリックは、個々のリソースごとに記録されますが、ディメンションはメトリックの値をより詳細に説明するための追加情報とお考えください。


2-3. 閾値を満たしていたかどうかを確認する方法

まずは、アラート ルールが監視している Azure リソースとアラートの評価期間を確認します。
次に、メトリック エクスプローラーで評価期間におけるメトリックの値を確認します。

  1. Azure ポータル > モニター > [アラート] を開き、発報したアラートを選択します。

  2. 監視対象のリソース、評価された値、アラートの評価期間を確認します。
    [メトリック アラートの詳細] 画面が開きますので、下表に表示されている内容をご確認ください。
    このアラート ルールでは、Azure VM の VmAvailabilityMetric (可用性メトリック) を監視しており、 評価期間 5 分間の平均値が 0.8 を下回った場合に発報します。

確認する項目画面上の該当箇所例（下図参照）
監視対象のリソース影響を受けるリソース (赤枠部分)Azure VM (win2022-jpe)
評価された値このアラートが発生した理由 (青枠部分)0.5
アラートの評価期間“追加の詳細” の Evaluation window start time,
Evaluation window end time (緑枠部分)		2025/7/3 16:58 ～ 2025/7/3 17:03


  1. [影響を受けるリソース] のリンクを押下し、左ペインの [監視] > [メトリック] から メトリック エクスプローラーを開きます。

  2. [スコープ] に監視している Azure リソースが表示されていることを確認します（赤枠部分）。
    このアラート ルールは VmAvailabilityMetric の平均を監視しているので、[メトリック] で VmAvailabilityMetric、[集計の粒度] は 平均 を選択します（青枠部分）。画面右上の [現地時刻] のボタンを押下し、2. で確認したアラートの評価期間 (2025/7/3 16:58 ～ 17:03 JST) を指定します（緑枠部分）。今回は、評価期間内のメトリックの推移を最小単位 (1 分) で確認したかったため、[時間の粒度] は 1 分 を指定していますが、7/3 16:59 以降はメトリックが 1 を下回っており、アラートの閾値を満たしていたことが分かります。

重要

繰り返しとなりますが、閾値を満たして発報したのか、閾値を満たしていないにもかかわらず発報したのかによって、調査の観点が異なります。上記の例では閾値を満たして発報しているため、発報した原因をお知りになりたい場合は、アラート ルール観点ではなく、監視しているリソース (Azure VM) 観点で調査が必要となります。 もし、閾値を満たしていなかった状況であった場合には、アラート ルールの動作に問題があった可能性があるため、アラート ルール観点（Azure Monitor 製品観点）で調査する必要がございます。


2-4. メトリックの値を確認するときにご留意いただきたいこと

メトリック アラート ルールの編集画面の [プレビュー] や、アラートの詳細画面で表示されるグラフは、実際のアラート ルールの評価期間に基づいた集計の粒度で表示されていない場合がございます。アラートの評価期間におけるメトリックの値を確認する際には、メトリック エクスプローラーからご確認いただきますようお願いいたします。

  • メトリック アラート ルールの編集画面

  • アラートの詳細画面



3. ログ アラート ルール

3-1. 確認するポイント

ログ アラート ルールの場合は、アラート ルールが実行された時に検索クエリが閾値を満たしていたかどうかを確認します。
ログ アラート ルールは、各評価時に、アラート ルールの検索クエリが指定したスコープの範囲で実行され、それにヒットしたログをもとに発報条件を満たすかどうかが評価されます。

そのため、アラート ルールのスコープ、アラートが評価した期間、検索クエリをもとに、主に以下 2 点をご確認いただく必要がございます。

  • 評価時に対象のログが存在して (収集されて) いたか
  • 発報条件 (閾値) を満たしていたか

3-2. ログ アラート ルールの発報条件を確認する

ログ アラート ルールの発報条件は、下記の手順でご確認いただけます。

  1. Azure ポータル > モニター > [アラート] を開き、画面上部の [アラート ルール] を選択します。

  2. 対象のログ アラート ルールを選択し、[概要] ページを開きます。以下画像における赤枠部分が発報条件、青枠部分がアラートのスコープです。下記の設定の場合、評価対象は “リソース グループ A” 配下のリソースから収集されたログとなります。
    そして、それらのログに対し “クエリ” を実行した結果返ってきたログの行数が 1 より小さい場合に発報するという条件となっています。
    アラート ルールのスコープと発報条件

〇 ログ検索アラート ルールのスコープについて
基本的には、アラート ルールに指定したリソースから収集されたログが評価対象となります。
リソース グループを指定した場合は、そのリソース グループ配下に存在するリソースから収集されたログが対象となります。

例外として、Log Analytics ワークスペース、および Application Insights を選択した場合は、(ログ出力元リソースに関わらず) そのワークスペースまたは Application Insights へ収集されたログが評価対象となります。

〇 ディメンション分割について
ログ アラート ルールではディメンション分割を行うことができます。
ディメンション分割を設定している場合、ディメンション分割で指定したカラムに含まれる一意な値に基づいて、ログが分割され、分割されたログの集まりごとにアラート ルールの発報条件が適用されます。

例えば、あるリソース グループをスコープとし、Heartbeat ログを監視しているアラート ルールがあるとします。
この場合、評価対象は、そのリソース グループ配下に含まれるマシンから収集された Heartbeat ログすべてです。
このアラート ルールで、_ResourceId カラムによるディメンション分割を設定した場合、評価時には Heartbeat ログが _ResourceId カラム内の一意な値にもとづいて分割されます。つまり、Heartbeat ログがマシンごとに分割され、分割されたログの集まりそれぞれに対して、発報条件を満たすかどうかが評価されます。


3-3. 閾値を満たしていたかどうかを確認する方法

まずは、ログ アラート ルールの検索クエリとアラートの評価期間を確認します。
次に、Log Analytics ワークスペースで評価期間における検索クエリの結果を確認します。

  1. Azure ポータル > モニター > [アラート] を開き、確認対象のアラートを選択します。

  2. 発報されたアラートの詳細を確認します。
    右側に [ログ検索アラートの詳細] が表示されているため、下表に表示されている内容をご確認ください。

確認する項目画面上の該当箇所例（下図参照）
監視対象のスコープ影響を受けるリソース (赤枠部分) ※1vm01-ubt22 (仮想マシン)
評価された値と評価基準“このアラートが発生した理由” と
“追加の詳細” の Time aggregation と Operator (青枠部分) ※2		クエリ結果のログ レコード数 (Time aggregation: Count) が 1 で、閾値 1 以上 (GreaterThanOrEqual) であった
アラートの評価期間“追加の詳細” の
Evaluation window start time,
Evaluation window end time (緑枠部分)		2025/7/23 11:48 ～ 2025/7/23 11:53

ログ検索アラートの詳細画面の例

※1
アラート ルールでディメンション分割を行っている場合、アラート ルールのスコープと、発報したアラートの “影響を受けるリソース” が異なる場合があります。例えば、仮想マシン A を含むリソース グループをアラート ルールのスコープに設定し、_ResourceId でディメンション分割を行っている場合に、仮想マシン A から収集されたログがアラートの発報条件を満たすと、アラートの “影響を受けるリソース” は仮想マシン A となります。

※2
Time aggregation が “Count” の場合は、クエリ結果のログ レコード数が閾値を満たすかどうかが評価されます。
Time aggregation が “Count” 以外の場合、クエリ結果のうちの特定のカラム内の値が Time aggregation で指定された集計方法で集計され、その値が閾値を満たすかどうか評価されます。こちらの場合は、同箇所に記載のある Metric measure column に評価対象のカラム名が記載されていますため、併せてご確認ください。


  1. 同画面の “クエリ” セクションにある、[結果をログに表示] を押下します。

すると、クエリ実行画面が開き、先ほど確認した “影響を受けるリソース” のスコープ、時間範囲が選択された状態で、検索クエリが実行されます。以下の様に、画面下部に [結果] が表示されるため、こちらをご確認ください。
クエリ実行画面の例

なお、アラート ルールに指定した発報条件 (評価基準) により見方が少々異なるため、以下をご確認ください。

  • “テーブルの行” が評価基準に設定されている場合:
    手順 2 で確認した Time aggregation が Count の場合を指します。
    結果に表示されるログ レコードの行数が、指定した閾値を満たしているかどうかをご確認ください。
    上記の画像は手順 2 で確認した情報 (“このアラートが発報した理由”) と一致しているため、実際にアラート ルールの閾値を満たして発報していたと判断できます。

  • “テーブルの行” 以外が評価基準に設定されている (数値が格納されるカラムが評価基準に設定されている) 場合:
    手順 2 で確認した Time aggregation が Count “以外” の場合を指します。
    結果内の、数値が格納されるカラムに示される値が、指定した閾値を満たしているかどうかをご確認ください。
    こちらの結果に表示されるカラム名は、手順 2 で確認した Metric measure column の名前とは異なります (以下画像の例をご参照ください)。これは、評価時には Metric measure column 内の値が、指定した集計方法で集計された値を算出するためのクエリが追加されているためです。
    クエリ実行画面の例 2

重要

閾値を満たして発報したのか、閾値を満たしていないにもかかわらず発報したのかによって、調査の観点が異なります。

上記の例では閾値を満たして発報していたため、発報した原因すなわち対象のログが出力された原因をお知りになりたい場合は、アラート ルール観点ではなく、ログ出力元リソース観点で調査が必要となります。 もし、閾値を満たしていなかったにもかかわらず発報していた場合には、アラート ルールの動作に問題があった可能性があるため、アラート ルール観点（Azure Monitor 製品観点）で調査する必要がございます。

なお、マシンから収集される Heartbeat ログやパフォーマンス カウンターなどの、一定の間隔で収集されるログで死活監視をしている場合、ログの一時的な収集遅延によって、期待せず (マシンの動作には問題がないにもかかわらず) アラートが発報することがございます。ログ収集遅延の要因は出力元リソース側にある場合と、ログ収集経路 (Azure 基盤側) にある場合がございます。マシンの動作に問題がなくアラートの発報も一時的であった場合は基本的にご静観いただきたく存じますが、もし期待しないアラートが断続的に発報する場合など、発報要因の調査が必要だと判断された場合は、まずはアラート ルールの観点でご起票をいただけますと幸いです (調査の結果、出力元リソース側に問題があった場合は、調査の観点を出力元リソースに変えて調査を進める場合がございます)。


3-4. ログを確認するときにご留意いただきたいこと

ログ アラート ルールの評価では、指定した時刻範囲内のログ データが対象となります。
基本的に評価の時間範囲はアラート ルールの集計の粒度および評価の頻度で決まりますが、ログ アラート ルールではログの取り込み遅延を考慮して各評価の時間範囲が調整されますため、時間範囲については上記手順 2 のように、それぞれのアラート発報履歴の詳細をご確認ください。



4. アクティビティ ログ アラート

アクティビティ ログ アラートは、指定した発報条件に一致するアクティビティ ログが出力されたかどうかを監視します。
アクティビティ ログは、サブスクリプション レベルのイベントが記録されます。例えば、リソースが作成された、変更された、削除された、Azure VM が起動された、といったログが出力されます。

アクティビティ ログは、操作が実行される Azure リソースのリソース プロバイダーによって提供され、リソース プロバイダー側でアクティビティ ログの出力条件が決定されております。 このため、アラートの条件を満たして発報し、アクティビティ ログが記録された原因の調査をご希望される場合は、監視対象の Azure リソース観点でお問い合わせをご起票ください。

本記事では、アクティビティ ログ アラートの発報条件と、アクティビティ ログ アラートで検知した内容を確認する手順をご紹介します。もし、アラートの条件を満たしていないにもかかわらず発報したと疑われる場合は、アラート ルールの動作に関する調査が必要となるため、アラート ルール観点 (Azure Monitor 製品) でお問い合わせをご起票ください。


4-1. アクティビティ ログ アラートの発報条件を確認する

まずは、アクティビティ ログ アラートの発報条件を確認します。

  1. Azure ポータル > モニター > [アラート] を開き、画面上部の [アラート ルール] を選択します。

  2. アクティビティ ログ アラートを選択し、[概要] ページを開きます。赤枠部分が発報条件、青枠部分がアラートのスコープです。
    下記の設定の場合は、該当の Azure VM で、下記のアクティビティ ログが出力された場合に発報します。アクティビティ ログ アラートの発報条件の項目につきましては、公開情報をご覧ください。

  • (カテゴリが Administrative) かつ (操作名が Microsoft.Compute/virtualMachines/start/action) かつ (レベルが Informational) かつ (状態= Started)

※ [概要] ページ画面上部の [JSON ビュー] を選択した画面です。


4-2. 閾値を満たして発報したかどうかを確認する

下記の手順でアクティビティ ログ アラートが検知した内容を確認します。

  1. Azure ポータル > モニター > [アラート] を開き、発報したアラートを選択します。

  2. 発報したリソースと検知されたアクティビティ ログの内容を確認します。
    [アクティビティ ログ アラートの詳細] 画面が開きますので、下表に表示されている内容をご確認ください。
    このアクティビティ ログ アラートは (カテゴリが Administrative) かつ (操作名が Microsoft.Compute/virtualMachines/start/action) かつ (レベルが Informational) かつ (状態= Started) のときに発報する条件のため、想定どおりアラートが発報したことが分かります。

確認する項目画面上の該当箇所例（下図参照）
監視対象のリソース影響を受けるリソース (赤枠部分)Azure VM (win2022-jpe)
アクティビティ ログの操作名、
カテゴリ、レベル		このアラートが発生した理由 (青枠部分)操作名 : Microsoft.Compute/virtualMachines/start/action
カテゴリ : Administrative
レベル : Informational
アクティビティ ログの状態と
ログが出力された日時		“追加の詳細” の
Status, Submission timestamp (緑枠部分)		状態 : Started
ログが出力された日時 : 2025/7/16 14:48


4-3. 該当のアクティビティ ログを確認する

アクティビティ ログ アラートの条件に一致するログは、下記の手順にてご確認いただくことが可能です。

  1. Azure ポータル > モニター > [アラート] を開き、画面上部の [アラート ルール] を選択します。

  2. アクティビティ ログ アラートを選択し、[概要] ページを開きます。

  3. [条件] の項目に表示されている “Azure Monitor でイベントを表示する - アクティビティ ログ” のリンクを押下します。

  4. アラートの条件に一致するアクティビティ ログが表示されます。
    ※ 同じ操作名のアクティビティ ログが 3 件ありますが、状態が「開始済み (Started)」のログが該当します。

  5. [JSON] を選択すると、アクティビティ ログの内容が表示されます。

Note

アクティビティ ログのカテゴリやレベルなどの値は、こちらの公開情報でご確認ください。



5. リソース正常性アラート

リソース正常性アラートは、Azure リソースの正常性に変化が生じた際に通知する機能です。
リソースの正常性に変化が生じると、リソース プロバイダーによってリソース正常性に関するイベントがアクティビティ ログに書き込まれます。出力されたアクティビティ ログがアラートで指定した条件を満たした場合に発報します。
そのため、アラートの条件を満たして発報し、リソース正常性イベントが発生した原因の調査をご希望の場合は、監視対象の Azure リソース観点でお問い合わせをご起票ください。

本記事では、リソース正常性アラートの発報条件と、リソース正常性アラートで検知した内容を確認する手順をご紹介します。
なお、アラートの条件を満たしていないにもかかわらず発報したと疑われる場合は、アラート ルールの動作に関する調査が必要となるため、アラート ルール観点 (Azure Monitor 製品) でお問い合わせをご起票ください。


5-1. リソース正常性アラートの発報条件を確認する

まずは、リソース正常性アラートの発報条件を確認します。

  1. Azure ポータル > モニター > [アラート] を開き、画面上部の [アラート ルール] を選択します。

  2. リソース正常性アラートを選択し、[概要] ページを開きます。赤枠部分が発報条件、青枠部分がアラートのスコープです。
    下記の設定の場合は、指定したリソース グループの Azure VM (microsoft.compute/virtualmachines のリソース) で、下記の条件を満たした場合に発報します。

  • (イベントの状態が Active) かつ (現在のリソースの状態が Degraded または Unavailable) かつ (以前のリソースの状態が Available) かつ (理由の種類が Platform Initiated または Unknown または User Initiated)

※ [概要] ページ画面上部の [JSON ビュー] を選択した画面です。

Note

リソース正常性アラートの発報条件の項目と設定値につきましては、リソース正常性アラートに関するよくあるご質問のブログをご覧ください。


5-2. 閾値を満たして発報したかどうかを確認する

下記の手順でリソース正常性アラートが検知した内容を確認します。

  1. Azure ポータル > モニター > [アラート] を開き、発報したアラートを選択します。

  2. 発報したリソースと検知されたアクティビティ ログの内容を確認します。
    [リソースの正常性 アラートの詳細] 画面が開きますので、下表に表示されている内容をご確認ください。
    このリソース正常性アラートは (イベントの状態が Active) かつ (現在のリソースの状態が Degraded または Unavailable) かつ (以前のリソースの状態が Available) かつ (理由の種類が Platform Initiated または Unknown または User Initiated) のときに発報する条件のため、想定どおりアラートが発報したことが分かります。

確認する項目画面上の該当箇所例（下図参照）
監視対象のリソース影響を受けるリソース (赤枠部分)Azure VM (win2022-jpe)
リソース正常性の状態、
イベントが発生した理由		このアラートが発生した理由 (青枠部分)リソース正常性の状態 : Available から Unavailable
理由の種類 : UserInitiated
イベントの状態、
イベントが発生した日時		“追加の詳細” の
Status, Event timestamp (緑枠部分)		イベントの状態 : Active
イベントが発生した日時 : 2025/7/14 17:16 JST


5-3. リソース正常性のアクティビティ ログを確認する

リソース正常性のアクティビティ ログは、下記の手順にてご確認いただくことが可能です。

  1. Azure ポータル > モニター > [アクティビティ ログ] を開き、[フィルターの追加] を選択します。

  2. フィルタ―の条件として イベント カテゴリ を選択し、リソース正常性 カテゴリを指定します。

  3. [リソースの正常性 アラートの詳細] 画面で確認した Event timestamp (2025/7/14 17:16) のアクティビティ ログを選択します。
    ※ 同じ日時に記録されたアクティビティ ログが 2 件ありますが、状態が「アクティブ (Active)」のログが該当します。

  4. [JSON] を選択すると、アクティビティ ログの内容が表示されます。

Note

アクティビティ ログのスキーマは、こちらの公開情報でご確認ください。



6. サービス正常性アラート

サービス正常性アラートは、お客様環境にてご利用いただいている Azure サービスおよびリージョンを監視対象とし、Azure サービス自体の正常性を監視します。例えば、以下のような情報が通知されます：

  • Azure サービスの障害
  • 計画メンテナンス
  • Azure サービスの仕様変更や廃止
  • セキュリティ関連の重要情報（可用性に影響する可能性があるもの）

サービス正常性アラートは、サブスクリプション単位で設定します。
アラートの発報条件としては Azure サービス、地域、イベントの種類を指定します。サービス正常性のイベントが発生すると、アクティビティ ログにサービス正常性に関するイベントが書き込まれ、指定した条件に一致した場合にアラートが発報します。
そのため、アラートの条件を満たして発報し、サービス正常性アラートで通知された内容についてご不明な点がある場合は、基本的に該当するサービス観点でお問い合わせをご起票くださいますようお願いいたします。

サービス正常性の通知メールの下部には対象となるサービス名が記載されておりますので、記載されたサービスのカテゴリを選択いただき、お問い合わせいただきますようお願いいたします。

※ 下記例の場合は Azure Monitor 製品に関する通知であることが分かります。

また、サービス正常性のイベントには Tracking ID (追跡 ID) が付与されておりますので、Tracking ID の情報もご記載ください。
もし、アラートの条件を満たしていないにもかかわらず発報したと疑われる場合には、アラート ルールの動作に関する調査が必要となるため、アラート ルール観点 (Azure Monitor 製品) でお問い合わせをご起票ください。


6-1. サービス正常性アラートの発報条件を確認する

まずは、サービス正常性アラートの発報条件を確認します。

  1. Azure ポータル > モニター > [アラート] を開き、画面上部の [アラート ルール] を選択します。

  2. サービス正常性アラートを選択し、[概要] ページを開きます。赤枠部分が発報条件、青枠部分がスコープ（サブスクリプション）です。サービス正常性アラートでは、発報条件として下記の項目を指定します。

  • 影響を受けるサブスクリプション
  • 影響を受けるサービス
  • 影響を受ける地域
  • イベントの種類 (サービスに関する問題、計画メンテナンス、正常性の勧告、セキュリティ アドバイザリ)

下記の設定では、いずれの項目も「すべて」を選択しているため、指定したサブスクリプションで利用しているサービスの、利用しているリージョンを対象としたサービス正常性イベントが発生すると、アラートが発報します。

例えば、下記のように設定していた場合には、指定したサブスクリプションで利用しているサービスの、下記三つのいずれかのリージョンで、当該サブスクリプションに影響を及ぼす「サービスに関する問題」と「セキュリティ アドバイザリ」が発生した場合にアラートが発報します。

  • 影響を受けるサービス : すべて
  • 影響を受けるリージョン : Global, Japan East, Japan West
  • イベントの種類 : サービスに関する問題、セキュリティ アドバイザリ

※ [概要] ページ画面上部の [JSON ビュー] を選択した画面です。


重要

サービス正常性アラートの “サービス” や “地域” はすべて選択いただくことを推奨しております。

サービス正常性アラートは、ご利用いただいているサービスのご利用いただいているリージョンを対象としたイベントが発生した場合にのみ通知が行われる仕組みです。このため、サブスクリプション上のすべてのサービス、リージョンおよびイベントの種類を選択した場合にも、利用していないリソースに対してアラートは発生しません。


6-2. 閾値を満たして発報したかどうかを確認する

下記の手順でサービス正常性アラートが検知した内容を確認します。

  1. Azure ポータル > モニター > [アラート] を開き、発報したアラートを選択します。

  2. 対象のサブスクリプションやサービス、イベントの種類、追跡番号 (Tracking ID) を確認します。
    [サービスの正常性 アラートの詳細] 画面が開きますので、下表に表示されている内容をご確認ください。
    このサービス正常性アラートは、影響を受けるサービス、影響を受ける地域、イベントの種類のいずれも「すべて」を選択しているため、アラートの条件を満たして発報したことが分かります。

確認する項目画面上の該当箇所例（下図参照）
監視対象のサブスクリプション影響を受けるリソース (赤枠部分)サブスクリプション
※ マスキングしています
サービス正常性の内容このアラートが発生した理由（青枠部分）※1サービス : SQL Database
リージョン : Australia Central など (省略)
イベントの種類 : ActionRequired (正常性の勧告)
サービス正常性の追跡番号“追加の詳細” の Tracking ID (緑枠部分) ※2DTC7-B_0

※ 1
イベントの種類につきましては、Incident が “サービスの問題”、Informational もしくは ActionRequired が “正常性の勧告”、Maintenance が “計画メンテナンス”、Security は “セキュリティ アドバイザリ” です。

※2
サービス正常性に関するお問い合わせをご起票いただく際には、必ず Tracking ID (追跡 ID) をご確認ください。


Note

サービス正常性のイベントの種類の詳細につきましては、こちらの公開情報でご確認ください。


6-3. サービス正常性のアクティビティ ログを確認する

サービス正常性のアクティビティ ログは、下記の手順にてご確認いただくことが可能です。

  1. Azure ポータル > モニター > [アクティビティ ログ] を開き、[フィルターの追加] を選択します。

  2. フィルタ―の条件として イベント カテゴリ を選択し、サービス正常性 カテゴリを指定します。

  3. サービス正常性が発報した時間帯 (7/3 11:10 頃) のアクティビティ ログを検索し、イベントの種類が「ActionRequired」のログを選択します。

  4. [JSON] を選択すると、アクティビティ ログの内容が表示されます。


6-4. サービス正常性の内容を確認する

サービス正常性の内容は、下記の手順でもご確認いただくことが可能です。

  1. Azure ポータル > モニター > [サービスの正常性] を選択します。

  2. 通知されたイベントの種類を選択します。今回通知されたイベントの種類は ActionRequired でしたので、「正常性の勧告」を選択します。[サービスの正常性 アラートの詳細] 画面で確認した Tracking ID と一致していることを確認し、イベントを選択します。

  3. サービス正常性の詳細が表示されます。



7. その他

最後に、Azure Monitor 以外の監視方法をご利用されている場合の留意事項をご案内します。
稀に Azure Monitor 製品以外の方法で Azure リソースを監視されているお客様から、検知されたメッセージの意味や発報した原因について調査のご依頼をいただくことがございます。大変恐縮ではございますが、サードパーティー製の監視製品をご利用されている場合、弊社サポートではその監視の仕組みや発報条件を確認することはできません。

そのため、お問い合わせをご起票いただく前に、お客様ご自身でご利用中の監視ツールの仕組みや発報条件をご確認いただきますようお願いいたします。調査いただいた結果、Azure リソース側に問題がある可能性があると判断された場合には、調査いただいた内容をもとに、Azure リソース観点でお問い合わせをご起票ください。その際、監視ツールの仕組みや発報条件に関する情報もご共有いただけますと、弊社での調査がよりスムーズに進みますので、何卒よろしくお願いいたします。


]]> https://jpazmon-integ.github.io/blog/AzureMonitorEssential/HowToCreateAlertRuleSR/ 2025-08-19T15:00:00.000Z こんにちは、Azure Monitoring サポート チームの北村、徳田です。
今回は Azure Monitor のアラート ルールが発報した原因の調査をご依頼いただく際に、事前にご確認いただきたいポイントをご紹介します。

]]> Azure Monitor のアラート ルールが発報した原因調査に関するお問い合わせを発行いただく前の確認ポイント 2026-09-06T00:15:21.592Z Japan Azure Monitoring Support Team [更新履歴]

  • 2025/8/18 ブログ公開
  • 2026/1/5 最新情報に更新

こんにちは、Azure Monitoring サポート チームの中条です。
今回は Azure Update Manager に関するよくあるご質問をご紹介します。

Azure Update Manager の基本概念、アーキテクチャ、機能、設定手順等については、別途ブログを投稿しておりますので併せてご覧いただけますと幸いです！


目次




Q. パッチ オーケストレーションの変更方法を教えてください。

Azure Portal 上でパッチ オーケストレーションの設定を変更する方法は、下図のように Azure VM のパッチ オーケストレーションの設定を変更し、保存します。





Q. Azure Update Manager でスケジュールで更新プログラムの適用を実施したいのに、Windows Update にて自動で更新プログラムが適用されました。

以下の 2 点を確認します。

1. パッチ オーケストレーション設定が [カスタマー マネージド スケジュール (Customer Managed Schedule)] になっていることパッチ オーケストレーション設定が [Windows 自動更新 (AutomaticByOS)] が設定されている場合、OS の設定に準拠して更新プログラムの適用が実施されます。

なお、パッチ オーケストレーションの設定を [Windows 自動更新 (AutomaticByOS)] から [カスタマー マネージド スケジュール (Customer Managed Schedule)] へ変更いただいた後、更新プログラムの適用もしくは評価が実行されるまでは、後述のレジストリ値 NoAutoUpdate の 0 から 1 への変更が即時反映されません。

Azure Update Manger による更新プログラムの適用もしくは評価が実行されたタイミングで、対象マシンに Microsoft.CPlat.Core.WindowsPatchExtension 拡張機能がインストールされ、この拡張機能により、レジストリ値 NoAutoUpdate が 0 から 1 に変更されます。


2. レジストリ値 NoAutoUpdate が 1 になっていること以下のレジストリ キー内のレジストリ値 NoAutoUpdate が 0 の場合、OS の設定に準拠して更新プログラムの適用が実施されます。HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

レジストリ キーの詳細はこちらをご参照ください。

レジストリ値 NoAutoUpdate を即時 0 から 1 に変更する方法としては、1 回限りの更新プログラム適用を実施します。

なお、Windows OS 側で設定いただく自動更新のグループ ポリシー設定の有効化により、レジストリ値 NoAutoUpdate が 0 から 1 に書き換わる場合があります。




Q. パッチ オーケストレーション設定がグレー アウトしていて変更できません。

例えば、Windows OS の Azure VM のパッチ オーケストレーション設定は Windows 自動更新 (AutomaticByOS) から手動更新 (Manual) に変更できません。

Windows OS では VM 作成時に指定するプロパティ osProfile.windowsConfiguration.enableAutomaticUpdates の値により、指定可能なパッチ オーケストレーション設定が決まります。

osProfile.windowsConfiguration.enableAutomaticUpdates指定可能なパッチ オーケストレーション設定
trueカスタマー マネージド スケジュール (Customer Managed Schedule)、Azure マネージド - 安全なデプロイ (Azure Managed - Safe Deployment)、手動更新 (Manual)
falseカスタマー マネージド スケジュール (Customer Managed Schedule)、Azure マネージド - 安全なデプロイ (Azure Managed - Safe Deployment)、Windows 自動更新 (AutomaticByOS)

また、ホットパッチを無効化した場合、選択可能なパッチ オーケストレーション設定は以下の 2 つのみです。

・カスタマー マネージド スケジュール (Customer Managed Schedule)

・Azure マネージド - 安全なデプロイ (Azure Managed - Safe Deployment)






Q. WSUS サポート終了に伴い、Azure Update Manager で更新プログラムを適用したいです。

Azure Update Manager で更新プログラムの適用がサポートされているオペレーティング システムにつきましてはこちらをご確認ください。

なお、Windows 10 や Windows 11 などのクライアント OS はサポートされていません。
Microsoft Intune での更新プログラムの管理をおすすめしております。

その他 Azure Update Manager でサポートされていない環境についてはこちらをご確認ください。




Q. SQL サーバーの更新プログラムが適用対象になりません。

Azure Update Manager を利用して SQL サーバーの更新プログラムを適用するためには、Windows OS の設定にて、[その他の Microsoft 製品の更新プログラムを受け取る] 設定を有効にする必要があります。詳細はこちらをご確認ください。







Q. Azure Update Manager で適用する更新プログラムを事前にダウンロードしておいて、後からインストールできますか。

Azure Update Manager では更新プログラムの事前ダウンロードはサポートされていません。




Q. Azure Update Manager のネットワーク要件を教えてください。

Azure Update Manager をご利用いただく際のネットワーク要件について、OS の種類ごとに説明します。

1. Windows OS の場合Windows OS のマシンの場合は、Windows Update エージェントで必要とされるすべてのエンドポイントへのトラフィックを許可する必要があります。

Windows Update エージェントで必要なエンドポイントの一覧はこちらで確認できます。


2. Linux OS の場合Linux OS のマシンの場合は、Linux パッケージの配布先のエンドポイントへの通信を許可する必要があります。

例えば、Red Hat Linux マシンの場合の Linux パッケージの配布先のエンドポイントはこちらで確認できます。

他の Linux ディストリビューションについては、各プロバイダーのドキュメントをご覧ください。




上記の内容以外でご不明な点や疑問点などございましたら、弊社サポート サービスまでお問い合わせください。
最後までお読みいただきありがとうございました！

]]> https://jpazmon-integ.github.io/blog/UpdateManager/Update_Manager_FAQ/ 2025-08-18T07:00:00.000Z [更新履歴]

  • 2025/8/18 ブログ公開
  • 2026/1/5 最新情報に更新

こんにちは、Azure Monitoring サポート チームの中条です。
今回は Azure Update Manager に関するよくあるご質問をご紹介します。

Azure Update Manager の基本概念、アーキテクチャ、機能、設定手順等については、別途ブログを投稿しておりますので併せてご覧いただけますと幸いです！


]]> Azure Update Manager に関するよくあるご質問 2026-09-06T00:15:21.954Z Japan Azure Monitoring Support Team [更新履歴]

  • 2025/7/18 ブログ公開
  • 2025/12/26 最新情報に更新

こんにちは、Azure Monitoring サポート チームの趙です。
Azure Update Manager は、Azure 上の仮想マシン (VM) や Azure Arc 対応マシンに対して、OS 更新プログラムの適用を自動化・管理できるサービスです。
本記事では、Update Manager の基本概念、アーキテクチャ、機能、設定手順等を解説します。
最後に補足としてパッチ オーケストレーション モードについてもご紹介いたします。

目次

Azure Update Manager とは

Azure Update Manager は、Azure 上の仮想マシン (VM) や Azure Arc マシンに対して、OS 更新プログラムの評価及び適用を自動化・一元管理できるサービスです。
Windows マシンや、Linux マシン、どちらに対しても更新プログラム (パッケージ) を適用できます。

Azure Update Manager をご利用いただく主な利点は、
OS 更新プログラムをスケジュールで評価、更新 (適用) できることです。
このスケジュールのことを メンテナンス構成 といいます。

Azure Update Manager のアーキテクチャ

Azure 上の仮想マシン (VM) や オンプレミス マシン、他クラウド環境のマシンに対して、OS 更新プログラムの評価及び適用を自動化・一元管理できるサービスです。
オンプレミス マシン、他クラウド環境のマシンにて Azure Update Manager をご利用いただくには、対象マシンを Azure Arc マシンとしてオンボードする必要があります。

Azure Update Manager の構成は以下構成図をご参考いただければ幸いです。

構成図に記載されている Azure Update Manager の操作の詳細については、本ブログの “Azure Update Manager の機能” セッションをご参考いただければ幸いです。

また、Azure Update Manager をご利用いただくには、対象マシンの OS 上の Windows Update または Linux パッケージ マネージャーから更新プログラム (パッケージ) の適用が可能な状態である必要があります。

Note

例えば、Windows マシンの OS で Windows Update による更新プログラムの適用ができない状態 (例えば、Windows Update エンドポイントと通信ができない状態等) である場合は、Update Manager からの更新プログラムの適用も失敗します。

同様に Linux マシンの OS で yum や apt などの Linux パッケージ マネージャーから更新プログラムの適用ができない状態 (例えば、sudo yum update 実行時、エラーが返される状態等) である場合は、Update Manager からの更新プログラムの適用も失敗します。

1.評価、更新操作を指示

ユーザーにて評価、更新操作を行う場合、 Update Manager から対象マシンに該当する操作を指示します。

ユーザーは、ポータル、PowerShell、Azure CLI、REST API 等を利用して操作を行うことができます。
PowerShell、Azure CLI、REST API を利用して操作を行う場合の詳細は以下公開情報をご参考いただければ幸いです。
Azure VM の更新プログラムをプログラムで管理する方法

2.対象マシンで評価、更新操作を実行

評価、更新操作を指示された対象マシンでは、Update Manager の拡張機能が対象マシンにて Windows Update エージェント API または Linux パッケージ マネージャーを経由して、更新プログラムの評価、適用を行います。

3.評価、更新操作を報告

評価、更新操作が完了したら、Update Manager の拡張機能は対象マシンの評価、更新状態を Azure Update Manager に報告します。
Azure ポータルの Azure Update Manager の履歴画面から評価された更新プログラム (パッケージ) の一覧や、更新操作の結果を確認できます。

ヒント

Update Manager では Windows マシンの場合、Windows Update エージェント API 経由で更新プログラムの評価、適用が行われます。

この動作は、OS の [設定] > [更新とセキュリティ] > [Windows Update] 画面で確認できる Windows Update クライアントの動作とは相違します。

そのため、Update Manager より更新プログラムを適用した場合、Windows Update の更新の履歴画面には反映されない場合があります。

Update Manager より適用された更新プログラムを確認されたい際には、Azure ポータルの Azure Update Manager の履歴画面をご確認いただければ幸いです。

4.評価、更新データ (ログ) を格納

Azure Update Manager は、評価、更新操作の結果を Azure Resource Graph に格納します。
このため、Azure Update Manager の評価、更新操作の結果は Azure Resource Graph を利用して、クエリで確認することも可能です。

Azure Update Manager の主な機能

Azure Update Manager では主に以下 4 つの機能がご利用可能です。

  • オンデマンド評価 (更新プログラムの確認)
  • オンデマンド更新 (1 回限りの更新)
  • 定期的な評価 (定期評価)
  • 定期的な更新 (スケジュールの更新)

評価 (assessment) と 更新 (update) について少し補足させていただきます。

  • 評価 (assessment): マシンに適用可能な更新プログラムの一覧を取得することです。Windows Update/Linux パッケージ マネージャーより更新プログラムのスキャンが行われます。

  • 更新 (update): マシンに対して、適用可能な更新プログラムを実際に適用することです。Windows Update/Linux パッケージ マネージャーより更新プログラムの適用が行われます。

この 2 つの機能が Update Manager の基本的な機能となります。
上記内容を踏まえ、Update Manager の 4 つの主な機能について以下に説明させていただきます。

オンデマンド評価 (更新プログラムの確認)

オンデマンド評価は、Update Manager を使用して、マシンの更新プログラムの状態を即座に確認する機能です。
この機能をご利用いただくことで、マシンに適用可能な更新プログラムの一覧を取得できます。
ポータルでは、[推奨される更新プログラム] タブに表示されます。

ヒント

ポータル上でオンデマンド評価をトリガーするには “更新プログラムの確認” をクリックします。

“1 回限りの評価” と呼ばれることもあります。

オンデマンド評価の詳細については以下公開情報をご参考いただければ幸いです。
Azure Update Manager を使用して更新コンプライアンス状況を確認する

オンデマンド更新 (1 回限りの更新)

オンデマンド更新は、マシンに対して 1 回限りの更新を適用する機能です。
この機能をご利用いただくことで、マシンに適用可能な更新プログラムを即座に適用できます。
適用/除外する更新プログラムの種類、KB ID (Windows の場合)、パッケージ名 (Linux の場合) を指定可能です。

ヒント

ポータル上では “1 回限りの更新” と表示されます。

オンデマンド更新の詳細については以下公開情報をご参考いただければ幸いです。
Azure Update Manager を使用して今すぐ更新プログラムをデプロイし、結果を追跡する

定期的な評価 (定期評価)

定期的な評価は、マシンの更新プログラムの状態を定期的 (24 時間ごと) に確認する機能です。
この設定はポータル上の 設定の更新 から ON/OFF できます。

定期評価が ON になっている場合、24 時間ごとに評価 (スキャン) され、対象マシンに必要な更新プログラムの一覧が表示されます。
定期評価が OFF になっている場合、評価は行われません。

定期評価の結果は、ポータルの “推奨される更新プログラム” タブに表示されます。

Note

定期評価は、あくまでマシンに必要な更新プログラムの状態を定期的に確認する機能です。

そのため、定期評価が ON になっている場合でも、ユーザーにて更新操作を行わない限り、マシンに対して更新プログラムは適用されません。

定期評価の詳細については以下公開情報をご参考いただければ幸いです。
定期評価

定期的な更新 (スケジュールの更新)

定期的な更新は、メンテナンス構成 (スケジュール) を利用し、マシンに対してユーザーが設定したスケジュールでパッチを適用する機能です。
適用/除外する更新プログラムの種類、KB ID (Windows の場合)、パッケージ名 (Linux の場合) を指定可能です。

ヒント

ポータル上では “スケジュールの更新” と表示されます。

“メンテナンス構成” とも呼ばれます。

“メンテナンス構成” の詳細は以下公開情報をご参考いただければ幸いです。

Azure portal と Azure Policy を使用してマシンの定期的な更新をスケジュールする

Azure Update Manager の設定手順

各機能ごとに説明させていただきます。

オンデマンド評価 (更新プログラムの確認) や オンデマンド更新 (1 回限りの更新) の操作は、すぐにご利用いただけます。
別途、お客様にて事前設定等を行う必要はございません。

一方、定期的な評価 (定期評価) や 定期的な更新 (スケジュールの更新) の操作を行うには、別途、お客様にて事前設定を行う必要がございます。
定期的な評価 (定期評価) については、ポータル上の 設定の更新 から ON/OFF できます。
定期的な更新 (スケジュールの更新) については、ポータル上の メンテナンス構成 から設定を行ってください。

なお、メンテナンス構成をご利用いただく際の注意点としては、対象マシンのパッチ オーケストレーション モードが、カスタマー マネージド スケジュール (Customer Managed Schedule) で設定されている必要があります。
パッチ オーケストレーション モードについては、本ブログの “(補足) Update Manager のメンテナンス構成、Automatic VM Guest Patching、Hotpatch の違い” セッションにて補足させていただきます。

メンテナンス構成を利用するための前提条件は以下公開情報をご参考いただければ幸いです。
スケジュールされたパッチ適用の前提条件

(補足) Update Manager のメンテナンス構成、Automatic VM Guest Patching、Hotpatch の違い

以下からは Update Manager のメンテナンス構成、Automatic VM Guest Patching、Hotpatch の違いについて説明させていただきます。
違いを説明させていただくため、まずは、パッチ オーケストレーション モードについて説明させていただきます。

パッチ オーケストレーション モード

パッチ オーケストレーション モードとは、対象マシンに対して、どのようにパッチを適用するかを定義する設定です。
パッチ オーケストレーション モードには 5つの種類があります。

  • カスタマー マネージド スケジュール (Customer Managed Schedule)
  • Azure マネージド - 安全なデプロイ (Azure Managed - Safe Deployment)
  • Windows 自動更新 (AutomaticByOS)
  • 手動更新 (Manual)
  • イメージデフォルト (ImageDefault)

パッチ オーケストレーション モードの詳細については、以下公開情報もご参考いただければ幸いです。
1 つの VM で設定を構成する
パッチ オーケストレーションのモード

以下それぞれのパッチ オーケストレーション モードについて説明させていただきます。

カスタマー マネージド スケジュール (Customer Managed Schedule)

Update Manager でメンテナンス構成 (スケジュールによる更新プログラムの適用) をご利用いただくためには、
パッチ オーケストレーションを “カスタマー マネージド スケジュール (Customer Managed Schedule)” に設定いただく必要があります。

公開情報 パッチ オーケストレーションのモード 上では、AutomaticByPlatform (Azure-orchestrated) に該当します。
ByPassPlatformSafetyChecksOnUserSchedule プロパティが “True” である場合、 “カスタマー マネージド スケジュール (Customer Managed Schedule)” に該当します。

Azure マネージド - 安全なデプロイ (Azure Managed - Safe Deployment)

Automatic VM Guest Patching で利用されるパッチ オーケストレーション モードです。
Azure の任意のタイミングで Critical および Security の更新プログラムが適用されます。

公開情報 パッチ オーケストレーションのモード 上では、AutomaticByPlatform (Azure-orchestrated) に該当します。
ByPassPlatformSafetyChecksOnUserSchedule プロパティが “False” である場合、 “Azure マネージド - 安全なデプロイ (Azure Managed - Safe Deployment)” に該当します。

ヒント

カスタマー マネージド スケジュール (Customer Managed Schedule) と Azure マネージド - 安全なデプロイ (Azure Managed - Safe Deployment) の違いは、Update Manager のメンテナンス構成を利用するか利用しないかの違いです。カスタマー マネージド スケジュール (Customer Managed Schedule) では Update Manager のメンテナンス構成を利用して、ユーザーが更新プログラムの適用スケジュール (ユーザーのタイミング) を設定します。一方、Azure マネージド - 安全なデプロイ (Azure Managed - Safe Deployment) では、Azure が自動的に (Azure のタイミング) 更新プログラムを適用します。

Windows 自動更新 (AutomaticByOS)

Windows のみ該当するパッチ オーケストレーション モードです。
Windows 自動更新 (AutomaticByOS) の場合、マシンの OS 上の Windows Update 自動更新が有効になります。

手動更新 (Manual)

Windows のみ該当するパッチ オーケストレーション モードです。
手動更新 (Manual) の場合、マシンの OS 上の Windows Update 自動更新が無効になります。

イメージデフォルト (ImageDefault)

Linux のみ該当するパッチ オーケストレーション モードです。
イメージデフォルト (ImageDefault) の場合、マシンの OS 上で設定されている既定のパッケージ配布設定に従って構成されます。

Update Manager のメンテナンス構成

Update Manager のメンテナンス構成は、カスタマー マネージド スケジュール (Customer Managed Schedule) のパッチ オーケストレーション モードでご利用いただけます。

ヒント

Update Manager でスケジュール機能 (メンテナンス構成) を特にご利用されない場合、

パッチ オーケストレーションをカスタマー マネージド スケジュールに変更しなくても、オンデマンド評価 (更新プログラムの確認)、オンデマンド更新 (1 回限りの更新)、定期的な評価 (定期評価) をご利用できます。

Automatic VM Guest Patching

Automatic VM Guest Patching は、Azure のタイミングによって、[重大] および [セキュリティ] 更新プログラムが自動的にダウンロードされて VM に適用される機能です。

ヒント

Azure のタイミングとは、VM のピーク外時間帯となります。

VM のピーク外時間帯は、VM がデプロイされているリージョンの時間帯に依存します。

具体的には、Automatic VM Guest Patching が有効になっており、対象 VM が東日本リージョンにデプロイされている場合、東日本リージョンの時間帯 (日本時間) の 10 PM - 4 AM が VM のピーク外時間帯となります。

また、VM のピーク外時間帯であっても VM がその時間帯に起動していなければ更新プログラムは適用されません。

お客様にて更新プログラムを適用するタイミングをスケジュールでコントロールされたい場合は、Update Manager のメンテナンス構成をご利用いただく必要がございます。

Automatic VM Guest Patching の詳細については以下公開情報をご参考いただければ幸いです。
Azure Virtual Machines とスケール セットのゲストの自動パッチ適用

Hotpatching

Hotpatching は、Azure 上の Windows 仮想マシン (VM) に対して、再起動なしで自動的に更新プログラムを適用できる機能です。

ヒント

Hotpatching で適用される更新プログラム (KB) は Release notes for Hotpatch in Azure Automanage for Windows Server 2022、あるいは、Release notes for Hotpatch on Windows Server 2025 Datacenter Azure Edition をご参考いただければ幸いです。

Hotpatching は、一部の Windows Server エディションでのみご利用いただけます。

Hotpatching は Hotpatch Calendar のスケジュールに従い、適用されます。
そのため、お客様にて更新プログラムを適用するタイミングをスケジュールでコントロールされたい場合は、Update Manager のメンテナンス構成をご利用いただく必要がございます。

Hotpatch のスケジュールの詳細については以下公開情報をご参考いただければ幸いです。
ホットパッチのしくみ
Release notes for Hotpatch in Azure Automanage for Windows Server 2022

本日のご紹介は以上となります。上記の内容以外でご不明な点や疑問点などございましたら、弊社サポート サービスまでお問い合わせください。
最後までお読みいただきありがとうございました。

]]> https://jpazmon-integ.github.io/blog/UpdateManager/AboutUpdateManager/ 2025-07-17T15:00:00.000Z [更新履歴]

  • 2025/7/18 ブログ公開
  • 2025/12/26 最新情報に更新

こんにちは、Azure Monitoring サポート チームの趙です。
Azure Update Manager は、Azure 上の仮想マシン (VM) や Azure Arc 対応マシンに対して、OS 更新プログラムの適用を自動化・管理できるサービスです。
本記事では、Update Manager の基本概念、アーキテクチャ、機能、設定手順等を解説します。
最後に補足としてパッチ オーケストレーション モードについてもご紹介いたします。

]]> Update Manager について 2026-09-06T00:15:21.952Z Japan Azure Monitoring Support Team こんにちは、Azure Monitoring サポート チームの北村です。
今回は、サービス正常性にて通知された「Action required: Ensure the right people can access security advisories in Azure Service Health」についてご案内します。


目次


1. 報告された正常性の勧告について

1-1. 概要

項目名 項目値
題名 Action required: Ensure the right people can access security advisories in Azure Service Health
追跡 ID T_Z2-LX8
影響を受けるリージョン Southeast Asia, East US, West US 2, Sweden Central, South Africa West, West US 3, Canada Central, UK South, South India, North Central US, New Zealand North, West India, Australia Central 2, France South, Switzerland North, Jio India West, Italy North, Central US, Japan West, Australia Southeast, Mexico Central, Qatar Central, Switzerland West, Central India, East US 2 EUAP, Taiwan North, East Asia, UAE Central, Canada East, West US, France Central, Norway West, Germany West Central, South Africa North, West Europe, East US 2, Israel Central, Australia Central, Central US EUAP, Brazil Southeast, Japan East, Korea South, Germany North, Brazil South, UK West, Sweden South, West Central US, South Central US, Jio India Central, North Europe, Australia East, UAE North, Spain Central, Norway East, Korea Central, Poland Central
正常性イベントの種類 正常性の勧告

1-2. 内容

You’re receiving this notice because you use Azure Service Health. 
To ensure sensitive security advisories are only received by people with elevated permissions, we’re making changes to role-based access control (RBAC) in Azure Service Health beginning 22 April 2025. To make the changes, we’ll:

  • Introduce a new version of the Resource Health API on 22 April 2025 which makes sure security advisory event details will be accessible only to privileged users.
  • Enable RBAC for security advisory events in the Azure portal on 22 October 2025.
  • Enable RBAC for security advisory events in Azure Resource Graph on 22 October 2025.

To avoid disruption, please ensure the right users have access by following the steps below.


1-3. 実施いただきたいアクション

If you’re accessing security advisories using the Azure portal:

If you monitor the health of your resources or services using the Resource Health API, including viewing security advisories:

  • Update to the new Resource Health API before old versions are deprecated, starting on 22 October 2025.
  • Use FetchEventDetails to view sensitive security information going forward.

If you’re accessing security advisories in Azure Resource Graph:

Visit Microsoft Learn to read more about these changes and stay informed about Azure security issues.



2. Azure Service Health (サービス正常性) の「セキュリティ アドバイザリ」に関する仕様変更について

今回の通知は、 Azure Service Health (サービス正常性) の「セキュリティ アドバイザリ」に関する仕様変更を通知しております。
サービス正常性の中でセキュリティ問題に関するイベントは 「セキュリティ アドバイザリ」 に分類されます。今後 「セキュリティ アドバイザリ」 の情報にアクセスする場合には、下記の事項にご留意いただきますようお願いいたします。

  1. 「セキュリティ アドバイザリ」 のイベントを閲覧・取得するための権限について
  2. 「セキュリティ アドバイザリ」 のイベントを取得する REST API について

2-1. 「セキュリティ アドバイザリ」 のイベントを閲覧・取得するための権限について

今回の仕様変更に伴い、「セキュリティ アドバイザリ」の機密性の高い情報にアクセスする権限が変更となります。
Azure ポータルの [サービス正常性] – [セキュリティ アドバイザリ] にアクセスして情報を閲覧するには、下記の Role Based Access (RBAC) For Security Incident に記載の権限 (*) が必要となります。

(*) Role Based Access (RBAC) For Security Incident


2-2. 「セキュリティ アドバイザリ」 のイベントを取得する REST API について

現在は、Event - Get By Subscription Id And Tracking Id や Event - Get By Tenant Id And Tracking Id の REST API を利用して「セキュリティ アドバイザリ」の情報を取得することができます。

今後、上記の API では「セキュリティ アドバイザリ」の機密情報に該当するプロパティは含まれなくなります。
このため、今後は下記の API をご利用いただく必要があり、Role Based Access (RBAC) For Security Incident に記載の権限も必要となります。



3. Azure Service Health (サービス正常性) の「セキュリティ アドバイザリ」に関する仕様変更に伴う必要なアクション

上記 2 点の仕様変更に伴って必要なアクションは以下の通りです。
今回の仕様変更によってお客様環境で影響のあるユーザー様や、REST API のご利用状況、アプリケーションの確認方法については、弊社からご案内できる情報がございません。誠に恐れ入りますが、お客様ご自身でシステムの設計資料や運用方法などを確認していただき、影響を受ける可能性のあるユーザー様やアプリケーションを特定していただく必要がございますのでご了承ください。

3-1. Azure ポータル や Azure Resource Graph でサービス正常性を閲覧している場合

Azure ポータルや Azure Resource Graph でサービス正常性イベントを確認している場合、2025 年 10 月 22 日までに対象のユーザー様に必要なロールを付与してください。


3-2. REST API でサービス正常性のイベントを取得している場合

今後も REST API で「セキュリティ アドバイザリ」 の情報を確認する場合には、2025 年 10 月 22 日までに、下記事項を実施してください。



4. よくあるご質問

Q. 今回の仕様変更に関する情報が掲載されている公開情報はありますか。

セキュリティ アドバイザリを表示するための昇格されたアクセス権 の公開情報をご覧ください。


Q. 今回の仕様変更に伴って、サービス正常性アラートに影響はありますか。

今回の仕様変更は、サービス正常性アラートの動作に影響しません。
一方で、サービス正常性アラートで通知されるメールには、セキュリティ アドバイザリに関する機密性の高い情報が含まれることもございません。このため、セキュリティ アドバイザリに関する通知メールを受信した場合に、機密性の高い情報も含んで詳細を確認したい場合は、Azure ポータルのサービス正常性の画面にて直接ご確認いただきますようお願いいたします。


Q. Azure ポータルから REST API の利用状況を確認することはできますか。

いいえ、Azure ポータルから REST API の利用状況を確認することはできません。
お手数ではございますが、お客様ご自身でシステムの設計資料や運用方法などをご確認いただき、REST API のご利用状況をご確認くださいますようお願い申し上げます。


Q. 現時点でユーザーに必要なロールが割り当てられているかを確認する方法を教えてください。

Azure portal を使用して Azure でのロールの割り当てを一覧表示する の公開情報をご覧ください。


]]> https://jpazmon-integ.github.io/blog/AzureMonitorEssential/SecurityAdvisoriesElevatedAccess/ 2025-06-26T15:00:00.000Z こんにちは、Azure Monitoring サポート チームの北村です。
今回は、サービス正常性にて通知された「Action required: Ensure the right people can access security advisories in Azure Service Health」についてご案内します。


]]> Action required: Ensure the right people can access security advisories in Azure Service Health について 2026-09-06T00:15:21.661Z Japan Azure Monitoring Support Team [更新履歴]
-2025/05/07 ブログ公開
-2026/01/21 画像の更新

こんにちは、Azure Monitoring チームの徳田です。
本ブログでは、Azure Monitor エージェントの自動アップグレード機能に関するよくあるご質問に対する回答をご紹介いたします。
弊社公開情報としては以下のページにてご紹介しておりますため、こちらも併せてご参照ください。


Azure の仮想マシンとスケール セットの拡張機能の自動アップグレード


Q & A タイトル

<自動アップグレード有効化に関する質問>

<自動アップグレードの実行に関する質問>

<アップグレード時に関する質問>

<その他>


<自動アップグレード有効化に関する質問>

Q. 自動アップグレードを有効化する手順を教えてください。

自動アップグレードを有効化する方法には、主に以下の様なものがあります。

それぞれの方法について紹介します。

Azure portal 上で有効化する

Azure portal で仮想マシン、または仮想マシン スケール セットのリソースを開き、[設定] > [拡張機能とアプリケーション] のページから有効化できます。
詳細な手順については、以下の弊社公開情報をご確認ください。

Azure の仮想マシンとスケール セットの拡張機能の自動アップグレード | 拡張機能の自動アップグレードを有効にする | Azure portal を使用する

PowerShell コマンドを使用して有効化する

以下のコマンドを実行して有効化することができます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Set-AzVMExtension `
-Name AzureMonitorWindowsAgent `
-ExtensionType AzureMonitorWindowsAgent `
-Publisher Microsoft.Azure.Monitor `
-ResourceGroupName <resourceGroupName> `
-VMName <vmName> `
-Location <region> `
-HandlerVersion <version> `
-DisableAutoUpgradeMinorVersion `
-EnableAutomaticUpgrade $true

# Linux の場合
Set-AzVMExtension `
-Name AzureMonitorLinuxAgent `
-ExtensionType AzureMonitorLinuxAgent `
-Publisher Microsoft.Azure.Monitor `
-ResourceGroupName <resourceGroupName> `
-VMName <vmName> `
-Location <region> `
-HandlerVersion <version> `
-DisableAutoUpgradeMinorVersion `
-EnableAutomaticUpgrade $true

※ <> で囲まれた箇所は環境に合わせて変更してください。


Azure CLI コマンドを使用して有効化する

以下のコマンドを実行して有効化することができます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Windows の場合
az vm extension set `
--name AzureMonitorWindowsAgent `
--publisher Microsoft.Azure.Monitor `
--ids <vm-resource-id> `
--version <version> `
--no-auto-upgrade-minor-version `
--enable-auto-upgrade true

# Linux の場合
az vm extension set `
--name AzureMonitorLinuxAgent `
--publisher Microsoft.Azure.Monitor `
--ids <vm-resource-id> `
--version <version> `
--no-auto-upgrade-minor-version `
--enable-auto-upgrade true

※ <> で囲まれた箇所は環境に合わせて変更してください。
※ no-auto-upgrade-minor-version パラメーターについては、後述の Q. Set-AzVMExtension コマンドの EnableAutomaticUpgrade と DisableAutoUpgradeMinorVersion パラメーターの違いについて教えてください。 を参照してください。


なお、以下弊社公開情報には、上記の方法に加えて ARM テンプレートや REST API を使用した有効化方法についてもご紹介しております。

Azure の仮想マシンとスケール セットの拡張機能の自動アップグレード | 拡張機能の自動アップグレードを有効にする


Q. Set-AzVMExtension コマンドの EnableAutomaticUpgrade と DisableAutoUpgradeMinorVersion パラメーターの違いについて教えてください。

EnableAutomaticUpgrade

  • EnableAutomaticUpgrade は、拡張機能の自動アップグレード機能を有効化の有無を指定するパラメーターです。
  • したがって、拡張機能の自動アップグレード機能を有効化したい場合は、値を $true に設定する必要があります。
  • このパラメーターは Azure CLI の az vm extension set コマンドにおける --enable-auto-upgrade と同じはたらきです。

DisableAutoUpgradeMinorVersion

  • このパラメーターは、Set-AzVMExtension が実行される際 (拡張機能をインストールするときや手動アップグレードするとき) に、どのバージョンがインストールされる (どのバージョンにアップグレードされる) かを指定するものです。
  • -DisableAutoUpgradeMinorVersion:$true または -DisableAutoUpgradeMinorVersion とした場合は、-TypeHandlerVersion に指定したバージョンがインストールされ (-TypeHandlerVersion に指定したバージョンにアップグレードされ) ます。
  • -DisableAutoUpgradeMinorVersion:$false とした場合、その時使用できる最新の安定したマイナー バージョンがインストールされ (にアップグレードされ) ます。

(ご参考)
Set-AzVMExtension
az vm extension | az vm extension set | 省略可能のパラメーター


Q. どのようなタイミングでアップグレードされますか。利用者側で指定できますか。

残念ながら、利用者様側で自動アップグレードのタイミングを制御することはできません。
起動している仮想マシン上で動作するエージェントが、定期的に最新バージョンの値をチェックし、最新のものが存在する場合は、その後自動アップグレードの処理がトリガーされます。


Q. 最新バージョンがリリースされてすぐにアップグレードされますか。

新しいバージョンがリリースされた後、順次各リージョンにデプロイされ、利用可能となります。
ご利用のリージョンで最新バージョンが利用可能になってから、すぐにその最新版への自動アップグレードが実行されるわけではありません。
以下弊社公開情報にもある通り、自動アップグレードによるアップグレードが実行されるまで、数週間かかるとご認識ください。

Azure Monitor エージェントのインストールと管理 | 更新する



Q. 利用中のリージョンで最新バージョンが利用可能になっていますが、自動アップグレードによるアップグレードがまだ行われていません。すぐにアップグレードしたい場合はどうすればいいですか。

以下の方法で手動でアップグレードすることで任意のタイミングで最新バージョンの利用を開始することが可能です。

Azure portal 上で手動アップグレードする

リソースの [設定] > [拡張機能とアプリケーション] にて “状態” 列に 「更新プログラムを利用可能」と表記されている場合、その拡張機能のバージョンよりも新しいマイナー バージョンが利用可能であることを意味しています。
[拡張機能とアプリケーション] 画面にて、当該拡張機能にチェックを入れ [更新] を押下することで、最新のバージョンにアップグレードできます。



<アップグレード時に関する質問>

Q. アップグレード中はログ収集が停止しますか。停止期間中のログはアップグレード後に再送されますか。

まず、AMA で収集可能なログは、仕組みによって大きく 2 種類に分かれます。

  1. 一定の間隔で取得して収集するログ : Heartbeat、パフォーマンス データ、Change Tracking データ
  2. 内部の仕組みでログの更新を検知して収集するログ : イベント ログ、 Syslog、カスタム ログ

1 のログについては、アップグレードしている間はログ収集できなくなるため、その分のログは欠損してしまいます。
2 のログについては、アップグレード後に再度ログの更新を検知することが可能なため、理論上欠損は発生しません。


Q. 停止している VM に対して自動アップグレードは行われますか。

仮想マシンが停止している場合は、自動アップグレード機能によるアップグレードは実行されません。


Q. アップグレードの際に仮想マシン (OS) は停止・再起動されますか。

Azure Monitor エージェントのアップグレードの際に、仮想マシンの再起動は起こりません。


Q. 自動アップグレードが失敗した場合は再実行されますか。

AMAの自動アップグレードが失敗した場合、バージョンアップ前のバージョンが再インストール (ロールバック) されます。
ロールバックが成功した場合は、翌日の処理で再度自動アップグレードが施行されます。
なお、ロールバックが失敗すると、AMA 自体の機能が停止し、ログ転送機能が停止する可能性が高いですが、ロールバックが失敗した際の挙動と解消方法は状況により異なります。
そのため、ロールバックも失敗した場合は、必要に応じて、原因と解消方法の調査のために弊社サポート サービスまでお問い合わせください。


<その他>

Q. アップグレードの成否は確認できますか。

アクティビティ ログから確認が可能です。
具体的には、以下の画像のように、Create or Update Virtual Machine Extension というアクティビティ ログが記録されます。
なお、手動で拡張機能をアップロードした場合も同様のログが記録されますため、こちらの点についてご留意ください。



また、各マシンで動作している Azure Monitor エージェントのバージョンは、Log Analytics ワークスペースの Heartbeat テーブルの Version 列からもご確認いただけます。
そのため、当該エージェントのバージョンがどのタイミングで変更されたかは、Heartbeat ログからもご確認が可能です。
以下は確認のためのサンプル クエリおよびクエリ実行結果の例です。

■ サンプル クエリ

1
2
3
4
5
Heartbeat
| where _ResourceId =~ "<VMResourceId>"
| where Category == "Azure Monitor Agent"
| where TimeGenerated >= ago(100d)
| summarize max(TimeGenerated) by _ResourceId, Category, Version

■ サンプル クエリの実行結果の例　　


Q. Azure Monitor エージェントの各バージョンの情報はどこで確認できますか。

Azure Monitor エージェントのバージョンのリリース情報は、以下弊社公開情報に記載されます。

Azure Monitor エージェント拡張機能のバージョン | バージョンの詳細


なお、上記サイトにリリース情報が記録されるタイミングと、新しいバージョンが実際に利用できるようになるタイミングは前後する可能性がございますため、恐れ入りますが、あらかじめご理解・ご了承ください。


補足として、リージョンごとにデプロイされている Azure Monitor エージェント拡張機能のバージョンは、以下の PowerShell コマンドを実行することで確認が可能でございます。


1
2
3
4
5
# Windows
((Get-AzVMExtensionImage -Location <region> -PublisherName "Microsoft.Azure.Monitor" -Type "AzureMonitorWindowsAgent").Version | Sort-Object -Property { [Version]$_})

# Linux
((Get-AzVMExtensionImage -Location <region> -PublisherName "Microsoft.Azure.Monitor" -Type "AzureMonitorLinuxAgent").Version | Sort-Object -Property { [Version]$_})

※ <region> の箇所は、任意のリージョン名にご変更ください (japaneast など)。



上記の内容以外でご不明な点や疑問点などございましたら、弊社サポート サービスまでお問い合わせください。
皆さんの疑問点が 1 つでも解消すれば幸いです。

]]> https://jpazmon-integ.github.io/blog/LogAnalytics/AMAAutoupgradeFAQ/ 2025-05-07T03:00:00.000Z [更新履歴]
-2025/05/07 ブログ公開
-2026/01/21 画像の更新

こんにちは、Azure Monitoring チームの徳田です。
本ブログでは、Azure Monitor エージェントの自動アップグレード機能に関するよくあるご質問に対する回答をご紹介いたします。
弊社公開情報としては以下のページにてご紹介しておりますため、こちらも併せてご参照ください。


Azure の仮想マシンとスケール セットの拡張機能の自動アップグレード

]]> Azure Monitor エージェントの自動アップグレード機能に関するよくあるご質問集 2026-09-06T00:15:21.730Z Japan Azure Monitoring Support Team [更新履歴]

  • 2025/3/31 ブログ公開
  • 2026/1/7 最新情報に更新

こんにちは、Azure Monitoring サポート チームの北山です。
今回の記事では、Application Insights の TLS 変更に関するご案内 (Tracking ID : TT8T-TR0) について記載します。

下記のサービス正常性に関する記事となります。

項目名 項目値
題名 Action required: Upcoming TLS changes for Azure Monitor Application Insights
追跡 ID TT8T-TR0
影響を受けるリージョン Southeast Asia; East US; West US 2; Sweden Central; South Africa West; West US 3; Canada Central; UK South; Global; South India; North Central US; New Zealand North; West India; Australia Central 2; France South; Switzerland North; Jio India West; Italy North; Central US; Japan West; Australia Southeast; Mexico Central; Qatar Central; Switzerland West; Central India; East US 2 EUAP; Taiwan North; East Asia; UAE Central; Canada East; West US; France Central; Norway West; Germany West Central; South Africa North; West Europe; East US 2; Israel Central; Australia Central; Central US EUAP; Brazil Southeast; Japan East; Korea South; Germany North; Brazil South; UK West; Indonesia Central; Sweden South; West Central US; South Central US; Jio India Central; North Europe; Australia East; UAE North; Spain Central; Norway East; Korea Central; Poland Central
正常性イベントの種類 正常性の勧告

内容は下記のとおりです。

原文

1
2
3
4
5
6
7
8
You’re receiving this notification because you're associated with one or more Azure subscriptions that use Azure Monitor Application Insights.

To enhance security and provide best-in-class encryption for your data, we'll require all connections to Azure Monitor Application Insights to be secured using Transport Layer Security (TLS) 1.2 or later beginning 1 May 2025, when support for TLS 1.0 and 1.1 will end.

If you're already using TLS 1.2 or later, no further action is required.

# Required action
If you're using TLS 1.0 or 1.1 for Azure Monitor Application Insights, you'll need to switch to TLS 1.2 or later by 1 May 2025. You can determine if you're using TLS 1.0 or 1.1 by enabling logging.

日本語

1
2
3
4
5
6
7
8
9
あなたは、Azure Monitor Application Insights をご利用いただいている Azure サブスクリプションに関連付けられているため、この通知を受け取っています。

データのセキュリティ強化と最先端の暗号化を提供するため、2025年5月1日より、Azure Monitor Application Insights へのすべての接続で TLS 1.2 以降の使用を必須とし、TLS 1.0 および 1.1 のサポートを終了します。

すでに TLS 1.2 以降を使用している場合は、追加の対応は不要です。

# 必要なアクション
クライアント側で TLS 1.0 または 1.1 を使って Azure Monitor Application Insights と通信している場合は、2025年5月1日までにクライアント側を TLS 1.2 以降へ移行する必要があります。
使用中の TLS バージョンを確認するには、ログを有効化してください。

どのような影響を受けるか

クライアント側 (OS の設定もしくは、ランタイム・Web アプリケーション側の設定) にて、TLS 1.1 もしくは 1.0 のプロトコルでサーバーと通信する設定の場合、期待どおり Application Insights に各種テレメトリが送信されません。
結果として、Application Insights に各種ログやメトリックが保存されず、期待どおり Web アプリケーションの監視が出来なくなります。

いつから影響を受けるか

2025 年 5 月 1 日からです。

影響を受けるお客様

監視対象の Web アプリケーションをホストしているクライアント側で、TLS 1.1 もしくは 1.0 のプロトコルを使ってサーバーと通信をしているお客様です。

影響を受けているか確認する方法

1. 接続文字列を用いて Application Insights と連携している場合

この場合、お客様に実施いただく対処は不要です。
接続文字列を用いて Application Insights と連携している場合、監視対象の Web アプリケーションは接続文字列に含まれるリージョナル インストルメンテーション エンドポイントに対して各種テレメトリを送信しております。

例えば下記の接続文字列の場合、Japan East に展開されたリージョナル エンドポイント (japaneast-1.in.applicationinsights.azure.com) 宛に各種テレメトリを送信します。

InstrumentationKey=XXXX;IngestionEndpoint=https://japaneast-1.in.applicationinsights.azure.com/;LiveEndpoint=https://japaneast.livediagnostics.monitor.azure.com/;ApplicationId=XXX

IP addresses used by Azure Monitor

このリージョナル インジェスト エンドポイントに関しましては、もともとサーバー側で TLS 1.1 / 1.0 を利用しておりません。
そのため、接続文字列を用いて Application Insights と連携していてかつ、Application Insights リソースに各種テレメトリが送信できている状況であれば、クライアント側はすでに TLS 1.2 以上で通信しております。
そのため、対処は不要です。

2. インストルメンテーション キーを用いて Application Insights と連携している場合

インストルメンテーション キーを用いて Application Insights と連携している場合、グローバル インジェスト エンドポイントに対して各種テレメトリを送信しております。
このエンドポイントは、現在も TLS 1.0 / 1.1 をサポートしております。
IP addresses used by Azure Monitor

インストルメンテーション キーを用いて Application Insights と連携している場合は、場合によってはクライアント側の対処が必要です。
対処の要否確認方法は、Web アプリケーションをホストしている OS の種類やランタイムによって異なります。
TLS 1.0 に関して、弊社からお客様向けにガイダンスを提供しております。
確認方法は環境によって異なるため一概にはお答えできませんが、下記公開情報をご参考くださいませ。

よくあるご質問

私は接続文字列とインストルメンテーション キーのどちらを利用していますか?

お客様の実装方法によって確認方法が異なります。
インストルメンテーション キーや接続文字列の指定方法は、いくつか方法がございます。
ランタイムによって実装方法が異なる可能性がございますが、基本的には下記のとおりです。

  1. 環境変数で指定する
  2. ご利用いただいている Azure Monitor OpenTelemetry Distro や Classic Application Insights SDK の設定ファイルで指定する
  3. ソース コード上にハードコーディングする

上記の方法が存在するため、確認自体はお客様にて実施いただく必要がございます。
これは、弊社ではお客様が管理しているデータにアクセス出来ないためです。

お問い合わせを頂いている中で、一番多い連携方法は環境変数で指定する方法です。
インストルメンテーション キーと接続文字列で使用される環境変数は下記のとおりです。

  • APPINSIGHTS_INSTRUMENTATIONKEY : インストルメンテーション キーを指定するために使われます。
  • APPLICATIONINSIGHTS_CONNECTION_STRING : 接続文字列を指定するために使われます。

もし環境変数に APPINSIGHTS_INSTRUMENTATIONKEY が指定されている場合は、環境変数から APPINSIGHTS_INSTRUMENTATIONKEY を削除して APPLICATIONINSIGHTS_CONNECTION_STRING のみをご指定ください。

App Service や Azure Functions の場合、環境変数を変更すると再起動が実施されます。
その結果一時的にアクセス出来ない状況が考えられるため、環境変数の設定は十分ご留意くださいませ。

その他、接続文字列に関する参考情報は下記となります。

下記の公開情報に Java の記載がございませんが、Java 用の OpenTelemetry Distro と Classic SDK (v2.5.1 と 3.x) は接続文字列に対応しております。

もしお客様自身でご確認いただいていも分からない場合は、お気兼ねなく Azure portal よりサポート リクエストをご起票ください。
その際は下記の情報をご連携いただけると、よりスムーズにサポートを提供出来ると存じます。

  • 監視対象 Web アプリケーションのランタイム (.NET, Java, Node.js など)
  • Application Insights との統合方法 (手動インストルメンテーション or 自動インストルメンテーション)
  • 手動インストルメンテーションの場合、組み込んでいただいているパッケージ情報 (パッケージ名とパッケージのバージョン)
  • 自動インストルメンテーションの場合、デプロイ先の Azure リソース ID (App Service のリソース ID)
  • 宛先の Application Insights リソースのリソース ID

なんとかして使っている TLS のバージョンをチェックすることは出来ますか?

パケットキャプチャーを取得することで、ご確認可能です。
App Service にデプロイいただいている状況を例に、方法について記載します。

下記に記載する方法は、TLS のバージョン問わず Application Insights のエンドポイントと通信が出来ている前提です。
何らかの理由で通信が出来ない場合は、TLS ハンドシェイクの箇所をご確認いただく必要がある点についてご留意ください。

手順 1
Azure portal にアクセスして、Web アプリケーションをデプロイしている App Service リソースのページへ移動します。
“問題の診断と解決” ページにて、”Collect Network Trace” を選びます。

こちらは Windows 版 の 専用コンピューティング (Basic, Standard, Premium) および Isolated の App Service プランのみです。
Linux 版や共有コンピューティングの App Service プランをご利用の場合は手動にて採取いただく必要がございます。
詳細は下記の公開情報をご参照ください。
仮想ネットワークを Azure App Service に統合する際のトラブルシューティング

手順 2
監視対象の Web アプリケーションが稼働していることを確認して、”Collect Network Trace” をクリックします。
すると、60 秒間ネットワーク トレースが採取され続けます。

手順 3
60 秒後、収集が完了します。
ハイパーリンクから、収集したトレース ファイルをダウンロードします。

手順 4
弊社のツールである Microsoft Network Monitor を使って、ダウンロードしたキャプチャ ファイルを開きます。

Wireshark など、他のパケット解析ツールでも問題ございません。

手順 5
30 秒ごとに実施される Application Insights へのテレメトリ送信処理のパケットを確認し、TLS フレームの詳細で利用しているバージョンを確認します。
下図のように 1.2 を使っていれば対処は不要です。

宛先となる Application Insights の IP アドレスですが、接続文字列に指定されたインジェスト エンドポイントを名前解決することで確認可能です。
App Service の場合 Kudu にてご確認可能です。
Global IP アドレスは一つでは無いため、下図のように複数回実行いただくことを推奨します。

名前解決は、Windows 版の App Service の場合は nameresolver を使います。
Linux 版の場合は nslookup を使います。
詳細は下記の公開情報をご参考ください。
仮想ネットワークを Azure App Service に統合する際のトラブルシューティング

正常性イベントに記載があった “You can determine if you’re using TLS 1.0 or 1.1 by enabling logging.” とはどういう意味ですか?

結論から申し上げますと、こちらの方法では TLS 1.0 / 1.1 を使っているかどうかの特定は出来ません。
お客様に誤った情報を発信して混乱を招いてしまい、大変申し訳ございませんでした。

ログを収集するために Application Insights を有効化いただいても、TLS バージョンを特定することは出来ません。
大変恐れ入りますが、本ブログ記事に記載させていただいた方法でご確認いただけますと幸いです。

最後に

もし移行方法についてご質問がある場合やトラブル解決のためにサポートが必要な場合は、Azure portal より Application Insights 観点でお問い合わせください。
以上となります。

]]> https://jpazmon-integ.github.io/blog/applicationInsights/upcomingTlsChangesForAppInsights/ 2025-03-31T02:00:00.000Z [更新履歴]

  • 2025/3/31 ブログ公開
  • 2026/1/7 最新情報に更新

こんにちは、Azure Monitoring サポート チームの北山です。
今回の記事では、Application Insights の TLS 変更に関するご案内 (Tracking ID : TT8T-TR0) について記載します。

]]> Application Insights の TLS に関する変更のご案内 2026-09-06T00:15:21.983Z Japan Azure Monitoring Support Team [更新履歴]

  • 2025/03/26 ブログ公開
  • 2026/01/13 最新情報への更新

こんにちは！Azure Monitoring チームの加治屋です。
この記事では、Container Insights に関する説明、導入のための前提条件、導入方法をご紹介いたします。

Container Insights とは？

AKS クラスターをはじめとした コンテナー環境へデプロイすることで、コンテナー環境で収集された情報を ログとして Log Analytics ワークスペースに収集する、Azure Monitor の製品です。
Log Analytics ワークスペースへ収集した情報は通常の VM などから収集したログと同じように、KQL を使用して、情報の分析やログ アラート ルールの処理を行うことができます。

Azure Monitor での Kubernetes の監視
https://learn.microsoft.com/ja-jp/azure/azure-monitor/containers/kubernetes-monitoring-overview

この機能をデプロイすると、コンテナー環境へ Azure Monitor エージェント Pod がデプロイされます。

Azure Monitor での Kubernetes の監視 - コンテナー レベル
https://learn.microsoft.com/ja-jp/azure/azure-monitor/containers/kubernetes-monitoring-overview#container-levels

Container Insights を有効化する上での前提条件

以下の前提条件がございます。

サポートされているクラスター

・ Azure Kubernetes クラスター
・ Azure Arc 対応 Kubernetes クラスター (※)
※ ディストリビューションによっては対応していないものもございます。サポートしているディストリビューションにつきましては、以下の弊社公開情報をご確認ください。

Arc 対応 Kubernetes クラスターの監視を有効にする - サポートされているクラスター
https://learn.microsoft.com/ja-jp/azure/azure-monitor/containers/kubernetes-monitoring-enable-arc?tabs=cli#supported-clusters

Azure Arc 対応 Kubernetes システム要件 - クラスターの要件
https://learn.microsoft.com/ja-jp/azure/azure-arc/kubernetes/system-requirements#cluster-requirements

ネットワーク要件

Container Insights には以下のネットワーク要件がございます。
Container Insights を有効化いただく前に以下の宛先に接続できるか、ご確認をお願いいたします。

*.ods.opinsights.azure.com:443
*.oms.opinsights.azure.com:443
dc.services.visualstudio.com:443
*.monitoring.azure.com:443
login.microsoftonline.com:443
global.handler.control.monitor.azure.com:443
*.ingest.monitor.azure.com:443
*.metrics.ingest.monitor.azure.com:443
.handler.control.monitor.azure.com:443

詳細な要件につきましては、以下の弊社公開情報をご確認いただけますと幸いです。

Kubernetes クラスターを監視するためのネットワーク ファイアウォールの要件
https://learn.microsoft.com/ja-jp/azure/azure-monitor/containers/kubernetes-monitoring-firewall

その他前提条件

Container Insights 有効化の際は、以下の前提条件をご確認ください。
・Azure CLI バージョン 2.49.0 以降では、CLI によるオンボーディングを実行すると、既定でマネージド ID 認証を使用する Container Insights が有効化されます。
・Azure k8s-extension バージョンが 1.3.7 以降であること。k8s-extension バージョン 1.43.0 以降では、既定でマネージド ID 認証が使用されます。

※ マネージド ID 認証は、ARO (Azure Red Hat OpenShift) または Windows ノードを使用する Azure Arc 対応 Kubernetes クラスターではサポートされていません。
上記環境にて Container Insights をご利用される場合は、レガシー認証を使用して Container Insights の有効化を実施ください。

AKS クラスターの監視を有効にする - Prometheus メトリックとコンテナー ログを有効にする - 前提条件
https://learn.microsoft.com/ja-jp/azure/azure-monitor/containers/kubernetes-monitoring-enable?tabs=cli#prerequisites-1

Container Insights の有効化 (デプロイ) 方法

有効化方法として、いくつか方法がございます。
代表的な手順をご紹介いたします。
なお、以下の有効化手順につきましては、Azure Kubernetes Service (AKS) リソースでご利用されることを前提として記載しております。

I. AKS リソースの作成時に Container Insights も一緒に有効化する方法

以下の画面にて有効化を行うことが可能です。
[コンテナー ログを有効にする] にチェックを入れていただき、ログを送信する先の Log Analytics ワークスペースを指定します。
指定しない場合は、規定の Log Analytics ワークスペース (DefaultWorkspace- からはじまる Log Analytics ワークスペース) が新規作成、もしくは自動的に指定されます。

リソース作成時に有効化

コストの事前設定の部分は、ログの収集頻度やログの収集対象を設定する箇所でございます。
具体的な設定につきましては、以下の弊社公開情報にも記載がございますので、ご参照ください。

AKS クラスターの監視を有効にする - Prometheus メトリックとコンテナー ログを有効にする - 構成オプション
https://learn.microsoft.com/ja-jp/azure/azure-monitor/containers/kubernetes-monitoring-enable?tabs=portal#configuration-options

II. AKS リソース作成後に Azure CLI を使用して有効化する方法
以下のコマンドを実行します。

1
az aks enable-addons --addon monitoring --name "<AKS クラスター名>" --resource-group "<リソース グループ名>" --workspace-resource-id "<Log Analytics ワークスペースのリソース ID>"

Azure Arc 対応クラスターをご利用の場合は、こちらのコマンドをご利用ください。

1
az k8s-extension create --name azuremonitor-containers --cluster-name "<Azure Arc 対応クラスター名>" --resource-group "<リソース グループ名>" --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings logAnalyticsWorkspaceResourceID="<Log Analytics ワークスペースのリソース ID>"

ARO (Azure Red Hat OpenShift) または Windows ノードを使用する Azure Arc 対応 Kubernetes クラスターに対しては、以下のコマンドにてレガシー認証を利用した Container Insights を有効化します。

1
az k8s-extension create --name azuremonitor-containers --cluster-name "<Azure Arc 対応クラスター名>" --resource-group "<リソース グループ名>" --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers ---configuration-settings logAnalyticsWorkspaceResourceID="<Log Analytics ワークスペースのリソース ID>" amalogs.useAADAuth=false

その他のクラスターで有効化を行う方法につきましては、以下の弊社公開情報にコマンドのサンプルがございますので、ご参照ください。
AKS クラスターの監視を有効にする
https://learn.microsoft.com/ja-jp/azure/azure-monitor/containers/kubernetes-monitoring-enable?tabs=cli#enable-container-insights

III. AKS リソース作成後に Azure ポータルを使用して有効化する方法

AKS リソースより [分析情報] もしくは [監視] をご選択いただき、[モニターの設定] より有効化いただけます。
Azure ポータルからの有効化

ログ送信先の Log Analytics ワークスペースの変更したいなど、設定変更を行いたい場合は、画面下部の [詳細設定] より設定を変更いただけます。
Azure ポータルからの有効化時の設定変更

コストの事前設定に関する具体的な設定につきましては、以下の弊社公開情報にも記載がございますので、ご参照ください。
AKS クラスターの監視を有効にする - Prometheus メトリックとコンテナー ログを有効にする - 構成オプション
https://learn.microsoft.com/ja-jp/azure/azure-monitor/containers/kubernetes-monitoring-enable?tabs=portal#configuration-options

なお、この有効化方法は、マネージド ID による認証が使用できないクラスター (Azure Arc 対応 Redhat OpenShift クラスターなど) ではご利用いただけません。

有効化の確認方法

Contianer Insights は、Azure Monitor にて使用されているエージェント (Azure Monitor エージェント) の仕組みを使用し、ログを Log Analytics ワークスペースへ送信いたします。
そのため、Container Insights を有効化いたしますと、ログの送信先 log Analytics ワークスペースに対して Heartbeat ログが 1 分間隔で送信されます。
Container Insights の有効化が正常に行われたかご確認いただければと存じます。

Container Insights の有効化確認

heartbeat ログの確認方法につきましては、以下の記事をご参照ください。
Azure Monitor エージェントにより収集される Heartbeat ログを使用した死活監視方法
https://jpazmon-integ.github.io/blog/LogAnalytics/MonitorVM_AMA/#%E4%BE%8B-1-%E3%81%82%E3%82%8B%E3%83%9E%E3%82%B7%E3%83%B3%E3%81%8B%E3%82%89-Heartbeat-%E3%81%8C%E5%8F%8E%E9%9B%86%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E3%81%93%E3%81%A8%E3%82%92%E7%A2%BA%E8%AA%8D%E3%81%99%E3%82%8B

Container Insights の無効化方法

誤った方法で設定変更を行ってしまった場合や、特定の設定を実施いただく際に必要な手順として、Container Insights の無効化をご案内させていただく場合がございます。
無効化の際は以下のコマンドをご実行ください。

1
az k8s-extension delete --name azuremonitor-containers --cluster-type connectedClusters --cluster-name <クラスター名> --resource-group <リソース グループ名>

無効化を行いますと、Container Insights を使用する機能 (ログ収集機能) がご利用いただけなくなりますので、ご留意ください。
また、無効化を行った場合でも、Container Insights の作成時に同時に作成した Log Analytics ワークスペースやアラート等は削除されませんので、もしこれらのリソースも不要である場合は、個別に削除ください。

Kubernetes クラスターの監視を無効にする - ログ収集を無効にしてエージェントを削除する
https://learn.microsoft.com/ja-jp/azure/azure-monitor/containers/kubernetes-monitoring-disable#disable-log-collection-and-remove-agent

もし、Container Insights のデプロイ方法にてお困りごとがございましたら、遠慮なく弊社サポートまでお問い合わせください。

参考情報

]]> https://jpazmon-integ.github.io/blog/LogAnalytics/HowToContainerInsights/ 2025-03-25T15:00:00.000Z [更新履歴]

  • 2025/03/26 ブログ公開
  • 2026/01/13 最新情報への更新

こんにちは！Azure Monitoring チームの加治屋です。
この記事では、Container Insights に関する説明、導入のための前提条件、導入方法をご紹介いたします。

]]> Container Insights のご紹介 2026-09-06T00:15:21.816Z Japan Azure Monitoring Support Team [更新履歴]

  • 2025/2/20 ブログ公開
  • 2025/12/26 最新情報に更新

こんにちは、Azure Monitoring サポート チームの北山です。
今回の記事では、Azure Automation のエージェント ベースの Hybrid Runbook Worker 廃止について記載します。
Retirement: All Azure Automation jobs running on Agent-based Hybrid Worker will be stopped from 1 April 2025

用語

Hybrid Runbook Worker

Azure Automation の機能の一つです。
予め作成した Runbook (PowerShell・Python スクリプト) は、Azure Automation のクラウド環境で比較的容易に実行可能です。
一方で Hybrid Runbook Worker を利用すると、お客様管理のコンピューター上で Runbook の実行が可能です。

メリットは、クラウド環境で実行するよりも制限が緩いこと、サード パーティー製のアプリケーションと連携が可能なこと、お客様管理のネットワーク環境上で実行が可能なことなどです。

エージェント ベースの Hybrid Runbook Worker

Log Analytics エージェントのテクノロジーを利用した、Hybrid Runbook Worker です。
エージェント ベースの Hybrid Runbook Worker をご利用いただくには、当該コンピューターに Log Analytics エージェントのインストールが必須です。

Log Analytics エージェントは 2024 年の 8 月にサポート終了しているため、それに伴いエージェント ベースの Hybrid Runbook Worker もサポートが終了しています。

拡張機能ベースの Hybrid Runbook Worker

現在主流の、Azure VM・Azure Arc enabled servers の拡張機能として動作する Hybrid Runbook Worker です。
Log Analytics エージェントに依存していないため、Log Analytics エージェントのインストールは不要です。
Log Analytics エージェントの後継版である Azure Monitor エージェントのインストールも不要です。

概要

エージェント ベースの Hybrid Runbook Worker に関しましては、2024 年の 8 月にすでにサポートが終了し、
下記の更新情報に記載がございますとおり 2025 年 4 月 1 日からはエージェント ベースの Hybrid Runbook Worker がご利用できなくなりました。

Retirement: All Azure Automation jobs running on Agent-based Hybrid Worker will be stopped from 1 April 2025

どのような影響を受けるか

エージェント ベースの Hybrid Runbook Worker 上でジョブを実行した場合、ジョブ実行が正常に動作しません。
これは、スケジュール実行・ポータルからの実行・Webhook (*1) による実行すべてに該当します。
※ 1 : Logic Apps や PowerAutomate で使われる Azure Automation コネクタも該当します。

いつから影響を受けるか

2025 年 4 月 1 日からです。

影響を受けるお客様

ジョブ実行環境として、エージェント ベースの Hybrid Runbook Worker をご利用いただいているお客様です。

エージェント ベースの Hybrid Runbook Worker を利用しているか確認する方法

1. Azure ポータルから確認する方法

一つ一つ Automation アカウントを確認する必要がありますが、Azure ポータルから確認が可能です。
確認の手順は下記のとおりです。

  1. Azure ポータルを開き、Automation アカウントのページへ移動します。
  2. 画面左側の [プロセス オートメーション - ハイブリッド Worker グループ] をクリックし、[ユーザー ハイブリッド worker グループ] タブから確認したい Hybrid Runbook Worker グループをクリックします。
  3. [ハイブリッド Worker グループ - ハイブリッド Worker] をクリックして表示される Hybrid Runbook Worker の [プラットフォーム] 列を確認し、値が「エージェント ベース (V1)」の場合はエージェント ベースの Hybrid Runbook Worker を利用しています。

もしプラットフォームの箇所が「拡張機能ベース (V2)」の場合は、対処不要です。

2. PowerShell スクリプトを実行して確認する方法

実行方法

後述する PowerShell スクリプトを Azure Portal の Cloud Shell にて実行することで、エージェント ベースの Hybrid Runbook Worker 一覧を CSV 形式で出力が可能です。

PowerShell スクリプトを Cloud Shell の PowerShell にて実行し、「CSV file has been created: Agent-basedHRWs.csv」が出力されれば処理は完了です。
その後、下記の手順にて CSV ファイルのダウンロードが可能です。

  1. Dir コマンドで対象の CSV ファイルが存在する事を確認します。

  2. ダウンロードをクリックします。

  3. ファイル名 (Agent-basedHRWs.csv) を入力して [ダウンロード] をクリックします。

出力された CSV には、下記の列が存在します。

  • WorkerName : エージェント ベースの Hybrid Runbook Worker の名称です。
  • AutomationAccountName : Hybrid Runbook Worker を管理している Azure Automation アカウントの名称です。
  • HybridRunbookWorkerGroupName : Hybrid Runbook Worker を管理している Hybrid Runbook Worker グループの名称です。
  • ResourceGroupName : Azure Automation アカウントを管理しているリソース グループの名称です。

注意点

  • Cloud Shell は、Bash ではなく PowerShell としてご利用ください。
  • テナントに複数のサブスクリプションが存在する場合、期待しないサブスクリプションに対して処理が実行される可能性がございます。期待しないサブスクリプションに処理が実行される場合は、予め「Set-AzContext -SubscriptionID “<対象サブスクリプション ID>”」のコマンドレットを実行ください。
  • Azure portal にアクセスしているユーザーには、最低でもサブスクリプション スコープに閲覧者ロールを付与してください。サブスクリプション内のすべての Azure Automation リソースを参照するためです。

補足

  • Cloud Shell のターミナルに PowerShell スクリプトをペーストする場合は、「Ctrl + V」ではなく「Shift + Insert」をご利用ください。
  • 出力される CSV には、エージェント ベースの Hybrid Runbook Worker しか出力されません。
  • この PowerShell スクリプトを実行することで、Azure リソースが更新されることはございません。
  • この PowerShell スクリプトを実行することで、Hybrid Runbook Worker として稼働している Azure VM が停止することはございません。

サンプル スクリプト

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
# 出力用のデータを格納する配列を初期化
$output = @()

# Automation アカウントの一覧を取得
$automationAccounts = Get-AzAutomationAccount | Select-Object -Property ResourceGroupName, AutomationAccountName

# Automation アカウントの総数を取得
$totalAccounts = $automationAccounts.Count
$currentIndex = 0

foreach ($account in $automationAccounts) {
    $currentIndex++
    
    # 進捗状況を出力
    Write-Progress `
        -Activity "In progress..." `
        -Status "Current account: $($account.AutomationAccountName)" `
        -PercentComplete (($currentIndex / $totalAccounts) * 100)

    # リソースグループ名とAutomationアカウント名を変数にセット
    $resourceGroup = $account.ResourceGroupName
    $automationAccountName = $account.AutomationAccountName

    # Hybrid Worker Groups を取得
    $hybridRunbookWorkerGroups = Get-AzAutomationHybridWorkerGroup `
        -ResourceGroupName $resourceGroup `
        -AutomationAccountName $automationAccountName `
    | Where-Object { $_.GroupType -eq "User" } `
    | Select-Object -Property Id, Name

    # $hybridRunbookWorkerGroups が NULL または空白の場合は次のループへ
    if (-not $hybridRunbookWorkerGroups) {
        Continue
    }

    # Hybrid Worker Groups に含まれる、エージェント ベース (HybridV1) Hybrid Runbook Worker を取得
    foreach ($worker in $hybridRunbookWorkerGroups) {
        $workerItem = Get-AzAutomationHybridRunbookWorker `
            -ResourceGroupName $resourceGroup `
            -AutomationAccountName $automationAccountName `
            -HybridRunbookWorkerGroupName $worker.Name `
        | Where-Object { $_.WorkerType -eq "HybridV1" }

        if (-not $workerItem) {
            Continue
        }
        
        # 出力用のデータを配列に追加
        $outputItem = @{
            ResourceGroupName            = $resourceGroup
            AutomationAccountName        = $automationAccountName
            HybridRunbookWorkerGroupName = $worker.Name
            WorkerName                   = $workerItem.WorkerName
        }
        $output += $outputItem
    }
}

# CSV ファイルに出力
$FilePath = "Agent-basedHRWs.csv"
$output | Export-Csv -Path $FilePath -NoTypeInformation

Write-Output "CSV file has been created: $FilePath"

移行方法

基本的には、下記の流れで移行作業を実施します。

  1. 対象のコンピューターに、Hybrid Runbook Worker の拡張機能をインストールします。
  2. 拡張機能をインストール後、動作実績がある Runbook を Hybrid Runbook Worker にて実行し、動作確認を行います。
  3. 動作確認完了後、Azure portal にて当該 Hybrid Runbook Worker グループからエージェント ベースの Hybrid Runbook Worker を削除します。

その他、拡張機能ベースの Hybrid Runbook Worker ご利用の前提条件や、Azure VM 以外のコンピューターでご利用いただく方法などが下記の公開情報に記載されております。
こちらの公開情報をご参考に、エージェント ベースの Hybrid Runbook Worker から拡張機能の Hybrid Runbook Worker へ移行作業をご検討ください。

最後に

もし移行方法についてご質問がある場合やトラブル解決のためにサポートが必要な場合は、Azure portal より Azure Automation 観点でお問い合わせください。
以上となります。

]]> https://jpazmon-integ.github.io/blog/automation/AgentBasedHrwRetired/ 2025-02-20T05:00:00.000Z [更新履歴]

  • 2025/2/20 ブログ公開
  • 2025/12/26 最新情報に更新

こんにちは、Azure Monitoring サポート チームの北山です。
今回の記事では、Azure Automation のエージェント ベースの Hybrid Runbook Worker 廃止について記載します。
Retirement: All Azure Automation jobs running on Agent-based Hybrid Worker will be stopped from 1 April 2025

]]> エージェント ベースの Hybrid Runbook Worker がご利用いただけなくなります 2026-09-06T00:15:21.990Z Japan Azure Monitoring Support Team こんにちは、Azure Monitoring サポート チームの北村です。
今回は Azure Monitor の診断設定に関するよくあるご質問をご紹介します。


Q & A タイトル

<Azure Monitor の診断設定の全般>


<リソース ログ・メトリックのエクスポート>


<アクティビティ ログのエクスポート>


<トラブルシューティング>


Azure Monitor の診断設定の全般

Q. Azure Monitor の診断設定について教えてください。

Azure プラットフォームのメトリックやログ、アクティビティ ログを Log Analytics ワークスペース等にエクスポートする機能です。
プラットフォームのメトリックは Azure リソースから一定の間隔で自動で収集される数値データであり、既定で収集されます。メトリックは Azure 基盤側のメトリック データベースに保存され、Azure ポータルのメトリック エクスプローラーから確認できます。
プラットフォームのログは Azure リソース内で実行された操作に関するデータであり、Azure Monitor の診断設定を構成しない限り、収集することはできません。プラット フォームのメトリックを既定の保持期間 (93 日間) 以上保管したい場合やプラットフォームのログを保管・監視したい場合にご利用いただける機能です。


Q. Azure VM にも「診断設定」というメニューがありますが、Azure Monitor の診断設定とは異なる機能ですか。

はい、Azure VM のメニューで表示される「診断設定」は、Azure Monitor の診断設定とは別の機能です。
Azure ポータルから Azure VM を開くと [診断設定] という項目がありますが、これは Azure VM に Azure Diagnostics 拡張機能をインストールし、ゲスト OS のログやメトリックをストレージ アカウントに送信する機能です。この 2 つの機能の違いについては、Azure VM の診断設定とそれ以外のリソースにおける診断設定について のブログで詳しく説明しておりますので、ご覧いただけますと幸いです。


Q. Azure Monitor の診断設定は、すべてのリソースでサポートしていますか。

いいえ、Azure Monitor の診断設定は、すべてのリソースでサポートしておりません。
基本的には、こちらの公開情報でサポート状況をご確認いただけます。
メトリックの場合は、上記公開情報経由でアクセスできる各ページに掲載されている表の [DS エクスポート] 列が「はい」の場合、診断設定で Log Analytics ワークスペース等にエクスポート可能です。下図は Microsoft.Automation/automationAccounts の例です。

ログの場合は、各ページにカテゴリやログの出力先テーブル (宛先が Log Analytics ワークスペースの場合) が記載されています。
下図は Microsoft.Automation/automationAccounts の例です。


Q. Azure Monitor の診断設定の設定手順を教えてください。

基本的には Azure ポータルから対象リソースを選択し、[監視] - [診断設定] から構成することが可能です。
設定手順の詳細はこちらの公開情報をご覧ください。


Q. Azure Monitor の診断設定を構成する前に生成されたログやメトリック、アクティビティ ログは、ストレージ アカウントや Log Analytics ワークスペースにエクスポートされますか。

いいえ、エクスポートされません。
診断設定の構成後に生成されたログやメトリックがエクスポートされます。


Q. Azure Monitor の診断設定の構成を検討しています。私の環境の場合、コストはどれぐらいになりますか。

誠に残念ではございますが、発生する具体的なコストについては一概に回答出来ません。
理由は、ご利用いただいている Azure サービスの種類やリソースの数・Azure のご利用方法など、お客様の環境に影響して出力されるログの量が変わるからです。

弊社といたしましては、料金計算ツールを用いてコストをお見積りいただくか、最低限の Azure リソースに対して一時的に診断設定をご構築いただき、1 日あたりのログ量を計測いただくことを一般的な戦略として案内しております。Azure Monitor のコスト見積もりに関しましては、下記の公開情報もご覧いただけますと幸いです。




リソース ログ・メトリックのエクスポート

Q. Azure リソースのログやメトリックを Log Analytics ワークスペースにエクスポートすることを検討しています。必要な権限を教えてください。

診断設定を構成するリソース側と、ログのエクスポート先となる Log Analytics ワークスペース側で、以下の権限が必要です。
診断設定に関する必要な権限は、公開情報にも掲載されておりますのでご覧ください。また、ロールの割り当て手順やカスタム ロールの作成手順 も公開情報をご確認ください。

1
2
3
4
"*/read",
"Microsoft.Insights/DiagnosticSettings/read",
"Microsoft.Insights/DiagnosticSettings/write",
"Microsoft.Insights/DiagnosticSettings/delete"
1
2
"Microsoft.OperationalInsights/workspaces/read",
"Microsoft.OperationalInsights/workspaces/sharedKeys/action"

Q. Azure リソースのログやメトリックをストレージアカウントにエクスポートすることを検討しています。必要な権限を教えてください。

診断設定を構成するリソース側と、ログのエクスポート先となるストレージ アカウント側で、以下の権限が必要です。
診断設定に関する必要な権限は、公開情報にも掲載されておりますのでご覧ください。また、ロールの割り当て手順やカスタム ロールの作成手順 も公開情報をご確認ください。

1
2
3
4
"*/read",
"Microsoft.Insights/DiagnosticSettings/read",
"Microsoft.Insights/DiagnosticSettings/write",
"Microsoft.Insights/DiagnosticSettings/delete"
1
2
"Microsoft.Storage/storageAccounts/Read",
"Microsoft.Storage/storageAccounts/listkeys/action"

Q. 複数のサブスクリプションのリソース ログやメトリックを、一つの Log Analytics ワークスペースにエクスポートすることは可能ですか。

はい、可能です。
各リソースの診断設定で同一の Log Analytics ワークスペースをご指定ください。


Q. 複数のサブスクリプションのリソース ログやメトリックを、一つのストレージ アカウントにエクスポートすることは可能ですか。

はい、可能です。
ただし、診断設定を構成するリソースとストレージ アカウントは、同じリージョンである必要がございます。
診断設定の宛先に関する制限事項は、こちらの公開情報もご確認ください。


Q. 別テナントの Log Analytics ワークスペースやストレージ アカウントに対して診断設定を構成することは可能ですか。

はい、Azure Lighthouse を使用することで別テナントの Log Analytics ワークスペースやストレージ アカウントにリソース ログやメトリックをエクスポートすることが可能です。Azure Lighthouse では、あるテナントのリソースへのアクセスを、別テナント内のユーザーやグループに委任することができます。詳細は、Azure Lighthouse への顧客のオンボードをご覧ください。


Q. Azure Monitor の診断設定でリソース ログとメトリックを、ストレージ アカウントにエクスポートしています。データの格納場所を教えてください。

メトリックやログをストレージ アカウントにエクスポートすると、追加 BLOB が作成されます。
診断設定でメトリックをストレージ アカウントにエクスポートした場合には、以下の命名規則で BLOB が作成されます。

1
insights-metrics-pt1m/resourceId=/SUBSCRIPTIONS/{subscription ID}/RESOURCEGROUPS/{resource group name}/PROVIDERS/{resource provider name}/{resource type}/{resource name}/y={four-digit numeric year}/m={two-digit numeric month}/d={two-digit numeric day}/h={two-digit 24-hour clock hour}/m=00/PT1H.json

リソース共通で insights-metrics-pt1m コンテナーに情報が格納されます。


診断設定でログをストレージ アカウントにエクスポートした場合には、以下の命名規則で BLOB が作成されます。

1
insights-logs-{log category name}/resourceId=/SUBSCRIPTIONS/{subscription ID}/RESOURCEGROUPS/{resource group name}/PROVIDERS/{resource provider name}/{resource type}/{resource name}/y={four-digit numeric year}/m={two-digit numeric month}/d={two-digit numeric day}/h={two-digit 24-hour clock hour}/m=00/PT1H.json

insights-logs-{log category name} の {log category name} はリソースおよび収集するログの種類により異なりますが、基本的にこちらの公開情報経由で参照可能なカテゴリ名が利用されます。例えば、ロジック アプリの診断設定で WorkflowRuntime カテゴリのログをエクスポートした場合、insights-logs-workflowruntime コンテナーに情報が格納されます。

ログのカテゴリは、こちらの公開情報経由で Microsoft.Logic のワークフローのページを開くと確認できます。

重要

リソースによっては resourceid や resourceId のように、大文字・小文字の表記が異なる場合がございます。Azure Storage ライフサイクル管理 のルールで設定する Blob prefix は大文字・小文字を区別します。ライフサイクル管理を使用する場合に、フィルターとして当該データの格納先のパスを指定する場合は、実際の BLOB のパスをご確認の上指定いただきますようお願いいたします。


Q. Azure Monitor の診断設定でリソース ログとメトリックを、Log Analytics ワークスペースにエクスポートしています。データの格納場所を教えてください。

メトリックを Log Analytics ワークスペースにエクスポートした場合は AzureMetrics テーブルにデータが格納されます。
リソース共通で AzureMetrics テーブルにエクスポートされますので、複数のリソースを 1 つの Log Analytics ワークスペースにエクスポートしている場合は、リソース ID (_ResourceId) やメトリック名 (MetricName) 等の条件を指定して検索してください。AzureMetrics テーブルのサンプル クエリは、こちらの公開情報をご覧ください。

リソース ログを Log Analytics ワークスペースに送信する場合は 2 種類の収集モードがあり、AzureDiagnostics テーブル、または リソース固有のテーブルに格納されます。

  • Azure Diagnostics - すべてのデータが AzureDiagnostics テーブルに書き込まれます。
  • リソース固有 - データは、リソースのカテゴリごとに個別のテーブルに書き込まれます。

Azure Diagnostics とリソース固有の両方のモードをサポートしている場合は、ターゲットとして Log Analytics ワークスペースを選択すると、ターゲット テーブルを選択するオプションが表示されます。各リソースのログ出力先は、こちらの公開情報経由で参照可能な表や、Azure リソース ログの共通およびサービス固有のスキーマ、各リソース側の公開情報等をご確認ください。

例えば、Microsoft.Automation/automationAccounts の場合、AzureDiagnostics テーブルにエクスポートされることが分かります。
AzureDiagnostics テーブルのサンプル クエリは、こちらの公開情報をご覧ください。


Q. Azure Monitor の診断設定でリソース ログとメトリックを、ストレージ アカウントにエクスポートしています。データの格納場所のコンテナーを変更することはできますか。

いいえ、データの格納場所のコンテナーを変更することはできません。
リソース ログとメトリックを、ストレージ アカウントにエクスポートした場合は、Q. Azure Monitor の診断設定でリソース ログとメトリックを、ストレージ アカウントにエクスポートしています。データの格納場所を教えてください。 や Q. Azure Monitor の診断設定でリソース ログとメトリックを、Log Analytics ワークスペースにエクスポートしています。データの格納場所を教えてください。 に記載した格納場所にコンテナーが作成されます。


Q. Azure VM のプラットフォーム メトリック (ホスト OS メトリック) を Log Analytics ワークスペースにエクスポートしたいのですが、Azure ポータル上に設定画面が見当たりません。

Azure VM のプラットフォーム メトリック (ホスト OS メトリック) に関する診断設定は、Azure PowerShell 等で設定可能です。
設定手順の詳細は、こちらのブログをご参照ください。




アクティビティ ログのエクスポート

Q. アクティビティ ログの診断設定の設定手順を教えてください。

Azure ポータルから設定する場合は [監視] を検索し、[アクティビティ ログ] の [診断設定] から構成いただけます。
設定手順の詳細はこちらの公開情報をご覧ください。


Q. アクティビティ ログのカテゴリの詳細を教えてください。

アクティビティ ログのカテゴリの詳細は、Azure アクティビティ ログのイベント スキーマの公開情報をご覧ください。


Q. アクティビティ ログを Log Analytics ワークスペースにエクスポートすることを検討しています。診断設定を構成するために必要な権限を教えてください。

診断設定を構成するサブスクリプションと、ログのエクスポート先となる Log Analytics ワークスペース側で以下の権限が必要です。Azure Monitor の組み込みロールの場合、サブスクリプションをスコープとして Monitoring Contributor (監視共同作成者) や Log Analytics Contributor (Log Analytics 共同作成者) を付与いただけますと幸いです。ロールの割り当て手順やカスタム ロールの作成手順 は公開情報をご覧ください。

  • サブスクリプション スコープで必要な権限 (診断設定の作成、変更、削除)
1
2
3
4
"*/read",
"Microsoft.Insights/DiagnosticSettings/read",
"Microsoft.Insights/DiagnosticSettings/write",
"Microsoft.Insights/DiagnosticSettings/delete"
  • ログのエクスポート先となる Log Analytics ワークスペースに必要な権限
1
2
"Microsoft.OperationalInsights/workspaces/read",
"Microsoft.OperationalInsights/workspaces/sharedKeys/action"

Q. アクティビティ ログをストレージ アカウントにエクスポートすることを検討しています。診断設定を構成するために必要な権限を教えてください。

診断設定を構成するサブスクリプションと、ログのエクスポート先となるストレージ アカウント側で以下の権限が必要です。Azure Monitor の組み込みロールの場合、サブスクリプションをスコープとして Monitoring Contributor (監視共同作成者) や Log Analytics Contributor (Log Analytics 共同作成者) を付与いただけますと幸いです。ロールの割り当て手順やカスタム ロールの作成手順 は公開情報をご覧ください。

  • サブスクリプション スコープで必要な権限 (診断設定の作成、変更、削除)
1
2
3
4
"*/read",
"Microsoft.Insights/DiagnosticSettings/read",
"Microsoft.Insights/DiagnosticSettings/write",
"Microsoft.Insights/DiagnosticSettings/delete"
  • ログのエクスポート先となるストレージアカウントに必要な権限
1
2
"Microsoft.Storage/storageAccounts/Read",
"Microsoft.Storage/storageAccounts/listkeys/action"

Q. 特定のリソースのアクティビティ ログを、Log Analytics ワークスペースやストレージ アカウントにエクスポートすることは可能ですか。

いいえ、特定のリソースのアクティビティ ログのみをエクスポートすることはできません。
アクティビティ ログの診断設定はサブスクリプション単位で指定するものであり、リソース単位で設定することはできません。


Q. Azure ポータルからリソース グループの [アクティビティ ログ] > [診断設定] を開くと、アクティビティ ログの診断設定が表示されます。リソース グループ単位でアクティビティ ログの診断設定を作成できるのでしょうか。

いいえ、できません。
リソース グループの [アクティビティ ログ] > [診断設定] からも、アクティビティ ログの診断設定が表示されますが、あくまで表示されているだけであり、アクティビティ ログの診断設定はサブスクリプション単位でしか設定できません。


Q. Azure Monitor の診断設定で、アクティビティ ログをストレージ アカウントにエクスポートしています。データの格納場所を教えてください。

アクティビティ ログをストレージ アカウントにエクスポートすると、追加 BLOB が作成され、以下の命名規則で BLOB が作成されます。

1
insights-activity-logs/resourceId=/SUBSCRIPTIONS/{subscription ID}/y={four-digit numeric year}/m={two-digit numeric month}/d={two-digit numeric day}/h={two-digit 24-hour clock hour}/m=00/PT1H.json

リソース共通で insights-activity-logs コンテナーに情報が格納されます。


Q. Azure Monitor の診断設定で、アクティビティ ログを Log Analytics ワークスペースにエクスポートしています。データの格納場所を教えてください。

アクティビティ ログを Log Analytics ワークスペースにエクスポートした場合は AzureActivity テーブルにデータが格納されます。
AzureMetrics テーブルのサンプル クエリは、こちらの公開情報をご覧ください。


Q. アクティビティ ログを Log Analytics ワークスペースにエクスポートした場合、Log Analytics ワークスペースに対する料金が発生しますか。

いいえ、アクティビティ ログを Log Analytics ワークスペースにエクスポートしても、Log Analytics ワークスペースに対するインジェスト料金や保持料金は発生しません。




トラブルシューティング

Q. Azure Monitor の診断設定によるプラットフォーム メトリックやリソース ログのエクスポートは、100 % のデータ エクスポートを保証していますか。

いいえ、100 % のデータ エクスポートを保証しておりません。
診断設定は、1 日あたりペタバイト単位のデータをお手頃な価格で、効率よくエクスポートすることを前提に設計されているため、完全なトランザクションは保証しておらず、ログやプラットフォーム メトリックが一部欠損する可能性がございます。診断設定によるプラットフォーム メトリックやリソース ログの一部欠損についてのブログでも紹介しておりますので、ご確認いただけますと幸いです。


Q. Log Analytics ワークスペースやストレージ アカウントにログやメトリックをエクスポートしていますが、データが格納されていません。考えられる原因を教えてください。

考えられる原因は以下の通りです。
なお、診断設定によるエクスポートでは、制約上、プラットフォーム メトリックやログの一部欠損は発生する可能性がございますので、予めご留意ください。

1. ログの出力に時間を要している
診断設定は、基本的には 90 分以内にデータがエクスポートされ始めますが、これよりもお時間がかかることもございます。
診断設定の構成後、1 日程度お時間をおいていただき、ログを確認できるかどうかをご確認いただけますと幸いです。

2. 対象のログがそもそも生成されていない
診断設定を構成しますと、リソース側から出力されたログは、基盤側の内部パイプラインを通じて Log Analytics ワークスペースやストレージ アカウントに送信されます。そもそもリソース側でログが生成されていない場合には、Log Analytics ワークスペースやストレージ アカウントにはログが収集されません。各リソースのログが生成される条件や契機をご確認されたい場合には、各リソース観点でお問い合わせのご起票をお願いいたします。

3. ストレージ アカウントのネットワーク設定で “信頼された Microsoft サービス” が許可されていない
ログの出力先がストレージ アカウントの場合は、ストレージ アカウントのネットワーク設定により、データがエクスポートされていない可能性がございます。宛先のストレージ アカウントが選択したネットワークからのアクセスを許可する構成である場合、 [信頼されたサービスの一覧にある Azure サービスがこのストレージ アカウントにアクセスすることを許可します] が有効になっているかどうかをご確認ください。

完全に外部からのアクセスを無効にすると、Azure Monitor サービスからの通信が遮断され、ログやメトリックをエクスポートすることができません。また、選択したネットワークからのアクセスを許可する構成の場合、Azure Monitor サービスからの通信を許可するために [信頼されたサービスの一覧にある Azure サービスがこのストレージ アカウントにアクセスすることを許可します] を有効にしていただく必要がございます。

上記に該当せず、一部の欠損ではなく継続的にログやメトリックが出力されていない場合は、下記の情報をお寄せいただき、弊社サポート窓口までお問い合わせください。

・診断設定を構成しているリソースのリソース ID
・診断設定の名前
・ログやメトリックが出力されることが想定された日時 (タイムゾーンを明記してご記載ください。例. 2024-12-30 12:00 JST)
・出力されることが想定されたログのカテゴリ名やメトリック名


Q. Azure Monitor の診断設定を構成しましたが、設定が消えてしまいました。

日本語を含む、英数字以外の文字がリソース名に含まれる場合、診断設定を作成しても設定が消えることがあります。
ただし本事象は公開情報にも記載があるとおり、診断設定が英数字以外の文字をサポートしないために発生する事象であるため、製品の不具合ではございません。


Q. 新たに Azure Monitor の診断設定を構成しようとしたところ、ストレージ アカウントの保持期間を指定する項目が表示されません。以前は、診断設定にてストレージ アカウントにエクスポートした場合、保持期間を指定する項目が表示されていました。

こちらのブログでもご紹介しておりますとおり、診断設定固有のストレージ アカウントの保持機能は廃止されます。
以前は、診断設定にてストレージ アカウントを出力先としていた場合、診断設定側でログの保持期間の指定ができましたが、今後はストレージ アカウント側の Azure Storage ライフサイクル管理にて保持期間を指定する必要がございます。
また、診断設定固有のストレージ アカウントの保持機能の廃止に伴う移行手順は、こちらの公開情報をご覧ください。


上記の内容以外でご不明な点や疑問点などございましたら、弊社サポート サービスまでお問い合わせください。
最後までお読みいただきありがとうございました！

]]> https://jpazmon-integ.github.io/blog/AzureMonitorEssential/MonitorDiagnosticsSettingFAQ/ 2025-02-19T15:00:00.000Z こんにちは、Azure Monitoring サポート チームの北村です。
今回は Azure Monitor の診断設定に関するよくあるご質問をご紹介します。


]]> Azure Monitor の診断設定に関するよくあるご質問 2026-09-06T00:15:21.643Z Japan Azure Monitoring Support Team [更新履歴]

  • 2025/02/14 ブログ公開
  • 2026/01/28 最新情報への更新

こんにちは、Azure Monitoring サポート チームの北村、佐藤です。
Azure Monitor エージェントを使用した死活監視方法について本ブログで紹介します。
本ブログは、以下の過去の記事 (Log Analytics エージェントを使用した死活監視) を Azure Monitor エージェント版に更新したものとなります。
https://jpazmon-integ.github.io/blog/LogAnalytics/MonitorVM/


目次


Heartbeat を使用した死活監視を行うために

Azure Monitor エージェントを使用して死活監視をするためには、Heartbeat ログ (マシンが実行中の間、1 分間に 1 度収集されるログ) を収集する必要がございます。

まず、Azure Monitor エージェントがログを収集するよう構成する方法からご説明します。
Azure Monitor エージェントは、データ収集ルールと呼ばれるリソースに仮想マシンを関連付けることで、インストールおよび必要なデータ収集設定の連携が行われます。
データ収集ルールは、Azure Monitor エージェントを用いてどのようなログを収集するかを Azure Monitor エージェントに伝える指示書の役割を果たします。

データ収集ルールでデータ ソース (どのようなログを取得するか) として設定可能なログ種は以下の通りです。

■ Windows OS

  • イベント ログ
  • パフォーマンス
  • テキスト ログ
  • IIS ログ

■ Linux OS

  • syslog
  • パフォーマンス
  • テキスト ログ

データ収集ルールは、上述のいずれかのデータ ソースを収集するよう指定する必要があります。マシンをデータ収集ルールと関連付け、上述のデータ ソースのログ収集を開始すると、Heartbeat ログも併せて収集されるようになります。
すなわち、Azure Monitor エージェントをご利用いただく場合、基本的に Heartbeat ログを単体で収集することはできかねます。

では、以下に Azure Monitor エージェントを使用したログ収集を行うための基本的な流れを簡単にご説明します。

  1. Log Analytics ワークスペースの作成
  2. データ収集ルールの作成とデータ収集ルールへの関連付け
  3. アラート設定

1. Log Analytics ワークスペースの作成

ログの送信先となる Log Analytics ワークスペースを作成します。

– Create a Log Analytics workspace
https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/quick-create-workspace?tabs=azure-portal


2. データ収集ルールの作成とデータ収集ルールへの関連付け

1 で作成した Log Analytics ワークスペースにログを収集するよう、データ収集ルールを構成します。

– Collect data from virtual machine client with Azure Monitor
https://learn.microsoft.com/ja-jp/azure/azure-monitor/agents/azure-monitor-agent-data-collection
(“データ ソース” 項目にて、各データ ソースをクリックすることでデータ ソースごとの設定方法の公開情報に遷移します。)

データ収集ルールにマシンを関連づけると Azure Monitor エージェントがインストールされます。
(すでにインストール済みの場合には、マシン上に Azure Monitor エージェントが存在することが確認されたのち、インストールがスキップされます。)


3. アラート設定

作成した Log Analytics ワークスペースの画面左側にあるメニュー内 [ログ] をクリックします。
[ログ] 検索フィールドでクエリを実行し、アラートの設定を行います。アラートの評価期間や設定したクエリを実行する頻度、
アラートの通知方法等を設定します。詳細は以下の弊社公開情報をご覧ください。

– Create or edit a log search alert rule
https://learn.microsoft.com/ja-jp/azure/azure-monitor/alerts/alerts-create-log-alert-rule

– Action groups
https://learn.microsoft.com/ja-jp/azure/azure-monitor/alerts/action-groups

Note

(補足)

前述の通り、Azure Monitor エージェントをご利用いただく場合、基本的に Heartbeat ログを単体で収集することはできません。

どうしても、Heartbeat ログだけを収集する必要がある場合には、存在しないダミーの情報を収集するようデータ収集ルールを構成することで、実質 Heartbeat ログだけを収集すること自体は可能でございます。

<カスタム パス追加手順>

以下すべて [データ ソースの追加] タブでの設定でございます。

  1. [データ ソースの種類] にて [パフォーマンス カウンター] を選択します。
  2. [パフォーマンス カウンターを構成する] という項目で [カスタム] タブを選択します。
  3. [収集するパフォーマンス カウンターと、そのサンプリング頻度を構成します:] に “\dummy” と入力し、[追加] をクリックします。

  4. お手数ではございますが、3. で追加した “\dummy” 以外のパスの左側にあるチェックをすべて外します。

なお、パフォーマンス カウンターについて、任意の収集設定を行う方法については以下のブログ記事に記載しております。

設定方法の詳細は以下をご確認ください。

– 既定で用意されているもの以外のパフォーマンス カウンターを収集する方法

https://jpazmon-integ.github.io/blog/LogAnalytics/HowToCollectCustomPerfCounter/



Heartbeat を使用した死活監視

Heartbeat は Azure Monitor エージェントによって Log Analytics ワークスペースに既定で収集されます。
Log Analytics ワークスペースで Heartbeat のレコードを確認すると、1 分間に 1 回レコードが生成されていることがわかります。
この Heartbeat を使用した死活監視の例をご紹介します。


例 1. あるマシンから Heartbeat が収集されていることを確認する

下記クエリでは、指定した VM の Heartbeat を抽出します。

1
2
Heartbeat
| where Computer == 'computer-name'

上記クエリを利用したアラート ルールの設定例を示します。まず、アラート ルールの主な設定項目をご説明します。

  • 集計の粒度 (赤枠線部分)
    クエリで取得したログを一つのグループにまとめる単位を示します。
    以下のように 5 分と設定した場合は 5 分単位でグループ化されます。

  • 演算子としきい値 (黄色ハイライト部分)
    上記クエリは、直近 5 分以内の Heartbeat を返しますので、当該クエリの実行結果が 0 件の場合は直近 5 分間 Heartbeat が収集されていないことを意味します。そのため、演算子は 「等しい」、しきい値は 「0」 としています。

  • 評価の頻度 (黄色枠線部分)
    アラートの検索クエリが実行される間隔です。この例では、10 分ごとにクエリが実行されます。

  • 評価期間 (黒枠線部分)
    クエリの対象とするデータの時間範囲です。基本的には [集計の粒度] と同じ時間範囲になります。

  • 違反の数 (緑枠線部分)
    評価期間内にある集約ポイントのうち (集約ポイントの個数 = 評価期間 ÷ 集計の粒度) 、指定した回数以上発報条件を満たしたらアラートが発報します。
    (連続で発報条件を満たした回数ではございません。)

例えば、以下の設定であったとします。
その場合、具体的には以下の挙動となります。

1
2
3
4
集計の粒度 : 5 分
評価頻度 : 10 分
評価期間: 15 分
違反の数 : 2 (評価期間内に 2 回閾値を超えたら発報する構成の場合)

以下、〇はしきい値を超えること、×はしきい値を超えないことを表します。
10:00 の評価
9:45 ~ 9:50 のログ : ×
9:50 ~ 9:55 のログ : 〇
9:55 ~ 10:00 のログ : ×
———> 発報しない

10:10 の評価
9:55 ~ 10:00 のログ : ×
10:00 ~ 10:05 のログ : 〇
10:05 ~ 10:10 のログ : 〇
———> 発報する

10:20 の評価
10:05 ~ 10:10 のログ : 〇
10:10 ~ 10:15 のログ : ×
10:15 ~ 10:20 のログ : 〇
———> 発報する

<ご参考>
アラートの設定項目は下記弊社公開情報にも記載しております。
–- Create or edit a log search alert rule
https://learn.microsoft.com/ja-jp/azure/azure-monitor/alerts/alerts-create-log-alert-rule


例 2. 直近 15 分間に Heartbeat が途絶えた VM を確認する

下記クエリでは、直近 15 分間、VM の Heartbeat が送信されなかった場合に検知します。
LastCall は 各コンピューターの Heartbeat が生成された最新の時刻です。
Heartbeat の最新時刻が 15 分より前の場合、実行結果が返されます。

1
2
3
Heartbeat
| summarize LastCall = max(TimeGenerated) by Computer 
| where LastCall < ago(15m)

Note

アラートルールで設定する場合、アラート ルール側では [集計の粒度] で 15 分より長い粒度 (期間) を指定する必要があります。

例えばこのクエリを利用する場合には、以下の様に設定する必要があります。

メジャー: テーブルの行

集計の種類: カウント

集計の粒度: 30 分 (クエリで指定した期間より長い期間)

演算子: 次の値より大きい

しきい値: 0

頻度: 15分


例 3. 直近 2 日間に Heartbeat が記録されたマシンのうち、直近 5 分間に Heartbeat が途絶えた VM を確認する

下記クエリでは、直近 2 日間に Heartbeat が記録されたマシンの中で、直近 5 分間に Heartbeat が途絶えた VM を検知します。
変数 ComputerListFor2days には、直近 2 日間に Heartbeat が記録されたマシンと、最新の TimeGenerated の情報が格納されます。
次に、直近 5 分間に収集された Heartbeat と、変数 ComputerListFor2days のデータを、Computer 列で rightouter 結合します。
最後に、直近 5 分間に Heartbeat が記録されていないマシン の AggregatedValue を 0 に設定します。
この AggregatedValue の値を監視することで Heartbeat が収集されなくなったマシンを検知することが可能です。

1
2
3
4
5
6
7
8
9
10
11
let ComputerListFor2days =
    (Heartbeat
    | where TimeGenerated > ago(2d)
    | summarize max(TimeGenerated) by Computer
    );
Heartbeat
| where TimeGenerated > ago(5m)
| summarize count() by Computer 
| join kind=rightouter ComputerListFor2days on $left.Computer == $right.Computer
| extend AggregatedValue = iif(isnull(count_), 0, count_)
| project ComputerName = Computer1, AggregatedValue

上記クエリの設定例をご紹介します。
下記の設定の場合、[評価の頻度] の 5 分毎に、直近 2 日間に Heartbeat が記録されたマシンのうち、直近 5 分間に Heartbeat が途絶えた VM を検知します。また、ディメンション名 で ComputerName を指定することで、VM 単位で Heartbeat が途絶えたことを監視できます。



Heartbeat の収集が遅延していることを確認する

死活監視のアラートを検知したにもかかわらず、監視対象の VM は正常に動作している。
このようなときは、Heartbeat の収集遅延が発生している可能性がございます。

– Azure Monitor でのログ データ インジェスト時間
https://docs.microsoft.com/ja-jp/azure/azure-monitor/logs/data-ingestion-time

※ ログ データを取り込むための一般的な待ち時間は 20 秒から 3 分です。ただしシステムの負荷状況によりさらに遅延が発生する可能性がございます。

Heartbeat の収集遅延には、様々な理由が考えられますが、以下のクエリを実行していただきますと、
“Azure Monitor エージェントがデータを生成してから Azure 側でデータを受信するまで” の間に遅延が発生していたことを確認できます。

1
2
3
4
5
Heartbeat
| where Computer == "Computer Name"
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated
| project Computer, TimeGenerated, _TimeReceived, ingestion_time(), E2EIngestionLatency
| order by TimeGenerated desc

※ TimeGenerated : データ ソースが生成された時刻
※ _TimeReceived : Azure Monitor のインジェスト エンドポイントによって受信される時刻
※ $ingestion_time : Log Analytics ワークスペースに保存され、クエリ検索が可能となる時刻
※ E2EIngestionLatency : ログが生成されてから Log Analytics ワークスペースにログが送信されるまでに要した時間

下記画像は上記クエリを実行した例です。
赤線で囲んだ部分が「ログが生成されてから Log Analytics ワークスペースにログが送信されるまでに要した時間」です。

Heartbeat ログ アラートが期待されないタイミングで発報した場合の調査方法については、よろしければ以下のブログ記事もご参照ください。

– マシンが起動中にも関わらず Heartbeat ログ アラートが発報された場合の調査方法
https://jpazmon-integ.github.io/blog/LogAnalytics/Unexpected_Heartbeat_logalert/


まとめ

本記事では、Azure Monitor エージェントを使用して Heartbeat ログを収集する方法および、収集された Heartbeat ログを用いて死活監視を行う方法をご案内いたしました。

Heartbeat ログを含め、仮想マシンの死活監視全般については以下のブログ記事でもご案内しております。よろしければこちらもご参照いただけますと幸いです。

– Azure VM における死活監視の考え方
https://jpazmon-integ.github.io/blog/LogAnalytics/MonitorVM02/

最後までお読みいただき、ありがとうございました！

]]> https://jpazmon-integ.github.io/blog/LogAnalytics/MonitorVM_AMA/ 2025-02-13T15:00:00.000Z [更新履歴]

  • 2025/02/14 ブログ公開
  • 2026/01/28 最新情報への更新

こんにちは、Azure Monitoring サポート チームの北村、佐藤]]>

Azure Monitor エージェントにより収集される Heartbeat ログを使用した死活監視方法 2026-09-06T00:15:21.926Z Japan Azure Monitoring Support Team [更新履歴]

  • 2025/01/29 : ブログ公開
  • 2025/10/21 : アラートの重複と検知漏れに関する情報を追記
  • 2026/02/06 : 最新の情報であることを確認済み

こんにちは、Azure Monitoring サポート チームの北村です。
今回は Azure Monitor のアラートに関するよくあるご質問をご紹介します。
リソース正常性アラートやサービス正常性アラートについては、別途ブログを投稿しておりますので併せてご覧いただけますと幸いです！


<メトリック アラート ルール>


<ログ アラート ルール>


<アクティビティ ログ アラート（サービス正常性アラート、リソース正常性アラート、アクティビティ ログ アラート）>


<アクション グループ、アラート処理ルール>




メトリック アラート ルール

Q. メトリック アラート ルールの設定項目を教えてください。

メトリック アラート ルールの設定項目は、公開情報をご確認いただけますと幸いです。
また、動的しきい値を利用したメトリック アラートについては こちらの公開情報もご参照ください。

アラート ロジックメトリックの値を集計する方法、集計された値と比較する際のしきい値等を指定します。

※ 静的しきい値を選択したときの設定項目です。

※ 動的しきい値を選択したときの設定項目です。

しきい値静的しきい値では指定した値に基づいて評価されます。
動的しきい値では機械学習アルゴリズムを使用してメトリックの動作パターンが継続的に学習され、予期しない動作に該当するしきい値が計算されます。
集計の種類[ルックバック期間] で設定した期間において、データをまとめる方法を選択します。
演算子集計された値と比較する際に、どの様な比較を行うかを設定します。
しきい値 (静的しきい値)集計された値と比較する際に使用するしきい値を数値で設定します。
しきい値の感度 (動的しきい値)アラートをトリガーする感度のレベルを指定します。

ディメンションディメンションは、メトリック値に関する追加のデータ (名前と値のペア) です。メトリックは、個々のリソースごとに記録されますが、ディメンションはメトリックの値をより詳細に説明するための追加情報とお考えください。ディメンションを分割しない場合、メトリックのデータをより細かく分析するための要素を考慮せずに集計されます。一方で、ディメンションを分割した場合には、そのディメンションで集計されたデータが監視され、メトリックのデータをより細かく分析することができます。また、複数のディメンション値を選択した場合は、その組み合わせによって集計されたデータごとに監視されます。詳細はこちらの公開情報ごご覧いただけますと幸いです。
ディメンション名メトリックの特定列によって分割したい場合に利用します。

評価するタイミング1 回の評価を行う際に評価の対象となる期間と、評価の頻度を設定します。

※ 静的しきい値を選択したときの設定項目です。

※ 動的しきい値を選択したときの設定項目です。

確認する間隔集計された値としきい値の比較を行う頻度です。[確認する間隔] は [ルックバック期間] で設定した期間以下とする必要があります。
ルックバック期間1 回の評価を行う際に評価の対象となる期間を設定します。
違反の数 (動的しきい値)アラートをトリガーするために発生する必要がある違反の数を設定します。
範囲 (動的しきい値)違反の数を評価する期間です。[範囲] で指定した期間を、[ルックバック期間] で分割され、しきい値を違反していた数を確認します。



Q. メトリック アラート ルールの設定にて [確認する間隔] と [ルックバック期間] はどのように選ぶのが良いですか？

[確認する間隔] と [ルックバック期間] を設定する際の注意点について説明します。

“確認する間隔 == ルックバック期間” の設定の場合、メトリックが評価可能になるまでの遅延による影響を受ける可能性が高くなります。

アラート ルールを設定する際には、監視の目的に応じて以下のように設定することをご検討ください。

【漏れを防ぎたい (重複して検知を容認する) 】確認する間隔 < ルックバック期間

【重複検知を防ぎたい (検知漏れを容認する) 】 確認する間隔 == ルックバック期間



Q. 静的しきい値のメトリック アラート ルールで、2 回連続でしきい値を満たした時にアラートを発報させることはできますか。

メトリック アラートでは「特定の条件を満たした状態が N 回継続したときに通知する」という設定ではできません。

一方で、監視対象のメトリックがプラットフォーム メトリックであり、Azure Monitor の診断設定でメトリックを Log Analytics ワークスペースに転送できる場合には、ログ アラート ルールにてご要件を満たす設定が実現できる可能性があります。

ログ アラート ルールの場合は [違反の数] を利用することで、特定の条件を満たした状態が N 回継続したときに通知することが可能です。大まかな設定手順は以下の通りです。

  1. Azure Monitor の診断設定の機能で Log Analytics ワークスペースにメトリックをエクスポートする
  2. 対象の Log Analytics ワークスペースをスコープにして、ログ アラート ルールを作成する

メトリックを Log Analytics ワークスペースにエクスポートすると、Log Analytics ワークスペース上では AzureMetrics というテーブルに格納されます。例えば、Azure VM の Percentage CPU の平均値を監視している場合、以下のようなクエリでメトリックの平均値を確認することができます。

1
2
3
4
AzureMetrics
| where _ResourceId =~ "<リソース ID>" // 目的のリソースで絞ります
| where MetricName contains "Percentage CPU" // 目的のメトリックで絞り込みます
| project TimeGenerated, ResourceProvider, MetricName, Average

ログ アラート ルールの場合は、これらの値を利用してログ アラート ルールを設定します。
例えば、[評価の頻度] が 5 分、[集計の粒度] が 5 分、[違反の数] を 3、[評価期間] が 15 分と設定したとします。
この場合、[評価の頻度] の 5 分毎に、15 分の [評価期間] が 5 分の [集計の粒度] で分割されます (15 ÷ 5 = 3)。この 3 つのグループの中で閾値を違反するグループが 3 つあった場合にアラートが発報します。ログ アラート ルールの設定項目は、本ブログの「ログ アラート ルールの設定項目を教えてください」もご覧ください。



Q. メトリック アラート ルールが実行されるタイミングを指定することはできますか。

Azure Monitor のアラート ルールでは、アラートが実行されるタイミングを指定することはできません。
アラート ルールが作成された時点から指定された "確認する間隔" のタイミングでアラート ルールが実行されるとご認識ください。



Q. メトリック アラート ルールで時間帯によって条件を変更することはできますか。

メトリック アラート ルールで時間帯によって条件を変更することはできません。
時間帯によって条件を変更したい場合には、以下の方法をご検討ください。

  • 複数のメトリック アラート ルールを作成し、アラート処理ルールを使用して特定の時間帯の通知を抑制する
  • 監視対象のメトリックをログとして Log Analytics ワークスペースに収集できる場合には、ログ アラート ルールで監視する


Q. ステートフルなメトリック アラート ルールで起動済み (Fired) のアラートを、手動で解決済み (Resolved) に変更することはできますか。

いいえ、手動で解決済みに変更することはできません。
メトリックの値がしきい値を満たさなくなるように Azure リソースを操作してください。



Q. メトリック アラート ルールのディメンション値のドロップ ダウンに値が表示されません。

ディメンションは過去 48 時間のデータをもとに表示されます。
過去 48 時間以内に当該ディメンション値を含むメトリックが記録されていない場合は、ディメンション値のドロップダウンには表示されません。ディメンション値が表示されない場合はカスタム値として設定いただきますようお願いいたします。



Q. メトリック アラート ルール編集画面の [プレビュー] ではしきい値を満たしていたように見えますが、アラートが発報していません。

下図はプレビュー画面であり、実際のアラート ルールの評価時刻やルックバック期間に基づいた集計の粒度で表示されていない場合がございます。このため、実際にはしきい値を満たしていない場合でも、プレビュー画面上ではしきい値を満たしているように表示されてしまう場合もございます。

こちらの公開情報の手順に沿って、しきい値を満たしていたと推測される時間帯のメトリック値をご確認ください。
メトリック エクスプローラー上でもアラートのしきい値を満たしている場合には、何らかの原因によりアラートが想定通り発報しなかった可能性がございます。アラートの検知漏れの調査をご要望の場合には、以下の情報をご記載の上、お問い合わせをご起票ください。

・アラート ルールのリソース ID
・アラートが発報されることが想定された日時 (タイムゾーンを明記してご記載ください。例. 2024-12-30 12:00 JST)



Q. メトリック アラート ルールの利用料金を教えてください。

メトリック アラート ルールは、監視対象の時系列ごとに課金されます。時系列はメトリックではなく、監視する単位とお考え下さい。例えば、静的メトリック アラート ルールで 10 個の VM を対象に 4 つのメトリックを監視した場合の月額料金は以下のとおりです。

(10 VM * 4 メトリック時系列/VM - 10 無料ユニット分) * メトリック時系列あたりの価格/月

また、アラート ルールにご指定いただくメトリック数 (条件数) 以外に、ディメンション分割した場合もメトリックの時系列が増加します。例えば、静的メトリック アラート ルールで 10 個の VM を対象に 4 つのメトリックを監視し、このうち 1 つのメトリックで 1 つのディメンションを選択してディメンションの値を 2 つ指定した場合、月額料金は以下のように計算されます。

(10 VM * 3 メトリック時系列/VM + 10 VM * 1 メトリック時系列/VM * 1 ディメンション * 2 個 - 10 無料ユニット分) * メトリック時系列あたりの価格/月

価格の詳細は Azure Monitor 価格サイトや計算ツールをご覧ください。
なお、アクション グループによってメールや SMS 等でアラートを通知している場合には、別途アクション グループに関するご利用料金も発生しますのでご留意ください。




ログ アラート ルール

Q. ログ アラート ルールの設定項目を教えてください。

ログ アラート ルールの設定項目は、公開情報をご確認いただけますと幸いです。

測定ログ検索を行う検索期間、実行結果の集計方法を指定します。例えば、[集計の粒度] を 10 分、[集計の種類] を [平均] とした場合、10 分間の期間にあるデータを平均化し、その値をアラート検知に利用します。
メジャー集計対象のテーブルの行または数値列を選択します。
集計の種類[集計の粒度] で設定した期間において、データをまとめる方法を選択します。
集計の粒度クエリで取得したログを一つのグループにまとめる単位を示します。

ディメンションディメンションごとに分割すると、数値列または文字列の組み合わせがグループ化され、複数の Azure リソースで同じ条件を監視できます。複数のディメンション値を選択した場合は、その組み合わせによって生成される時系列ごとに独自のアラートがトリガーされ、個別に処理されます。
リソース ID 列クエリ結果に リソース ID が含まれていると、自動的に検出され、選択状態となります。リソース ID を指定した場合、リソース ID 毎にアラートのターゲットとして分割され、リソース ID 別にアラートの検知、通知が行われます。
ディメンション名リソース ID 以外の特定列によって分割したい場合に利用します。

アラートロジック[測定] の設定によって集計された値と比較する際のしきい値と、評価の頻度を設定します。
演算子[測定] の設定によって集計された値と比較する際に、どの様な比較を行うかを設定します。
しきい値[測定] の設定によって集計された値と比較する際に、使用するしきい値を数値で設定します。
評価の頻度[測定] の設定によって集計された値としきい値の比較を行う頻度です。[評価の頻度] は [集計の粒度] で設定した期間以下とする必要があります。


Q. ログ アラート ルールの設定にて [評価の頻度] と [集計の粒度] はどのように選ぶのが良いですか？

[評価の頻度] と [集計の粒度] を設定する際の注意点について説明します。
Log Analytics ワークスペースに収集されるデータは、収集遅延や待機時間が発生いたします。
このログ取り込みにかかる平均待機時間は一般的には 20 秒から 3 分ですが、システムの負荷状況などによりさらに遅延が発生する可能性があります。

“評価の頻度 == 集計の粒度” の設定ですと、ログの取り込みにかかる時間や収集遅延による影響を受ける可能性がより高くなります。

アラート ルールを設定する際には、監視の目的に応じて以下のように設定することをご検討ください。

【漏れを防ぎたい (重複して検知を容認する) 】 評価の頻度 < 集計の粒度

【重複検知を防ぎたい (検知漏れを容認する) 】 評価の頻度 == 集計の粒度



Q. ログ アラート ルールが実行されるタイミングを指定することはできますか。

Azure Monitor のアラート ルールでは、アラートが実行されるタイミングを指定することはできません。
アラート ルールが作成された時点から指定された "評価の頻度" のタイミングでアラート ルールが実行されるとご認識ください。



Q. ログ アラート ルールのディメンション値のドロップ ダウンに値が表示されません。

メトリック アラート ルールと同様、ディメンションは過去 48 時間のデータをもとに表示されます。
過去 48 時間以内に当該ディメンション値を含むログが記録されていない場合は、ディメンション値のドロップダウンには表示されません。ディメンション値が表示されない場合はカスタム値として設定いただきますようお願いいたします。



Q. ログ アラート ルールでディメンションを設定し、各ディメンションのログが 0 件のときに発報するルールを作成しました。特定のディメンションを含むログの出力を停止しましたが、アラートが発報しません。

ログ アラート ルールでディメンションを分割した場合、すべてのディメンションのログが 0 件のときにはアラートが検知されますが、一部のディメンションが 0 件のときには、アラートが検知されません。例を用いて説明します。

例えば、Windows マシンでパフォーマンス カウンターを収集し、「\Process(*)\ID Process」を監視するアラートを構成していたとします。
ログ アラート ルールに対して下記のようなクエリを指定し、Computer と InstanceName でディメンション分割されたと仮定します。

1
2
3
Perf
| where ObjectName == "Process"
| where CounterName == "ID Process"

このアラート ルールで [集計の粒度] を 5 分とした場合、下記のように直近 5 分間のログを検索し Computer、InstanceName 列でレコード数を集計したデータを、ログ アラート ルールは確認します。つまり、Log Analytics ワークスペースに存在するログに対してディメンション分割されます。

1
2
3
4
5
Perf
| where TimeGenerated > ago(5m) // 集計粒度が 5 分なので、直近 5 分間のログを取得
| where ObjectName == "Process"
| where CounterName == "ID Process"
| summarize count() by Computer, InstanceName, bin (TimeGenerated, 5m) // Computer と InstanceName でレコード数を集計する

上記のクエリで特定のプロセスを停止し、5 分以上当該プロセス情報が送信されていなかったとしても、そもそも直近 5 分間のログとして監視対象のプロセスに該当するログが存在しないため、そのプロセスに対するディメンション分割ができず、アラート ルールは検知できません。

一方で、下記のようにログ アラート ルールを設定いただくことで、このような問題を回避することができます。
このクエリでは、過去 2 日間のデータをプロセス リストとして取得し、直近 5 分間のデータとジョインしてレコードの数をカウントします。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
let Computer_InstanceList =
( Perf
| where TimeGenerated > ago(2d)
| where ObjectName == "Process"
| where CounterName == "ID Process"
| summarize max(TimeGenerated) by Computer, InstanceName 
);
Perf
| where TimeGenerated > ago(5m)
| where ObjectName == "Process"
| where CounterName == "ID Process"
| summarize count() by Computer, InstanceName 
| join kind=rightouter Computer_InstanceList on $left.Computer == $right.Computer and $left.InstanceName == $right.InstanceName
| extend AggregatedValue = iif(isnull(count_), 0, count_)
| project ComputerName = Computer1, AggregatedValue, InstanceName = InstanceName1

< 測定 >
メジャー : AggregatedValue
集計の種類 : 合計
集計の粒度 : 2 日

< ディメンションで分割する >
リソース ID 列 : 分割しない
ディメンション設定 : ComputerName と InstanceName を指定

< アラート ロジック >
演算子 : 次の値以下
しきい値 : 0
評価の頻度 : 5 分



Q. ログ アラート ルールの設定画面を開いたところ、アラート ルールによって UI が異なります。

ログ アラート ルールの API バージョンによって UI が異なります。
API のバージョンが 2021-08-01 以降の場合は新 UI、バージョン 2018-04-16 以前であれば旧 UI で表示されます。

旧 UI のアラート条件を設定する画面です。

新 UI のアラート条件を設定する画面です。

ログ アラート ルールの API バージョンは、Azure Resource Graph クエリで確認することができます。Azure ポータルで [Resource Graph エクスプローラー] (Azure Resource Graph エクスプローラー) を開き、API バージョンをご確認ください。また、API バージョンの違いによる UI の差異については、こちらのブログでも紹介しておりますので、ぜひご覧下さい。

1
2
3
4
5
6
resources
| where subscriptionId == "サブスクリプション ID"
| where type == "microsoft.insights/scheduledqueryrules"
| extend createdWithApiVersion = properties['createdWithApiVersion']
| where kind != 'LogToMetric'
| project id, createdWithApiVersion


Q. 旧 API (バージョン 2018-04-16 以前) のログ アラート ルールを作成する方法を教えてください。

旧 API バージョンのログ アラート ルールを作成する場合は ARM テンプレートや REST API を利用してアラート ルールをデプロイしてください。Azure ポータルからログ アラート ルールを作成した場合は、現行の API (バージョン 2021-08-01 以降) でデプロイされます。弊社サイトの 「(バージョン 2018-04-16 以前) 」 と記載されたテンプレートは旧 API バージョンの ARM テンプレートになります。また、REST API の場合はこちらのサイトをご覧ください。



Q. ログ アラート ルールで通知されるメールの件名や本文をカスタマイズすることはできますか。

Azure Monitor で通知されるアラートのメールは、カスタマイズすることはできません。
メール本文のカスタマイズが必要な場合には、Logic Apps 等でお客様にて作りこんでいただく必要がございます。
弊社 Integration Support Blogでは Logic Apps を利用してログ アラート ルールのメールを通知する方法を紹介しておりますので、ご覧いただけますと幸いです。



Q. ログ アラート ルールで通知されたメールの件名やフォーマットが変わりました。原因を教えてください。

ログ アラート ルールの API バージョンの差異によってフォーマットが異なるメールが通知された可能性がございます。
現行の API (バージョン 2021-08-01 以降) のログ アラート ルール (ログ アラート ルール V2) で、非共通アラート スキーマの場合に送られる通知メールのフォーマットが変更されました。アラート ルールによって通知されるメールのフォーマットが異なる場合には、アクション グループの共通アラート スキーマの設定をご確認ください。こちらのブログでアクション グループの設定を確認する方法や、フォーマットが変更された背景等をご案内しておりますので、ご確認いただけますと幸いです。



Q. ログ アラート ルールが勝手に無効化されていました。考えられる原因を教えてください。

ログ アラート ルールの検索クエリの実行が継続して失敗している可能性があります。
ログ アラート ルールは、クエリなどの失敗が 1 週間続いた場合、Azure Monitor によって自動で無効化されます。クエリの構文や該当のテーブルにログが出力されているかどうかをご確認ください。

また、ログ アラート ルールにて Azure Data Explorer や Azure Resource Graph クエリを設定する際には、システム割り当てマネージド ID、またはユーザー割り当てマネージド ID を有効化し、閲覧者権限を付与いただく必要がございます。マネージド ID に必要な権限が付与されていない場合、Azure Data Explorer や Azure Resource Graph に対してクエリを実行できません。Azure Data Explorer や Azure Resource Graph クエリを設定している場合には、マネージド ID に必要な権限が付与されているかどうかもご確認ください。



Q. ログ アラート ルールの利用料金を教えてください。

ログ アラート ルールは、評価の頻度毎に月額料金が設定されています。また、ディメンション分割した場合、評価される時系列が増えますので時系列に対するご利用料金も発生します。

例えば、評価の頻度が 5 分のログ アラート ルールで 2 つのディメンションを選択し、それぞれディメンションの値を 2 つ指定した場合、評価される時系列は 2 * 2 = 4 時系列となり、月額料金は以下のように計算されます。

頻度 5 分のログ アラート ルールの価格/月 + (4 時系列 - 無料の 1 時系列) * 頻度 5 分の時系列の価格/月

価格の詳細は Azure Monitor 価格サイトや計算ツールをご覧ください。
なお、アクション グループによってメールや SMS 等でアラートを通知している場合には、別途アクション グループに関するご利用料金も発生しますのでご留意ください。




アクティビティ ログ アラート（サービス正常性アラート、リソース正常性アラート、アクティビティ ログ アラート）

Q. サービス正常性アラートでテスト発報することは可能ですか。

サービス正常性アラートでは、テスト アラートという仕組みはございません。
一方で、アクション グループにはテスト通知機能がございます。通知のテストを実施されたい場合には、テスト アクション グループ機能をご利用いただけますと幸いです。



Q. サービス正常性アラートで通知された内容について確認したいです。

サービス正常性アラートで通知された内容についてご不明な点がある場合、基本的には該当するサービス観点でお問い合わせをご起票くださいますようお願いいたします。サービス正常性のメールでは、メールの下部に該当するサービス名が記載されております (下記例の場合は Azure Resource Manager 観点でお問い合わせをご起票ください)。

また、サービス正常性のイベントには Tracking-ID (追跡 ID) が付与されておりますので、Tracking-ID の情報もご記載ください。



Q. サービス正常性アラートで通知されたメールを、メールの件名でフォルダ分けしたいです。件名のルールを教えてください。

サービス正常性アラートのメールの件名や本文の内容は、特に決められた形式はございません。
メールの件名や通知内容は各サービスの弊社開発エンジニアが決定しております。ご参考までに過去に通知されたサービス正常性アラートの件名やメールで通知された内容を紹介しますが、決められた形式はないこと、ご了承ください。

イベントの種類 イベントの内容 過去に通知されたメール件名の例 過去に通知されたメールの内容
サービスに関する問題 サービスの問題は、Azure サービスに影響する問題が発生した際のイベント Azure Resource Manager - Investigating Azure Resource Managerプラットフォームに依存するサービスのリソース作成で問題が発生する可能性があることを通知した内容です。
計画メンテナンス 定期的なメンテナンスは、Azure サービスの可用性に影響を及ぼす可能性のあるメンテナンスが発生した際のイベント Advance Notification for Scheduled Maintenance to Azure Database for MySQL Azure Database for MySQLの定期メンテナンスの事前通知のメールです。
正常性の勧告 ユーザーが注目すべき Azure サービスの変更が発生した際のイベント Action recommended: Allow communication with new Azure SQL Database gateways by 1 September 2020 SQL Databaseの更新に伴い、推奨される操作をご案内した内容です。
セキュリティ アドバイザリ Azure サービスの可用性に影響する可能性があるセキュリティ関連の通知または違反があった際のイベント Security - Critical: Certificate Authority revocation due to non-compliance of your certificates potentially impacting 一部の証明書の失効に伴う影響について通知をするメールです。


Q. サービス正常性アラートで、現在利用しているサービスに関する通知のみを受け取りたいです。

サービス正常性アラート設定時の “サービス” や “リージョン” ですべて選択いただくことをご検討ください。
サービス正常性アラートは、ご利用いただいているサービスのご利用いただいているリージョンを対象としたイベントが発生した場合にのみ通知が行われる仕組みです。このため、サブスクリプション上のすべてのサービス、リージョンおよびイベントの種類を選択した場合にも、利用していないリソースに対してアラートは発生いたしません。サービス正常性アラートのサポート ブログ もあわせてご確認ください。



Q. Azure サービスの廃止に関する通知を受け取り、通知の内容に沿って移行作業を実施しましたが、同様の通知が再度通知されました。対応が完了していないリソースが存在するということでしょうか。

サービスの廃止や仕様の変更等、ご利用いただいているお客様に影響が大きいと推測される通知は、対象となるリソースが存在しない場合も、そのサービスをご利用いただいている幅広いお客様に通知させていただくことがございます。予めご了承ください。



Q. サービス正常性アラートやリソース正常性アラートを利用し、アクション グループでメール通知を設定しています。利用料金を教えてください。

メールの通知に関する費用のみが発生します。
アラート ルールで通知する場合、基本的にアラート ルールに対する料金と通知の料金が発生します。アクティビティ ログ アラート (サービス正常性やリソース正常性アラートを含む) の場合は、アラート ルールに対する料金は発生しません。
価格の詳細は Azure Monitor 価格サイトや計算ツールをご覧ください。

Note

リソース正常性アラートについては別途ブログを作成しております。




アクション グループ、アラート処理ルール

Q. アクション グループの処理が失敗したことを検知する方法はありますか。

誠に恐れ入りますが、基本的にアクション グループの失敗を検知する方法はございません。
アクション グループによる通知処理が失敗する原因は、主に以下の 2 つが考えらえます。

  • Azure 側の障害でアクション グループがトリガーされなかった
  • アクション グループはトリガーされたが、何かしらの原因で処理が失敗した

前者の場合は Azure のサービス正常性アラートで通知される可能性はございます。
一方で、後者の場合はお客様環境で確認いただく方法がなく、現時点でアクション グループの失敗を検知することができません。

アクション グループによって通知処理が失敗した原因の調査をご希望の場合は、以下の情報をもってお問い合わせをご起票くださいますようお願いいたします。

・アラート ルールのリソース ID
・アクション グループのリソース ID
・アラートが発報した日時 (タイムゾーンを明記してご記載ください。例. 2023-03-15 12:00 JST)
・アラート ID



Q. アラートが発報しましたが、メールが届いていません。考えられる原因を教えてください。

考えられる主な原因は以下の通りです。
こちらの公開情報にもトラブルシューティングのステップが掲載されておりますのでご確認ください。

  • 通知されたメール アドレスが許可されていない
  • アラート処理ルールによってメールの通知が抑制された
  • アクション グループで登録解除されていた
  • メールのレート制限に達した

Azure Monitor から送られるメールは以下のアドレスが利用されます。メール アドレスがブロックされていないかどうかをご確認ください。

・azure-noreply@microsoft.com
・azureemail-noreply@microsoft.com
・alerts-noreply@mail.windowsazure.com

アラート処理ルールによってメールの通知が抑制された可能性もございます。
Azure ポータルの [監視] - [アラート] から、アラート処理ルールでアラートの通知が抑制されていないかどうかをご確認ください。

アクション グループのメール アドレスが登録解除されている可能性もございます。
Azure ポータルからアクション グループの編集画面を開き、[通知] の [状態] で 登録解除済み と表示されている場合は、こちら のブログを参考にメール アドレスの再登録をお願いいたします。

また、アクション グループには制限がございます。メールの場合は 1 時間に 100 通のレート制限があり、この制限に触れた場合は通知が停止されます。この制限に抵触すると、当該のアドレスに「We’ve temporarily paused your Azure email notifications」という通知メールが届きますので、このレート制限の影響でメールが届いていないとご判断いただけます。

上記に該当しない場合は、Azure Monitoring サポートまでお問い合わせをご起票ください。
お問い合わせをご起票いただく際には、以下の情報をご連携くださいますようお願いいたします。

・アラート ルールのリソース ID
・アクション グループのリソース ID
・アラートが発報した日時 (タイムゾーンを明記してご記載ください。例. 2023-03-15 12:00 JST)
・アラート ID



Q. アクション グループでメールを通知しています。利用料金を教えてください。

課金アカウント毎に 1,000 通までは無料でご利用いただけますが、この無料枠を超えた場合はご利用料金が発生します。
100,000 通につき $2 の場合、1,001 通目から 100,000 通目までは、$2 となります。
100,001 通 から 200,000 通目までは、さらに + $2 となり、＄4 となります。
現時点の価格の詳細は Azure Monitor 価格サイトや計算ツールをご覧ください。通知の種類 (メール、webhook、SMS など) によってご利用料金が異なりますので、アクション グループの設定内容に応じてご確認ください。



Q. アラート処理ルールのスコープでは、通知を抑制したいアラート ルールを指定すればよいのでしょうか。

いいえ。アラート処理ルールのスコープでは、影響を受けるリソースを指定してください。
影響を受けるリソース は、Azure ポータルの [監視] > [アラート] でご確認いただけます。
必ずしも、アラート ルールのスコープと 影響を受けるリソース が一致するとは限りませんので、ご注意ください。

また、スコープでサブスクリプションやリソース グループを選択することも可能ですが、サブスクリプションやリソース グループに存在するリソースを対象とした、すべてのアラート ルールにアラート処理ルールが適用されますので、ご注意ください。



Q. アラート処理ルールを利用していますが、Azure ポータルの [監視] > [アラート] でアラートが発報しているようです。

アラート処理ルールは、アクション グループの適用/抑制を行う機能であり、アラート ルールの実行自体を抑制するものではございません。 アラートの発報や解決自体を抑制する機能ではございませんので、ご留意ください。



Q. アラート処理ルールによってアラート ルールの通知が抑制されたことを確認する方法を教えてください。

Azure ポータルの [監視] - [アラート] を開き、[履歴] を選択してください。
アラート処理ルールでアラートの通知が抑制された場合は、以下のように表示されます。



Q. アラート処理ルールのスコープは「サブスクリプション」や「リソース グループ」の単位で登録した方がよいですか。

弊社としては推奨している単位はございません。
監視対象となるリソース、リソース グループ、サブスクリプションのいずれか、お客様のご要件に沿うものをご指定ください。

アラート処理ルールのスコープでサブスクリプションやリソース グループを選択した場合、その配下に存在するリソースを対象とした、すべてのアラート ルールにアラート処理ルールが適用されます。特定のアラート ルールにアラート処理ルールを適用されたい場合には、フィルターの条件で [アラート ルール ID] もしくは [アラート ルール名] で通知を抑制したいアラート ルールをご指定ください。



Q. ステートフルなアラート ルールを設定しています。アラートが「解決」したときのみ通知を抑制することはできますか。

はい、可能です。
アラート処理ルールでは、任意の時間帯にアクション グループを適用したり、抑制したりすることができます。
下図のようにアラートの条件に対して「解決済み」をご指定いただくことで、解決済みのアラートに対してアクション グループを抑制することが可能です。



Q. アラート処理ルールでサービス正常性アラートの通知を抑制することはできますか。

いいえ。
サービス正常性アラートはアラート処理ルールで通知を抑制することはできません。



上記の内容以外でご不明な点や疑問点などございましたら、弊社サポート サービスまでお問い合わせください。
最後までお読みいただきありがとうございました！

]]> https://jpazmon-integ.github.io/blog/AzureMonitorEssential/MonitorAlertFAQ/ 2025-01-28T15:00:00.000Z [更新履歴]

  • 2025/01/29 : ブログ公開
  • 2025/10/21 : アラートの重複と検知漏れに関する情報を追記
  • 2026/02/06 : 最新の情報であることを確認済み

こんにちは、Azure Monitoring サポート チームの北村です。
今回は Azure Monitor のアラートに関するよくあるご質問をご紹介します。
リソース正常性アラートやサービス正常性アラートについては、別途ブログを投稿しておりますので併せてご覧いただけますと幸いです！


]]> Azure Monitor のアラートに関するよくあるご質問 2026-09-06T00:15:21.636Z