Li-akb-branch-office

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への転送は診断設定で行います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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にアクションルールという機能があります。

• • アクションルール(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の設定画面に移動します。

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

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

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

• アクションルール固有の重要な設定項目

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

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

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

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

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

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

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

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

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

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

定期的に抑制を行う場合

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

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

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

これで設定は完了です。

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

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

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

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

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

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

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

今回はリソース正常性(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を使ってリソース正常性の監視設定を行ってみました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• • サービス正常性(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(サービス正常性)の監視設定を行ってみます。

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

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

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

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

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

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

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

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

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

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つそれぞれ別々にサービス正常性アラートを作るのが、受け取った時に一番わかりやすいかなぁと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

３.実際に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通知され、それ以降のアラートが通知されない可能性があります。実際の利用にあたっては注意が必要かと思われます。