[2018/3/26更新] 新規リリースされた “Azure Monitor” 機能を使って、利用中のリソースに影響しうるメンテナンスや障害のメール通知を受け取る


2018/03/26 更新

設定手順について、一部 UI が刷新されたため、最新のものに変更しました。
以前に作成したルールはそのまま残存し、有効であるため、再設定は不要ですのでご安心下さい。

 


こんにちは、Azure プラットフォーム サポート部の石井です。

 

Azure Monitor のサービス正常性の通知機能について、概要と設定手順をご紹介します。

 

- 概要 ~ 何が通知できるのか ~

Azure Monitor のサービス正常性アラートでは、サービスの問題 (いわゆる障害) 情報や、計画メンテナンスによる仮想マシン再起動、ならびに正常性に関する勧告について通知が受けられます。お客様の利用しているサービスに限定された的確な通知が行われ、お客様の設定上も、どのメールアドレスや SMS (携帯電話のショートメッセージ) にて通知を受け取るか、特定のサービスの通知のみ受け取るといったカスタマイズが可能となっています。

 

技術情報 Azure Service Health より抜粋:

  1. サービスの問題 - ユーザーに今すぐ影響を及ぼす Azure サービスの問題。
  2. 定期的なメンテナンス - お使いのサービスの可用性に将来影響を及ぼす可能性のある今後のメンテナンス。
  3. 正常性に関する勧告 - ユーザーが注目する必要のある Azure サービスの変化。 Azure の機能が使用不可になるタイミングや、使用量のクォータを超えた場合に関する例も含まれます。

 

なお、Azure の状態ページの更新が一律に受け取れるものではなく、ご自身のリソースが、"Azure の状態" ページに記載される障害の対象リージョンに存在することが条件となります。

 

参考資料: Azure Monitor の使用
https://docs.microsoft.com/ja-jp/azure/monitoring-and-diagnostics/monitoring-get-started

Azure のアプリケーションおよびリソースの監視
https://docs.microsoft.com/ja-jp/azure/monitoring-and-diagnostics/monitoring-overview

Azure Monitor の料金
https://azure.microsoft.com/ja-jp/pricing/details/monitor/

 

Azure IaaS VM などのパフォーマンス データに対して、「アラート ルール」 を作り、一定の負荷状況になった場合にメール通知する、という機能はこれまでも存在していましたが、Azure Monitor ではこの通知をアクティビティ ログ全般やサービスの正常性においても行えるようにした、と考えていただくとシンプルです。

 

当技術情報では、Azure Monitor の設定を行い、「障害」「計画メンテナンス」「サービスの勧告」 のイベントを通知する方法をご紹介します。

 

- (ステップ1/2)「誰に」通知するかの設定を行う

Azure Monitor では、「誰に」 「何を」 通知するかという 2 つのステップに分かれています。まずは、「誰に」 の部分を設定します。

1. Azure ポータルから、[モニター] – [アクション グループ] を選びます。

まだ [モニター] の登録がない場合、左メニューの一番上より「すべてのサービス >」 (もしくは 「その他のサービス>」) をクリックし、一覧から「モニター」を選択します。☆マークをクリックし、お気に入りにセットしておくと、ポータルの画面左のリストにピン留めされます。

 

2. [アクション グループ] のメニューの画面上から、[アクション グループの追加] を選びます。

3. [アクション グループの追加] メニューにて、設定を入力します。

 

 

アクション グループ名: アクショングループの名前を記載します
短い名前: SMS などテキスト メッセージ内で使われる、識別用の 12 文字以内の名前を入力します
サブスクリプション: 通知グループの格納先のサブスクリプションです
リソース グループ: 通知グループの設定の格納先のリソース グループです

受信者の項にて、受信者の名前、通知の種類 (Email、SMS、ITSM、Webhook、Automation から選択 ※)、メール アドレスの 3 項目を設定します。
合計で 10 個まで、複数の登録が可能です。

 

※ SMS は 2018 年 3 月現在、日本の国番号 (+81) に対応しました。また、Webhook とは、専用の Web アプリケーションをキックするための通知であり、お客様がそういった Web アプリケーションを作成いただいている場合にのみ、ご利用いただくものとなります。

アクション グループの設定について、詳しくは以下技術情報もご参照ください。

Azure Portal でのアクション グループの作成および管理
https://docs.microsoft.com/ja-jp/azure/monitoring-and-diagnostics/monitoring-action-groups

→ 上記登録を保存すると、登録されたメール アカウントに対して、"Microsoft Azure Action Groups actiongroups-noreply@mail.microsoftazure.com" から、"You are now in the '短い名前' action group" という招待メールが届きます。(特にアクションは不要です。)

- (ステップ2/2) 「何を」 通知するかの設定を行う

Azure Monitor では、「誰に」 「何を」 通知するかという 2 つのステップに分かれています。ここでは「何を」 の部分にて、"Azure の状態" Web ページに掲載されるような、サービス正常性の情報を通知するように設定します。

1. Azure ポータル<https://portal.azure.com>を表示し、左メニューより「モニター」をクリックします。 (一覧に無い場合には、左メニューの一番上より「すべてのサービス >」をクリックし、一覧から「モニター」を選択します。)
2. メニューの「サービス正常性 (Service Health)」をクリック、続く画面の [正常性アラート] を選択します。
3. 画面上部の「+サービス正常性アラートの作成」をクリックします

 

4. 通知規則の追加画面が表示されます。

 

アクティビティ ログ アラート名: 分かりやすい名前を入力します。
説明: 当アクティビティ ログ アラートの主旨 (誰に送信するのかなど) を記載しておきます。
サブスクリプション: 当通知の対象となるサブスクリプションです。何らかのリソースで障害が発生しても、リソースが無く該当しないサブスクリプションには通知がされません。
リソース グループ: 当アラートの設定が保存されるリソース グループ名です。(※ 特定のリソース グループの監視をするというものではないのでご注意下さい。)
サービス: 障害が発生したときに含めたいサービスを選択します。絞り込めない場合、全てに設定しておけば OK です。
リージョン: 障害が発生した場合に通知に含めたいリージョンを選択します。ここで選択していないリージョンは、障害が発生しても通知がされません。
Type:  [サービスの問題] (障害)、[計画済みメンテナンス]、[正常性の勧告] (ユーザーが注目すべき Azure サービスの変化) のいずれかにチェックします。基本的にはすべてチェックしていただいて OK です。

※ 詳しい定義については以下をご参照下さい。

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

アクション グループ: 本 Blog の前半でご紹介したアクション グループを作成済みの場合、そちらを選びます。この画面で新規作成することも可能です。説明は本 Blog の前半をご参照下さい。

 


※注意事項:
自分のサブスクリプションに無関係なインシデント (障害) は通知がされません。
何らかのリソースが存在する状態のサブスクリプションで設定をしていただくことが重要です。
また、当アラートでは、Azure の状態ページに表示されない、小規模な事象であっても通知がある場合もございます。

サンプルのメールは以下の通りです。
"accounts-noreply@azureemail.microsoft.com" もしくは "no-reply@email.microsoftazure.com" から送信されます。メールの仕分けルールを作る場合、サービス名やリージョン名をキーワードに入れるとよいでしょう。IaaS 仮想マシンの場合、"Virtual Machines - Southeast Asia" といった形式でタイトルが表示されます。

 

 

 

手順は以上となります。最後に、補足として、サポートに良くご相談をいただいている、「VM のダウンの通知」と、「お客様のサービスへの監視・通知」についても触れさせていただきます。興味がありましたら併せてご参照ください。

 

- 個別の仮想マシンのダウンは通知が出来るのか?

一部のお客様にてご期待いただいている、「Azure 基盤の要因で IaaS の仮想マシンが予期しない再起動をした場合、これで通知がされるの?」 という点について補足させていただきます。

結論から先にいうと、「個別の仮想マシンのダウンをメール通知に含める」という機能は、まだ開発段階にあります。(2018 年 3 月現在も開発中となっていますが、今年中にパブリック プレビューとなる見込みです。)

 

- 「お客様のサービスへの監視の考え方」

Azure Monitor の強みは、これまでに仮想マシン用の拡張機能 (エージェント) で取れなかった、Azure 基盤側の情報が取れることにあります。例えば、「障害の情報」や、Azure 基盤の「ネットワーク セキュリティ グループに関しての通知」 のようにエージェントで監視が出来なかったものなどがあります。

私達サポートではよく、お客様のご質問として「Azure 基盤では VMの死活監視していないの?」「マイクロソフトは、Azure データセンターを持っている側なのだから、(お客様の) サービスがダウンしたことが分かっているはずだし、通知してほしい」といったご相談をいただきます。

監視と言っても、「何を」「どこから」という定義によって、様々です。
Azure プラットフォームからの答えとしては、「VM のアップ・ダウンは監視しています」 が、「お客様の通信内容については特に内容を見ていません」ということが答えになります。
以下のような、様々な固有の状況があって、「ユーザーにとってのソリューション」があり、「お客様のサービスとしてのダウンタイム」が定義されます。

・構築したアプリケーションが、どこと、どのようなプロトコルで通信するか。
・どの VM や PaaS と連携し、ソリューションが構成されているか。
・何をもってダウンとするのか。

具体的に例を挙げてみると、

・VM 上に Web サーバーを構成しており、ポート443 にて通信している。
・VM は Azure ロードバランサー配下にある。
・パブリック IP アドレスは解放しておらず、オンプレミスからの VPN 通信のみ許可している。
・Web サーバーは、バックエンドとして SQL Database と連携している。
・エンド ユーザー (クライアント) は、専用アプリケーションを使って Web サーバーに接続する。アプリケーションでは 1 分間応答が無いとエラーとなる。

といったケースの場合では、5 つ挙げたいずれの点も、お客様のサービスが稼働するために必要な要素となります。「Web サーバーの VM が起動できていたかどうか」 だけでは、サービスが継続するにあたって必要十分にはならず、各項目を監視し、何をもって異常とするのかを定義することが重要です。

このため、Azure の大原則として、上記のような定義に沿った監視はお客様側での実装が不可欠となる、ということです。

 

Azure Monitor のリリースが行われ、将来的には、VM 自体が Azure 基盤側の要因でダウンしてしまった場合には、通知が出来るようになるかもしれません。可能性は広がりますが、お客様のソリューションとしてきちんと動いているか、監視をしていただくことはお客様の責任範囲である、という点をご理解ください。

「Azure Monitor による基盤側や、VM 監視エージェントによる監視」、さらにオプションとして、Application Insights や OMS (Log Analytics) の監視など、強みを組み合わせて監視をしていただき、残る部分についてはお客様のソリューションに適した監視を実装いただくことをお願いいたします。

 


Comments (1)

  1. 河端善博 より:

    Azure 障害を、Azure モニターから通知できる機能、いいですね
    Azure Monitor のコミュニティフォーラムが、欲しくなります。
    通知を試験する機能がほしい、とか
    Webhook へ渡す JSON のサンプルがほしい、とか、投稿するために.

Skip to main content