Azureアクテビティログ監視をAzure MonitorとLog Analyticsでやってみた

Azureプラットフォーム上でAzure VMを作成、起動、削除した等の作業が記録されるログとしてアクテビティログがあります。

    • Azure アクテビティログ

https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/activity-log

アクテビティログで収集される内容はマイクロソフト様のサイトに記載を参照して頂きたいのですが、アクテビティログについても診断設定を使ってLog Analyticsでのデータ収集が可能です。

Log Analyticsデータ収集が可能という事は、Azure Monitorでの監視も可能なんじゃないか?という事で試してみました。

今回は、サンプルとして15分間の間に1人のユーザーがAzure VMを2台作成した場合にアラートを上げるような設定を試してみました。

      • アクテビティログの診断設定
      • Log Analyticsワークスペースでアクテビティログの確認
      • Azure Monitorでの監視設定

Log Analyticsのワークスペース作成はこちらの記事に纏めております。

Log Analyticsワークスペースを複数まとめてデプロイ

1.アクテビティログをLog Analyticsへ転送する為に診断設定をする

アクテビティログを事前に準備したLog Analyticsワークスペースへ転送する設定を行います。Log Analyticsへの転送は診断設定で行います。

1)アクテビティログのメニューで診断設定を選択します。

2)診断設定の画面が表示されますので、診断設定を追加するを選択します。

3)診断設定画面が表示されます。Azure VM作成を収集するのであれば、以下の項目にチェックをします。(今回はお試しなのですべてにチェックをつけています。)

      • カテゴリの詳細:Administrative(Log)にチェック
      • 宛先の詳細:Log Analyiticsへの送信にチェック
      • Log Analytics ワークスペース:事前に準備したLog Analyticsワークスペースを指定

10分ほどすると、Log Analyticsでアクテビティログの確認ができるようになります。

2.Log Analyticsでアクテビティログを確認してみる

Log Analyticsのワークスペースでログの確認をしてみます。

1)Azure PortalのメニューでLog Analyticsを選択します。

2)Log Analyticsでログを選択すると下記画面が表示されますので、クエリ欄に下記の通り入力し、実行をクリックします。これですべてのアクテビティログが表示されます。

AzureActivity

アクテビティログが結果として表示される事が確認できました。

実際に、Azure VMを作成した際のログを確認すると、以下のログが出力される事が分かりました。

      • ActivitySubstatusValue :Created
      • OperationNameValue:MICROSOFT.COMPUTE/VIRTUALMACHINES/WRITE
      • Caller:作成者のアカウント

こちらの情報をもとにAzure Monitorでの監視設定を行ってみます。

3.Azure MonitorでLog Analyticsを使ったアクテビティログの監視設定をしてみる

まず、Log Analyticsの画面で実際のクエリを作成してみます。特定のアカウントで15分以内にAzure VMが2回以上作成された場合にアラートを発生させる設定としてみました。

    • Logの検索条件
      • ActivitySubstatusValue :Created
      • OperationNameValue:MICROSOFT.COMPUTE/VIRTUALMACHINES/WRITE
    • 検出条件 
      • Caller:同じアカウントの場合
      • 検索時間:15分
      • 回数:2回以上

上記条件を実際にクエリとして記載するとこんな感じになりました。

AzureActivity

| where ActivitySubstatusValue == “Created”
| where TimeGenerated > ago(15m)
| summarize countif(OperationNameValue == “MICROSOFT.COMPUTE/VIRTUALMACHINES/WRITE”) by Caller
| where countif_ > 1

この条件でAzure Monitorの設定を行います。今回はLog Analyticsの画面から設定を行ってみます。

1)Log Analyticsのクエリ画面に新しいアラートルールという設定がありますので、こちらをクリックします。

2)Azure Monitorのアラートルールの作成画面に遷移します。スコープはLog Analyticsワークスペース名が設定されていますので、条件を選択し設定を行います。

3)シグナル ロジックの構成画面が表示されますので、アラートロジックと評価基準の設定を行います。今回は15分単位での設定としています。

    • アラートロジック
      • 基準;結果の数
      • 演算子:次の値より大きい
      • しきい値:0
    • 評価基準
      • 期間:15
      • 頻度:15

注意点ですがしきい値は0より大きいになります。該当のクエリの結果が1行でも表示されていた場合にアラートとして検出するようにしています。

4)アクショングループの設定をクリックし、アクショングループを適時選択します。

アラート通知をSMSで行うような設定も行っております。興味がある方はぜひ一緒に見て下さい。

Azure Monitorのアラート通知をSMSで行ってみた

5)アラートルールの詳細でアラートルール名(必要に応じてその他項目)を設定し、完了したらアラートルールの作成をクリックします。

これでアラートルールの作成は終了です。

4.Azure VM作成をしてアクテビティログアラートを発生させてみた

実際にAzure VMを作成しアラート発生させてみました。

こんな感じでアラートを発生させる事が出来ました。

      • 件名:Alert Notification “VM-Create” raised for “Log Analyticsワークスペース名”
      • Name:VM-Create
      • Severity:3
      • Resource:Log Analyticsワークスペース名
      • Search interval start time:時刻
      • Search interval duration 15 min
      • Caller :作成者アカウント名
      • countif_ 2

今回はサンプルとして作成してみましたが、適切な情報が出力されるように改善を加えていきたい所です。

Azure Monitorのアクションルールを使って非監視設定(非通知)を試す

 

Azure Monitorにアクションルールという機能があります。

    • アクションルール(2020年7月19日現在はプレビュー)

https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/alerts-action-rules

詳細はマイクロソフト様のサイトに記載を参照して頂きたいのですが、アクションルールを使って特定のリソースに対してのアラート通知を抑制をすることが出来ます。

例えば、毎週金曜日の夜にVMを再起動するからその時間帯だけでアラート通知を止める、そんな非監視設定と同じような事がアラートルールを使えばできます。

今回は、アラートルール自体を無効にするような非監視ではなく、アクションルールの発動を抑える内容を試しています。フィルターでルールIDの指定も行えるのでアラートの発生自体の抑制も可能なのかは、今後試してみたい所です。

1.Azure Monitorでアクションルールの設定してみた

今回は、以下の設定で試してみました。

      • スコープ(対象):Azure VM
      • 対象のアラートルール:すべての重要度のアラートルール
      • アクション(スコープの定義):抑制
      • 時間:10分間(1回限り)

Azure Portalでモニターを選択し、Azure Monitorの設定画面に移動します。

アラートを選択すると下記画面が表示されますので、アクションの管理を選択します。

2)アクションルールのタブを選択します。

そうすると、アクションルールの設定画面が表示されます。

  • アクションルール固有の重要な設定項目
      • スコープ(アクションルールの対象。抑制の場合は抑制を行うサービスを指定)
      • フィルター(どういう条件に合致したものに適用するか?という設定(任意なのですべての場合は設定しない)
      • スコープでの定義(抑制するのか、アクショングループの定義にするのか?)
      • 抑制の構成(抑制を選択したい場合に表示されます。抑制を行う時間帯等を指定します。)

その他ルール名等のアクションルールに関する設定を行います。

3)スコープを選択します。今回はAzure VMに対しての抑制なので、Virtual Machinesを選択します。

4)フィルターの設定を行います。どういう条件の場合は抑制を行うのかの指定ができます。

Azure VMに対してすべて抑止を行う場合はフィルターの設定が必要ありません。今回は設定内容を確認したかったので重要度をすべて選択しています。

実際に重要度=すべての重要度で設定すると下記のようになります。

5)次にスコープの定義を設定します。今回はアラート通知を止めたいので抑制を選択します。

6)そうすると抑制の構成が表示されますので、編集ボタンをクリックして設定を進めます。

7)抑制の構成ですが、スケジュールした時刻や定期的なスケジュール設定が可能です。

スケジュールされた時刻の場合

定期的に抑制を行う場合

今回はテストなので下記の通り、10分間だけ抑止を行う設定にしてみました。

 

8)最後にアクションルール名や、保存するリソースグループを選択します。

9)最終的に確認画面が表示されますので、内容を確認して問題がなければ保存します。(サンプルは一度保存した後の画面になります。)

これで設定は完了です。

実際に作成されたアクションルールは、アクションの管理の画面で一覧表示して確認する事が出来ます。

設定内容に慣れる必要はありそうですが、設定自体は非常に簡単にできます。

2.Azure Monitorのアクションルールを実際に使ってみて

今回、Azure VMの再起動で試してみました、アクションルールの設定によりアラート通知は止められていました。

定期的にメンテナンスするような場合には非常に有効かと思われました。

スコープではアクショングループも選択が可能なようなので、夜だけは特定の通知(アクショングループ)を止めるような設定も可能なようです。

またフィルターで色々な条件設定も可能なので、今後引き続き試して行きたい所です。

Azure リソース正常性(Resource Health)の監視設定

 

今回はリソース正常性(Resource Health)の監視、アラート通知設定をAzure Monitorを使って試してみました。

リソース正常性(Resource Health)では、自身のリソースが使用可能な状況にあるのかどうかを知る事が出来ます。

Azure 基盤の障害だけではなく、ユーザー自身が行った操作による影響も知る事が出来ます。例としては、ユーザー自身が行ったAzure VMの停止もリソース正常性の1つとして通知されます。

リソース正常性(Resource Health)に関する詳細は下記サイトを参照ください。

    • リソース正常性(Resource Health)

https://docs.microsoft.com/ja-jp/azure/service-health/resource-health-overview

なお、Service Health(サービス正常性)に関しては、下記に記載しております。併せて見て頂ければと。。。

Azure サービス正常性(Service Health)の監視設定

—-

1.リソース正常性(Resource Health)をAzure Portalで確認してみた。

リソース正常性(Resource Health)は、サービス正常性(Service Health)の中にあります。

Azure Portalで確認するには、まずモニターのService Healthのメニューを選択します。

サービス正常性の画面が表示されますので、リソース正常性を選択します。次にリソースの種類を選択します。(下記例では仮想マシンを選択しています)。選択したリソースの種類に関するリソース正常性状況が表示されます。

詳細を確認したい場合は、リソースを選択します。正常性の状況や利用できない場合はその理由が表示されます。

Azure Portal上でも確認が可能ですが、リソース状態の変化を都度確認するのも大変です。これをAzure Monitorを使って通知する設定を行ってみました。

2.Azure Monitorでリソース正常性(Resource Health)の監視設定をしてみた

Azure Monitorを使ってリソース正常性の監視設定を行ってみました。

1)まずモニターでService Healthを選択します。

2)サービス正常性の画面が表示されますのでリソース正常性を選択します。

3)リソース正常性の画面が表示されますので、リソース正常性アラートの追加を選択します。

下記のようなResource Healthアラートルールの作成画面が表示されます。まずアラートの対象の設定を行います。

      • サブスクリプション
      • リソースの種類
      • リソースグループ
      • リソース

4)リソースの種類について設定します。リソースの種類は以下の通りAzureのサービスが個別に表示されます。設定対象のサービスを選択します。

Azure Resource Health で利用できるリソースの種類と正常性チェック

https://docs.microsoft.com/ja-jp/azure/service-health/resource-health-checks-resource-types

 

※サービス正常性に比べて利用できる対象はまだ少ない状況です。

5)次にリソースグループを選択します。設定したリソースが存在するリソースグループ名を選択します。

6)次に監視対象としたいリソースを選択します。リソースの種類とリソースグループで絞り込まれたリソースが表示されますので適時選択します。

次にアラートの条件を設定します。アラートの条件で設定するのは以下の通りになります。

      • イベントの状態
      • 現在のリソースの状態
      • 以前のリソースの状態
      • 理由の種類(何に起因して発生したのか)

7)イベントの状態を選択します。

8)現在のリソースの状態を選択します。状態は下記3つになります。

      • Available(使用可能)
      • Degraded(パフォーマンス低下(リソースは使用可能))
      • Unavailable(使用不可)

例えばサービス影響を受けた場合検出したい場合は、DegradedとUnavailableにチェックを入れます。

9)以前のリソースの状態を選択します。利用可能な状態から状態遷移した場合のみを検知したい場合等はAvailableに選択を入れます。

10)理由の種類を選択します。

      • Platform Initiated(Azure側起因)
      • User Initiated(User操作起因)

プラットフォーム起因の影響のみ検出したい場合は、Platform Initiatedを選択します。User Initiatedにはユーザー自身が意図的に行ったAzureVMの再起動等が含まれます。

11)アクショングループで通知方法を選択します。アクショングループの選択をクリックすると、作成したアクショングループが表示されますので、適時選択します。

12)アラートルールの詳細を設定します。アラートルール名やアラートルールを保存するリソースグループ名を指定します。

設定が終わったら、アラートルールの作成をクリックしルールを作成します。

これで設定作業が終了です。



3.リソース正常性(Resource Health)をAzure Monitorを使ってアラート通知してみた感じ

Azure VM等がAzure基盤影響でハングアップした場合等も通知出来る為、Azure Portalを確認しなくても済むため非常に便利だと思いました。

しばらく、様子を見ながら試したいと思いますが、少なくともプラットフォーム起因の部分は設定しておいたほうが良さそうな感じでした。

Azure サービス正常性(Service Health)の監視設定

 

Azure基盤の障害やメンテナンス作業影響で自身のリソースや、サービス全体の影響が発生した場合に検知する方法としてサービス正常性とリソース正常性2つの方法があります。

    • サービス正常性(Service Health)

https://docs.microsoft.com/ja-jp/azure/service-health/service-health-overview

リージョン単位で発生しているような大規模なサービスの障害や、メンテナンス計画等の情報を表示します。(リージョン内の特定リソースを対象にしたようなものは表示されません。)

    • リソース正常性(Resource Health)

https://docs.microsoft.com/ja-jp/azure/service-health/resource-health-overview

リソース単位で発生している障害や、利用可能な状態にあるかの情報を表します。

サービス正常性(Service Health)にはメンテナンス計画等が含まれたり、リソース正常性(Resource Health)はリソース自体をユーザーが停止した場合も含まれるなど、同じ正常性でも用途や範囲が異なります。

Azure Portal上でも正常性の確認も出来ますが、Azure Monitorを使った監視、アラート通知する事が可能です。

今回はAzure Monitorでサービス正常性(Service Health)の アラート ルールを作成してみました。

なお、リソース正常性に関しては、下記に記載しております。併せて見て頂ければと。。。

Azure リソース正常性(Resource Health)の監視設定

1.Azure Service Health(サービス正常性)をAzure Portalで確認してみた。

Azure Portalで確認するには、モニター(Azure Monitor)のService Healthを選択します。

現在のサービス正常性が表示されます。(なお、本画面では過去の履歴を含めてサービスに関する問題も確認可能です。)

なお、デフォルトすべてのサービスが選択されているので、自身の利用していないサービスの問題も表示されます。(サンプルは何も発生していない場合の画面になります。)

2.Azure MonitorでService Health(サービス正常性)のアラート通知設定してみた

Azure Monitorを使ってService Health(サービス正常性)の監視設定を行ってみます。

1)まずモニターでService Healthを選択します。

2)サービス正常性の画面が表示されます。サービス正常性アラート追加を選択します。

3)下記のようなアラートルールの作成画面が表示されます。サービス正常性(Service Health)で設定する内容は下記の通りになります。

      • サービス(通知対象のAzureサービス)
      • リージョン(通知対象のリージョン)
      • イベントの種類
      • アクショングループ(アラートの通知方法)
      • アラートルールの詳細(ルール名や保存するリソースグループ名等)

4)サービスについて設定します。サービスは以下の通りAzureのサービスが個別に表示されます。自身が利用するサービスのみを選択します。

※かなりの数がありどれを指定すればよいのかわかりにくいものも多いです。ある程度広めに設定しておき、どんどん削っていくのが良さそうな感じです。

5)次にリージョンを選択します。Azureで展開されるているリージョンがすべて表示されます。アラート通知したい(利用しているリージョン)を選択します。

6)次にアラート通知を行う、イベントの種類を選択します。

イベントの種類については下記サイトに記載があります。適時選択します。

https://docs.microsoft.com/ja-jp/azure/service-health/service-health-overview#service-health-events

  1. サービスの問題 – ユーザーに今すぐ影響を及ぼす Azure サービスの問題。
  2. 定期的なメンテナンス – お使いのサービスの可用性に将来影響を及ぼす可能性のある今後のメンテナンス。
  3. 正常性に関する勧告 – ユーザーが注目する必要のある Azure サービスの変化。 例としては、Azure の機能が非推奨となることやアップグレードの要件 (サポートされている PHP フレームワークへのアップグレードなど) が挙げられます。
  4. セキュリティに関する勧告 (プレビュー) – Azure サービスの可用性に影響する可能性があるセキュリティ関連の通知。

※サービスの問題と計画メンテナンスと正常性の勧告&セキュリティ アドバイザリと3つそれぞれ別々にサービス正常性アラートを作るのが、受け取った時に一番わかりやすいかなぁと思います。

7)アクショングループで通知方法を選択します。アクショングループの選択をクリックすると、作成したアクショングループが表示されますので、適時選択します。

8)アラートルールの詳細を設定します。アラートルール名やアラートルールを保存するリソースグループ名を指定します。

設定が終わったら、アラートルールの作成をクリックしルールを作成します。

これで設定作業が終了です。

3.Azure サービス正常性(Service Health)を使ってみて

メンテナンス通知等がメールで来るので、こういうところは非常に便利だと思いました。

実際の障害時にがサービス正常性が来るのが、実際のサービスが影響発生してしばらくしてから来るので、この編は参考情報程度に近いかと思います。

幅広く設定すると色んなメールが来るので、内容確認に慣れていく必要があるなぁという感じです。




Azure Monitorのアラート通知をSMSで行ってみた

 

Azure Monitor のアラート通知をSMSでやってみました。

Azure Monitor でアラート通知を行う際には、どういう方法で通知を行うかをアクショングループで定義をします。

https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/action-groups

この通知方法に関しては、メールだけではなく、SMSを選択する事も可能です。

今回は、SMSを利用したアラート通知の設定を作成し、アラートを出して実際に受信する所までを試してみました。

実施した作業の流れは、以下の通りになります。

1) Azure Monitorで通知方法にSMSを指定したアクショングループを作成する。

2)1)で作成したアクショングループを指定して、Azure Monitorのアラートルールを作成する。

※なお、電話は米国(国番号1)のみで提供されています。(2020年7月5日現在)

1.Azure Monitorで通知方法にSMSを指定したアクショングループを作成

Azure Portalを利用して作業を実施します。

1)Azure Portalのメニューでモニターを選択します。以下の画面が表示されますので、アクションの管理を選択します。

2)以下の画面が表示されますので、アクショングループを追加を選択します。

3)アクショングループの作成の画面が表示されます。基本設定として、リソースグループ名、アクショングループ名、表示名を入力します。

4)アクショングループの通知の設定を行います。通知の種類でSMSメッセージを選択します。

5)SMSの登録を行います。国コード(日本の場合81)を選択し、通知を行う電話番号を入力します。登録が終わったらOKで保存をします。

6)アクショングループの設定を行います。今回はSMSの通知のみですので、何もせずに次へで進みます。

7)タグの設定を行います。環境に合わせて適時入力します。投入が終わったら次へ進みます。

確認をおよび作成画面が表示されますので、作成をクリックします。これでSMSの通知を行うアクショングループの作成作業は完了です。

正しく設定出来ていると、下記のようなSMS通知が届きます。(AlertSMS01という名前でアクショングループの表示名を作成した場合の例になります。)

2.Azure MonitorでAzure VMに起動時に発動するアラートルールを作成

次にSMSの通知確認を行う為に、Azure Monitorのアラートルールを作成します。今回は、Azure VM起動時にアラート通知を行うように設定を行います。

1)Azure Portalのメニューでモニターを選択します。以下の画面が表示されますので、新しアラートルールを選択します。

2)アラートルールの作成を行います。最初に監視対象のリソースを選択します。下記画面が表示されますので、リソースの選択をクリックします。

3)リソースの選択画面が表示されます。今回はリソースの種類でフィルターでVirtual Machineを選択します。

4)監視対象のリソースを選択します。監視対象のVMを選択しOKをクリックします。

5)監視条件を設定します。条件の選択をクリックします。

6)シグナルロジックの構成(監視条件の設定)を行います。今回は仮想マシンの起動を選択します。(3ページ目に表示されます。)

7)監視アラートの通知方法を設定します。このアラートルールにアタッチするアクショングループを選択するという項目がありますので、先ほど作成したSMSメッセージのアクショングループを選択します。

8)アラートルールの詳細を設定します。今回はアラートルール名をVM Startで作成します。

アラートルールの作成を行えば、Azure Monitorの設定は完了です。

3.実際にAzure MonitorでSMS通知してみる

実際にAzure VMを起動して試してみました。以下のようにどのVMが起動したかがSMSで通知されます。通知速度的にはメール通知と同時という形でした。

※AlertSMS01はアクショングループの表示名、VM Startはアラートルール名になります。

4.SMS通知の場合の注意点

マイクロソフト様のサイトに記載の通り、SMS通知には5分に1度しか通知出来ない(同じ通知先)というレート制限があります。

https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/alerts-rate-limiting

このレート制限はアクショングループ単位ではなく、サブスクリプション単位になる為、複数のアラートが発生した場合には、一番最初のアラートだけがSMS通知され、それ以降のアラートが通知されない可能性があります。実際の利用にあたっては注意が必要かと思われます。

Azure Web Appsのリソース監視を設定してみた

 

Azure Web Appsのリソース(CPU使用率やメモリ使用率)を見ようと確認してみた所、Azure Web Appsのメトリックにはありませんでした。

何故?という事で調べてみた結果、マイクロソフト様のサイトに答えがありました。

https://docs.microsoft.com/ja-jp/azure/app-service/web-sites-monitor

サイトの記載を見ると、CPU使用率等のリソースについては、App Service プランのメトリックにあると記載がありました。

今回は、CPU使用率等のAzure Web Appsリソースを見てみる事から、監視設定まで実際に触って確認してみました。

1 .Azure Web AppsのメトリックにはCPU使用率がありません

最初にAzure PortalでAzure Web Appsのメトリックを見てみました。

それらしい、CPU Timeはありますが、CPU使用率のようなものはありません。

という事で、Azure App Service プランを見てみます。

2 .Azure App Service プランのメトリックにWeb Appsのリソースはあります

Azure PortalでApp Service プランのメトリックを見てみました。

ちゃんと、CPU使用率やメモリ使用率がありました。

Azure Web Appsのリソースを指定しているのはApp Serviceプランになります。

リソースについてはリソース指定しているもので見るのが正解!!

という事でCPU使用率などのメトリックもApp Serviceプランにあるという事に気づきました。(当たり前な話なんでしょうけど。。。)

.Azure Web Appsのリソース拡張もApp Serviceプランで設定

Azure Web Appsですが料金プランによっては、自動リソース拡張が設定できます。

ではこの設定自体はどこにあるというと、こちらも、App Serviceプランの設定になります。

Web Appsのスケールアウトの設定にありますが、実際はApp Serviceプランの設定となっています。(App Serviceプラン側のメニューでも全く同じ事ができます)

.Azure Web Appsのリソース監視(App Serviceプランのリソース監視)

最後に、Azure Web Appsのリソース監視を確認してみます。これはApp Service プランのリソース監視を行う事になります。実際に見てみます。

 1)モニターのアラートを選択すると下記画面が表示されますので、新しいアラートルールを選択します。

 

 2)リソースの選択をします。

 

 3)リソースの種類でフィルターでプルダウンを選択すると、App Serviceプランがありますのでこちらを選択します。

 

 4)Web Appsに紐づいているApp Serviceプラン名を指定します。

 

 5)監視の条件を選択します。

 

 6)シグナルロジックの選択をします。今回はCPU使用率ですので、CPU Percentageを選択します。

 

7)シグナルロジックの構成が表示されますので設定を行います。設定が終わったら完了をクリックします。

 例えば80%より大きい場合はアラートといった場合は、アラートロジックは下記の通りのようにします。

        • しきい値:Static
        • 演算子:次の値より大きい
        • 集計の種類:平均
      • しきい値:80

 

8)アクショングループの設定で通知方法の設定を行います。

9)アラートルールの設定でアラートルール名の設定等を行います。

これですべての設定が終了ですので、アラートルールの作成をクリックします。

アラートルールが作成され、しばらくすると監視が開始されます。

Azure Front Doorのバックエンド正常性監視

 

Azure Front Doorのバックエンド状態(正常に応答しているかどうか)の確認をしてみました。

また、Azure  Monitorの機能を利用してバックエンドの状態が異常な場合に検知するようにしてみました。Azure Monitorを使ってますのでメール送信等を行う事も標準機能で出来ます。

Application Gatewayの正常性プローブの監視についてはこちらに記載しております。

Azure MonitorでApplication Gateway正常性プローブを監視

1.Azure Front Doorのメトリックで正常性プローブの応答率がわかる

マイクロソフト様のサイトを確認するとAzure Front Doorのメトリックで、バックエンドへの正常性プローブの応答率がわかるようです。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-diagnostics

※マイクロソフト様のサイトでは、バックエンドの正常性の割合と記載されています。

実際にAzure Portal上で確認してみました。

メニューのメトリックを選択すると、下記画面が表示されます。ここでBackend Health Percentageを選択するとバックエンドプール全体での応答率(正常な割合)が表示されます。

応答率になるので、バックエンドプールに所属するバックエンドがすべて正常な場合は100%になります。

※バックエンド落としてないにも関わらず、なぜか100%になってなかったりするので、この編は調査が必要かも。という感じです。

バックエンドホスト単位で確認するには、フィルターの追加を使います。

フィルターの追加を選択すると、BackendとBackend Poolが表示されますので、Backendを選択します。そうすると、値の部分に設定しているバックエンドホスト名が表示されます。確認したいバックエンドのホスト名を選択します。

選択するとバックエンドホスト単位での応答率が確認できました。

ここの数値が低い場合は、バックエンドホストがAzure Front Doorの正常性プローブに応答を返せてないという状態になります。

2.Azure Front Doorのバックエンドが正常かAzure Monitorで監視する

Azure MonitorでAzure Front DoorのBackend Health Percentageをメトリック監視する事が出来ます。

まず、Azure Front Doorのメニューで、警告を選択します。表示された画面で新しいアラートルールを選択します。

そうすると、アラートルールの作成画面が表示されます。

スコープはすでにFrontDoorが選択されています。(Azure Monitorから設定を行った場合はスコープで今回設定するFront Doorを選択します。)

条件を選択します。

   シグナルロジックの構成画面が表示されますので、Backend Health Percentageを選択します。

そうするとシグナルロジックの構成画面が表示されます。ここで実際の設定を行います。

      • ディメンション:バックエンドホスト、バックエンドプールすべて監視する
      • アラートロジック:しきい値(平均)が95%より小さい場合はアラートを発生させる
      • 評価基準:15分単位での確認とする

上記のような設定の場合は、下記のような画面になります。

バックエンドホスト単位、バックエンドプール全体の状態どれを監視するかを選択します。

個別に設定可否を判断する場合は、ディメンションで対象を選択します。すべてを選択する場合は、選択にチェックを入れるとすべての項目が選択されます。

※注意点ですが、選択にチェックを入れるとAzure Front Door側でバックエンドやバックエンドホストを追加すると自動的に監視項目にも追加になります。

何%以下(より小さい)というしきい値を設定すると、バックエンドホスト側へのアクセスに問題がある場合、Azure Monitorで検知ができます。

上記設定が終わったら、完了をクリックします。

アクショングループや、名前等を付けて保存すれば、Azure Monitorでの監視設定が完了になります。

3.Azure Monitorで実際に送信されたメール

実際にアラートメールを送信すると、以下のような内容が記載されたメールが送信されます。

Metric name BackendHealthPercentage
Metric namespace frontdoors/フロントドア名
Dimensions ResourceId = /subscriptions/サブスクリプションID/resourcegroups/リソースグループ名/providers/Microsoft.Network/frontdoors/フロントドア名

ApplicationEndpoint = バックエンドホスト名(1)

ApplicationEndpointPool = バックエンドホスト名(2)

Time Aggregation Average
Period Over the last 15 mins
Operator LessThan
Threshold 95
Criterion Type StaticThresholdCriterion

Azure MonitorでApplication Gateway正常性プローブを監視

 

Application GatewayはL7のレイヤーでWEBアクセスを負荷分散してくれるAzure上のロードバランサーになります。

Application Gatewayの負荷分散先(バックエンド)にある、WEBサーバ(HTTP(S))が正常に応答していないと、WEBサイトがエラーになる等の事象になってしまいます。

その為、WEBサイトに障害が発生していた場合の切り分けの1つとして、Application GatewayからWEBサーバへの通信状況(正常性プローブ)の状態を監視する事は非常に重要になってきます。

今回は、Azure  Monitorの機能を利用してApplication Gatewayの正常性プローブのステータスの変化を検知するようにしてみました。

Application Gatewayの構築についてはこちらに記載しております。

Azure Application Gatewayを構築してみた

1.Application Gatewayのメトリックで正常なホストの数、異常なホストの数がわかる

Application Gatewayの正常性プローブの変化は、正常なホストの数、異常なホストの数の変化で分かります。

Application Gatewayのメトリックでは、この正常なホストの数、異常なホストの数を検知する事ができます。これはV1、V2どちらでも可能です。
このホストの数は、正常性プローブによって正常もしくは異常と判断されたバックエンドの数になります。

正常性プローブ自体は、バックエンドにあるWEBサーバへHTTP(S)のヘルスチェックで確認されます。

マイクロソフト様のサイトに記載があります。

https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-metrics#backend-metrics

マイクロソフト様のサイトを読むと、以下のような事が言えます。

      • 正常なホストの数が0の場合は、すべてのバックエンドプールに問題が発生しており、サイトが表示されない状態
      • 異常なホストの数が1以上の場合は、1つ以上のバックエンドプールで異常が発生している状態(特定のバックエンドにあるホストが停止している状態

したがって、正常なホストの数や異常なホストの数状態を監視することにより、Application Gatewayのバックエンド正常性状態がわかります。

2.Application GatewayでWEBサーバへのヘルスチェック状況をAzure Monitorで検知する(正常なホストの数が0になった場合)

Azure MonitorでApplication Gatewayのメトリックを監視することができます。

まず、モニター>アラート>新しいアラートルールを選択します。

そうすると、下記画面が表示されますので、リソースの選択でアプリケーションゲートウェイを選択します。

    選択が終わったら、完了を押します。

ルールの作成画面に戻りますので、次に条件の項目で追加を選択してください。

そうすると、下記のようにシグナルロジックの構成が表示されます。

ここに項目が表示されるのですが、今回対象とする項目は下記2つになります。

    • Unhealthy Host Count が異常なホストの数になります
    • Healthy Host Count が正常なホストの数になります

すべて正常性プローブがNGになった場合の検出は正常なホストの数で設定をします。

Healthy Host Countを選択をすると下記のような画面が表示されます。バックエンドのサーバが1つ(ルールもHTTP用1つ)で検証していますので、以下のように1となります。

これが、0になると、正常なバックエンドがなくなる為、すべてのアクセスが停止する状態になります。ですので以下のような設定とします。

    • しきい値:Static
    • 演算子:より小さい
    • 集計の種類:平均
    • しきい値(演算子の方):1

1より小さいとなりますので、バックエンドにあるWEBサイトからのヘルスチェックがすべてNGだった場合(一時的な状態を含む)が検出される事になります。

評価基準は適時選択してください。最後に完了ボタンを選択します。

ルールの作成画面に戻りますので、アクショングループの選択、アラートの詳細を適時記入し、アラートルールの作成をクリックします。

これで、Azure MonitorでApplication Gatewayのバックエンド正常性がすべてNGになった場合に、アラートを発生させることができます。

3.Application GatewayのバックエンドのWEBサーバに異常があった場合に検知する

Application GatewayのバックエンドにいるWEBサーバに異常があった場合(ヘルスチェックがNG)になった場合の検出は異常なホスト数で行います。

シグナルロジックの構成で、Unhealthy Host Countを選択します。

そうすると、下記画面が表示されます。

すべてのバックエンド正常性がOKなので、0になります。

これが0より大きい場合は、バックエンド正常性に問題が発生している事を示します。ですので、下記のように設定にします。

    • しきい値:Static
    • 演算子:より大きい
    • 集計の種類:平均
    • しきい値(演算子):0

評価基準は適時選択し完了ボタンを選択します。

ルールの作成画面に戻りますので、同様に、アクショングループの選択、アラートの詳細を適時記入し、アラートルールの作成をクリックします。

Application GatewayのバックエンドにあるWebサーバが1つでもNGになっている場合に、Azure Monitorを使ってアラートを発生させることができます。

Azure Front Doorのバックエンド正常性監視については、こちらで試しております。

Azure Front Doorのバックエンド正常性監視

 

Azure VM Bシリーズ CPUクレジットの確認と監視

 

Azure VMのシリーズの1つに、Bシリーズがあります。

Bシリーズは普段使わないCPUの使用量を貯めておいて、負荷が高くなった時にその貯めたCPU使用量を使うシリーズです。

Dシリーズと比較して2分の1位の使用料金で使える為、普段からCPUを使わないようなサーバに向いているシリーズになります。

Azure VM Bシリーズの詳細は下記マイクロソフト様のサイトに記載があります。

https://azure.microsoft.com/ja-jp/pricing/details/virtual-machines/series/

https://docs.microsoft.com/ja-jp/azure/virtual-machines/sizes-b-series-burstable

ただ、このAzure VMのBシリーズですが、CPUの使用量が使い果たされている為性能が発揮されないという可能性もあります。

今回はCPUクレジット残量確認方法を試し、Azure Monitorの設定項目確認までを行ってみました。

1 .Azure VM BシリーズのCPUクレジット残(CPU Credits Remaining)をAzure Portal上で確認する

Azure Portal上のメトリックで確認ができます。

仮想マシンのメニューの監視にあるメトリックという項目を選択します。

このメトリックを選択すると、下記のように項目を選ぶとグラフが表示されます。この項目でCPU Credits Remainingを選択すると過去のクレジット残の履歴確認ができます。

CPU使用率が高く使い果たしているような状況だと0になります。

なお、CPU Credits Consumedを使う事により、CPUクレジットがどれだけ溜まっているのか確認できます。

.BシリーズのCPUクレジット残(CPU Credits Remaining)をPower Shellで確認する

Power ShellでもCPU Credits Remainingが確認できます。今回は直近の値を確認しています。

サブスクリプションIDやリソースグループ名は環境に合わせて設定します。Power Shell実行時に取得対象のVM名を指定します。

Get-Dateで取得した日付フォーマットそのままだとエラーになるので、フォーマットを変更しています。

StartTime等を変更することにより、過去の値も取得可能です。

#CPU Credits Remaining

param (
    [String] [Parameter(Mandatory=$true)]  $VMname
    )

$subscriptionID =“サブスクリプションID”
$RGName = “リソースグループ名”

$startTime = (Get-Date).AddMinutes(-3) | Get-Date  -Format ‘yyyy-MM-dd THH:mm’
$endTime = Get-Date -Format “yyyy-MM-dd THH:mm”
 
# 注意-ResourceIdの行は折り返していますが、実際には1行です。GitHubの方を参考にして下さい
# https://github.com/Tama-negi/Li-akb-branch-office/tree/PowerShell_Azure/Azure_PowerShell

(Get-AzMetric `
    -ResourceId “/subscriptions/$subscriptionID/resourceGroups/$RGName/providers/Microsoft.Compute/virtualMachines/$VMname” `
    -TimeGrain 00:01:00 `
    -AggregationType “Average” `
    -StartTime $startTime `
    -EndTime $endTime `
    -MetricName “CPU Credits Remaining” `
    -DetailedOutput).Data `
| Select-Object TimeStamp,Average
 

実行すると以下のように結果が得られます。

TimeStamp Average

——— ——-

2020/04/16 10:20:00 316.12
2020/04/16 10:21:00 316.12
2020/04/16 10:22:00 316.12
 

※MetricNameの値を、CPU Credits Consumedに変更することにより、1分間にどれだけクレジットがたまっているかの確認が可能です。

.Azure MonitorでAzure VM Bシリーズの残CPUクレジット(CPU Credits Remaining)を監視

Azure MonitorのVirtual Machineメトリック監視にCPU Credits Remainingの項目があります。

スコープにAzure VMを指定します。

条件の選択でCPU Credits Remainingを選択するとシグナルロジックの構成が表示されます。

下記画面のように残量が次の値より小さいと指定すると、CPU Credits Remainingが少なくなった場合にアラートを上げる事も可能です。 

このアラートが頻発するようだと、CPUのリソースを使っているという事になるので、Dシリーズを選択した方が良いと思われます。

Azure MonitorのアクショングループをARMテンプレートを使ってデプロイ

 

Azure Monitorでアラートが発生した場合に、どのように通知を行うのかを定義する機能として、アクショングループがあります。

アクショングループにはメールやSMS、Webhookなどがあります。

今回はアクショングループの作成をAzure PortalとARMテンプレートを利用してメール送信のアクショングループを作成してみました。

ARMテンプレートはマイクロソフト様のサイトを参考に作成しています。

https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/action-groups-create-resource-manager-template

今回作成した内容はGithubにも公開しています。

アクションルールについては、Azure Portalを使った設定を試しております。こちらは下記記事に纏めております。

Azure Monitorのアクションルールを使って非監視設定(非通知)を試す

.Azure Monitorのアクショングループで設定する内容

Azure Monitorのメニューでアラートを選択します。

アクションの管理が表示されるので選択し、表示されるアクショングループの追加をクリックすると、下記画面が表示されます。

画面を確認した結果、アクショングループ作成時に指定が必要になる内容が分かりました。

      • アクショングループ名
      • 短い名前
      • サブスクリプション(デプロイ時に指定します)
      • リソースグループ(デプロイ時に指定します)
      • 操作名
      • アクションの種類(今回は電子メールを想定します。)
      • 電子メールアドレス(アクションの種類で電子メールを選択すると入力できます)

.アクショングループのARMテンプレートを作成する

電子メールを送信するアクショングループのテンプレートは下記のようになります。

ARMテンプレート内のvariables 関数で以下の内容を変数を指定するようにしてます。

      • アクショングループ名
      • 短い名前
      • 操作名 
      • 電子メールアドレス(アクションの種類で電子メールを選択すると入力できます)

電子メールに関するアクションの指定は、テンプレート内のemailReceivers項目を利用する事で定義されます。

{
 ”$schema”: “https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
 ”contentVersion”: “1.0.0.0”,
 ”variables”: {
   “actionGroupName”: “アクショングループ名”,
   “actionGroupShortName”: “短い名前”,
   “OperationName”: “操作名”,
   “emailAddress”: “送信先の電子メールアドレス”
    },

  },
  ”resources”: [
  {
   ”type”: “Microsoft.Insights/actionGroups”,
   ”apiVersion”: “2018-03-01”,
   ”name”: “[variables(‘actionGroupName’)]”,
   ”location”: “Global”,
   ”properties”: {
    ”groupShortName”: “[variables(‘actionGroupShortName’)]”,
    ”enabled”: true,
    ”emailReceivers”: [
     {
     ”name”: “[variables(‘OperationName’)]”,
     ”emailAddress”: “[variables(‘emailAddress’)]”
     }
    ]
   }
  }
 ],
 ”outputs”:{
  ”actionGroupId”:{
  ”type”:”string”,
  ”value”:”[resourceId(‘Microsoft.Insights/actionGroups’,variables(‘actionGroupName’))]”
  }
 }
}

.Power ShellでARMテンプレートをデプロイする

最後に、作成したARMテンプレートをPower Shellでデプロイします。デプロイ方法は下記を参考にしています。Power Shell実行時に、Action Groupを作成するリソースグループ名を指定します。

https://docs.microsoft.com/ja-jp/azure/azure-resource-manager/templates/deploy-powershell#deploy-local-template

#テンプレートをデプロイするPowerShell
$resourceGroupName = Read-Host -Prompt “Enter the Resource Group name”
$TemplateFilePath = “テンプレートファイルのパス(ex;”C:\tmp\ActionGroup_templete.json”)”

New-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName `
-TemplateFile $TemplateFilePath
 

最後に以下のPower Shellで実際にAction Groupができているか確認します。

$resourceGroupName = “リソースグループ名”
$actionGroupName = “アクショングループ名”

Get-AzActionGroup -ResourceGroupName $resourceGroupName -Name $actionGroupName

Azure Monitorのアラート設定に集約という項目が追加されてました

 

Azure Monitorのアラート設定で、LogAnalyticsワークスペース-Custom log searchにを指定した際に集約という項目が追加されてました。

https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/alerts-unified-log#metric-measurement-alert-rules

詳細は上記サイトに記載の通りですが、これを具体的に言うと、LogAnalyticsワークスペース単位でアラート設定を行う場合に正しく集計されないケースがあるという事になります。

1つの例として、以下のような継続して閾値を超えた場合の設定を行うには、Custom log searchを利用し、かつクエリとして仮想マシン単位で指定が必要でした。

監視対象:仮想マシン
監視内容;メモリ監視
閾値;% Used Memoryが80%以上
間隔;5分間
継続回数;3回

集約という項目を使う事により、仮想マシン単位ではなく、LogAnalyticsのワークスペース単位での設定可能になりました。

※Metricを利用してのリソース監視では仮想マシン単位での監視が可能ですが、連続して3回発生した場合等、継続を条件としたような設定ができません。その為、Custom log searchでの設定が必要になります。

1 .Azure Monitorに設定するクエリ(Custom log searchを使う場合)

下記のLogAnalyticsクエリで、ワークスペースに接続された仮想マシンの% Used Memoryを仮想マシン単位で取得可能です。 しかし、このクエリをAzure Monitorのクエリとして設定しても、ワークスペースに接続された仮想マシンの平均値で認識されるため、正しくアラート検知されませんでした。(平均値として認識されるのはAzure Monitorの仕様だそうです。)

#LogAnalyticsクエリ(メモリ使用率取得)
Perf
| where ( ObjectName == ‘Memory’ )
| where ( CounterName == ‘% Used Memory’ )
| summarize AggregatedValue=avg(CounterValue) by bin(TimeGenerated, 5m), Computer

Azure Monitorに設定するクエリとしては、下記のように、仮想マシンを明示的に指定する必要がありました。

#LogAnalyticsクエリ(メモリ使用率取得)
Perf
| where ( Computer == ‘VM名‘ )`
| where ( ObjectName == ‘Memory’ )
| where ( CounterName == ‘% Used Memory’ )

| summarize AggregatedValue=avg(CounterValue) by bin(TimeGenerated, 5m)

※リソースを収集するためには、事前にLogAnalytics側の設定で、パフォーマンスカウンターの取得設定が必要です。

.集約を利用する。

集約を使う事により、以下のクエリをAzure Monitorでも正しくクエリを認識させる事ができます。

#LogAnalyticsクエリ(メモリ使用率取得)
Perf
| where ( ObjectName == ‘Memory’ )
| where ( CounterName == ‘% Used Memory’ )
| summarize AggregatedValue=avg(CounterValue) by bin(TimeGenerated, 5m), Computer

集約に表示されるのはクエリ内でbyで設定された項目になります。実際の設定は下記画面の通りになります。
今回の場合、集約という項目にComputerが表示されますので、これを選択します。

Computerを指定することにより、以下のクエリでもLogAnalyticsワークスペースに接続された仮想マシンのリソースをAzure Monitor上でも期待した動作をしてくれます。

.集約を使う事のメリット。

ワークスペース単位での指定になるため、仮想マシンがワークスペースに接続された段階でAzure Monitorの設定変更する事なく、監視が開始できます。
また1つのアラートルールで済むため、コスト削減のメリットもあります。
非常に、細かい部分での機能になりますが、メリットは十分にあるかと思います。

Azure VMからLog Analyticsへのログ転送状況監視をしてみた(Metric)

 

前回に引き続き、Azure Virtual MachineからLog Analyticsへのログ転送状況監視をAzure Monitorを使って実施してみました。

Azure MonitorでLog AnalyticsのメトリックHeartBeatという項目があります。これを利用して監視することで、Azure VMからLog Analyticsへ正常にログ転送が行えているか監視出来ます。

なお、Azure VMからLog Analyticsへの転送はAzure VMにインストールされたOMSエージェントで実施されます。この監視でエラーが発生した場合はOMSエージェントの再起動等が必要になります。

また、メトリック(Metric)を利用した方式だけではなく、Custom log searchで実施する方法もあります。下記記事も併せて参照頂ければと。

Azure VMからLog Analyticsへのログ転送状況監視をしてみた(Custom log search)

1.Azure Monitorを利用したOMSエージェントHeartBeat監視

Azure Monitorの機能を利用して実施します。

1) Azure Portal上でモニターのメニューにアクセスします。アラートで[+ 新しいアラート ルール] をクリックします。

2)アラートルールの作成でリソースの選択をクリックします。

3)リソースの選択で VMが接続されているLog Analyticsのワークスペースを選択します。選択したら完了をクリックします。

4)次に監視条件の設定を行います。条件の選択をクリックします。

5)シグナルロジックの構成画面が表示されます。シグナル名でHeartbeatを選択します。

6)シグナルロジックの構成画面が表示されます。下記画面の通り選択します。

    • ディメンション名:Computer
    • 演算子:= 
    • ディメンション値:現在および将来のすべての値。

*現在および将来のすべての値を選択する事で、ワークスペースに新規VMが接続された場合も監視が自動的に有効になります。

 “アラート ロジック” にて以下を設定します。

    • しきい値 : Static
    • 演算子 : 次の値より小さい
    • 集計の種類 : 合計
    • しきい値 : 1

これで、過去5分間に1度もHeartBeatが来てない場合にエラーとして検知が可能になります。

“評価基準” にて以下を設定します。

    • 集約粒度 (期間) : 5 分
    • 評価の頻度 : 5 分

7)アクショングループにて電子メールの送信を行うアクションを設定します。

なお、アクショングループの作成についていは、こちらの記事を参照頂ければと。

ARMテンプレートを使ってAzure Monitorのアクショングループをデプロイしてみた

8)アラート ルール名や重要度をを入力します。入力が終わったら作成をクリックします。

これでアラートルールの作成は完了です。

2.OMSエージェントHeartBeatエラー時のアラートメール

Azure VM側でOMSエージェントを停止し、5分経過すると以下のメールが来ます。

どのVMのOMSエージェントが停止したかは、Dimensionsに記載されます。

Suject:Azure: Activated Severity: 3  ”アラート名”

Dimensions ResourceId = /subscriptions/XXXXXXXXXXXXX/resourceGroups/RG名/providers/Microsoft.OperationalInsights/workspaces/ワークスペース名-01Computer = ”VM名”

3.MetricとCustom log searchで設定した場合の違い

主な違いは以下のような感じになります。Log AnalyticsのHeartBeat監視の場合は、Metricを使った方が良さそうな感じです。

・メール送信タイミングが異なる

 Custom log searchを使用した場合は、回復するまでメールが送信され続けます。

 Metricを使用した場合は、発生時と回復時にのみメールが送信されます。

・コストは、Metricで設定した場合の方が安い。

※実際の環境に合わせて、設定はチューニングするようにして下さい。

Azure VMからLog Analyticsへのログ転送状況監視をしてみた(Custom log search)

 

Azure Virtual MachineからLog Analyticsへのログ転送は、Virtual MachineにインストールされたOMSエージェントで実施されます。その為、OMSエージェントが停止していた場合は、Virtual Machineが動作していてもログ転送が行われません。

今回は、Azure Virtual MachineからLog Analyticsへのログ転送状況監視をAzure Monitorを使って実施してみました。

OMSエージェントは死活監視のために、1分おきにLog AnalyticsへHeartBeatを送信します。このHeartBeatが取得出来ているかを監視することで、Virtual MachineからLog Analyticsへログ転送が行われているのか監視出来ます。

最終のHeartBeat取得時間が一定時間以上前の場合にアラートを上げる確認する事で監視を行います。

Azure MonitorのCustom log searchを使う方法と、メトリックを使う方法がありますが、今回はCustom log searchを使う方法で実施します。

メトリックを利用する方法も併せて参照頂ければ幸いです。

Azure VMからLog Analyticsへのログ転送状況監視をしてみた(Metric)

1.OMSエージェントのHeartBeat時刻取得

最後にOMSエージェントからHeartBeatアクセスがあった時刻は、Log Analytics上で以下のクエリを実行すると確認できます。(下記サンプルはAzure VM指定での出力になります。)

Heartbeat | where Computer==“VM名” | summarize max(TimeGenerated) 

実際に取得される値

2019-08-21T11:23:06.600

この取得時刻を利用して、Azure Monitorの設定を行います。

2.Azure MonitorでのOMSエージェントHeartBeat最終取得時刻で監視を設定する

今回は、HeartBeatの最終取得時刻が5分以上前にAzure Monitorからアラート発出するように設定します。

1) Azure Portal上でモニターのメニューにアクセスします。アラートで[+ 新しいアラート ルール] をクリックします。

2)アラートルールの作成でリソースの選択をクリックします。

3)リソースの選択で VMが接続されているLog Analyticsのワークスペースを選択します。選択したら完了をクリックします。

4)次に監視条件の設定を行います。条件の選択をクリックします。

5)シグナルロジックの構成画面が表示されます。シグナル名でCustom log searchを選択します。

6)シグナルロジックの構成の画面で以下の通り設定ます。”検索クエリ”に以下の内容を設定します。

検索クエリには以下の内容を設定します。

Heartbeat
| summarize LastCall = max(TimeGenerated) by Computer
| where LastCall < ago(5m)

”アラート ロジック”には以下を設定します。
 しきい値 : Static
 演算子 : 次の値より大きい
 集計の種類 : 結果の数
 しきい値 : 0

“評価基準” にて以下を設定します。
 集約粒度 (期間) : 5 分
 評価の頻度 : 5 分

7)アクショングループにて電子メールの送信を行うアクションを設定します。

なお、アクショングループの作成についていは、こちらの記事を参照頂ければと。

ARMテンプレートを使ってAzure Monitorのアクショングループをデプロイしてみた

8)アラート ルール名や重要度をを入力します。入力が終わったら作成をクリックします。

これでアラートルールの作成は完了です。

3.実際のアラートメール

実際のアラートメールを確認する為にはAzure VM側でOMSエージェントを停止すると確認ができます。OMSエージェント停止後5分経過すると以下のメールが来ます。

Suject:We are notifying you because there are 1 counts of ”アラートルール名”

※Custom log searchを使うと、回復するまでメールが送信され続けます。