次の方法で共有

Windows VM の Scheduled Events を監視する

  • [アーティクル]

適用対象: VM ✔️ Windows VM ✔️ フレキシブル スケール セット ✔️ 均一スケール セット

更新プログラムは Azure のさまざまな部分に毎日適用され、そこで実行されているサービスをセキュリティで保護された最新の状態に保ちます。 計画された更新に加えて、計画外のイベントが発生することもあります。 たとえば、ハードウェアの性能低下や障害が検出された場合、Azure サービスでは計画外メンテナンスの実行が必要になることがあります。 ライブ マイグレーション、メモリによる更新プログラムの保持、更新プログラムの影響に対する厳密な制限の維持を使用することで、これらのイベントは顧客に対してほぼ気付かれることがなくなります。 最大で、仮想マシンは数秒間フリーズする場合があります。 ただし、一部のアプリケーションでは仮想マシンが数秒フリーズするだけでも影響を受ける可能性があります。 それらのアプリケーションに最適なエクスペリエンスを確保するには、今後の Azure メンテナンスについて事前に把握しておくことが重要です。 Scheduled Events サービスには、今後のメンテナンスについて通知を受けるためにプログラムのインターフェイスが用意されているため、メンテナンスに適切に対応できるようになります。

この記事では、Scheduled Events を使用して、VM に影響を与える可能性があるメンテナンス イベントについて通知を受け取り、監視と分析に役立つ基本的な自動化を構築する方法について説明します。

スケジュールされたイベントを Log Analytics にルーティングする

Scheduled Events は、すべての Azure 仮想マシン上で使用できる Azure Instance Metadata Service の一部として提供されます。 お客様は、仮想マシンのエンドポイントに対してクエリを実行することで、スケジュールされたメンテナンス通知を検索して、状態の保存や仮想マシンのローテーションからの除外などの軽減策を実行するといった、自動化を作成できます。 Scheduled Events を記録する自動化を作成することをお勧めします。これにより、Azure メンテナンス イベントの監査ログを取得できます。

この記事では、メンテナンスの Scheduled Events を Log Analytics に記録する方法について説明します。 次に、所属チームへのメール送信、仮想マシンに影響したすべてのイベントの履歴ビューの取得など、いくつかの基本的な通知アクションをトリガーします。 イベントの集計と自動化には Log Analytics を使用しますが、これらのログの収集と自動化のトリガーには任意の監視ソリューションを使用できます。

イベントのライフサイクルを示す図

前提条件

この例では、可用性セット内に Windows 仮想マシンを作成する必要があります。 Scheduled Events から、可用性セット、クラウド サービス、仮想マシン スケール セット、またはスタンドアロン VM 内の仮想マシンのいずれかに影響する可能性がある変更について通知が提供されます。 コレクターとして機能する複数の VM のうち 1 台の上で、Scheduled Events をポーリングし、可用性セット内にあるその他すべての VM のイベントを取得するサービスが実行されます。

このチュートリアルの終了時に、グループ リソース グループを削除しないでください。

また、可用性セット内の VM から情報を集計するために使用する Log Analytics ワークスペースを作成する必要もあります。

環境をセットアップする

これで、可用性セット内に 2 つの初期 VM が作成されました。 次に、同じ可用性セット内に myCollectorVM という 3 番目の VM を作成する必要があります。

New-AzVm `
   -ResourceGroupName "myResourceGroupAvailability" `
   -Name "myCollectorVM" `
   -Location "East US" `
   -VirtualNetworkName "myVnet" `
   -SubnetName "mySubnet" `
   -SecurityGroupName "myNetworkSecurityGroup" `
   -OpenPorts 3389 `
   -PublicIpAddressName "myPublicIpAddress3" `
   -AvailabilitySetName "myAvailabilitySet" `
   -Credential $cred

  1. GitHub からプロジェクトのインストール .zip ファイルをダウンロードします。

  2. myCollectorVM に接続し、.zip ファイルをその仮想マシンにコピーして、すべてのファイルを抽出します。 ご利用の VM 上で PowerShell プロンプトを開きます。 SchService.ps1 が含まれるフォルダー (例: PS C:\Users\azureuser\AzureScheduledEventsService-master\AzureScheduledEventsService-master\Powershell>) にプロンプトを移動し、サービスを設定します。

    .\SchService.ps1 -Setup

  3. サービスを開始します。

    .\SchService.ps1 -Start

  4. サービスの状態を検証し、それが実行中であることを確認します。

    .\SchService.ps1 -status

    検証コマンドは "Running" を返す必要があります。

サービスでは、スケジュールされたイベントのポーリングが 10 秒ごとに開始され、イベントが承認され、メンテナンスが迅速化されます。 凍結、再起動、再デプロイ、およびプリエンプトは、スケジュール イベントによってキャプチャされるイベントです。 イベントを承認する前にいくつかの軽減策をトリガーするようにスクリプトを拡張することができます。

上記のイベントのいずれかが Schedule Event サービスによってキャプチャされると、アプリケーション イベント ログのイベントの状態、イベントの種類、リソース (仮想マシン名)、および NotBefore (最小通知期間) に記録されます。 アプリケーション イベント ログでは、ID が 1234 のイベントを見つけることができます。

サービスを設定して開始すると、Windows アプリケーション ログにイベントが記録されます。 これが機能することを確認するには、可用性セット内のいずれかの仮想マシンを再起動します。イベント ビューアーの [Windows ログ] > [アプリケーション ログ] に、VM が再起動されたことを示すログが表示されるはずです。

イベント ビューアーのスクリーンショット。

イベントが Schedule Event サービスによってキャプチャされると、イベントの状態、イベントの種類、リソース (仮想マシン名)、および NotBefore (最小通知期間) がアプリケーション イベント ログに記録されます。 アプリケーション イベント ログでは、ID が 1234 のイベントを見つけることができます。

Note

この例では、仮想マシンが可用性セット内に置かれていたため、1 つの仮想マシンをコレクターとして指定することで、スケジュールされたイベントをリッスンし、ログ分析ワークスペースにルーティングすることができました。 スタンドアロンの仮想マシンが複数ある場合は、どの仮想マシンでもサービスを実行することができ、それぞれを個別にログ分析ワークスペースに接続することができます。

このセットアップでは、Windows を選択しましたが、Linux 上でも同様のソリューションを設計することができます。

Scheduled Event Service は、–stop スイッチおよび –remove スイッチを使用して、いつでも停止または削除することができます。

Log Analytics ワークスペースに接続する

ここで、Log Analytics ワークスペースをコレクター VM に接続します。 Log Analytics ワークスペースはリポジトリとして機能するので、コレクター VM からアプリケーション ログをキャプチャできるようにイベント ログ コレクションを構成します。

Scheduled Events をイベント ログ (サービスによってアプリケーション ログとして保存されます) にルーティングするには、仮想マシンを Log Analytics ワークスペースに接続する必要があります。

データ収集を設定する

  1. Azure Portalを開きます。

  2. 上部の検索バー内に「Log Analytics ワークスペース」と入力して、検索結果からそれを選択します。

  3. 作成したワークスペースを選択し、そのページを開きます。

  4. [設定] の下で [エージェント] を選択してから [Virtual Machines] をクリックします。

  5. [Windows サーバー] タブの下で [データ収集ルール] をクリックします。

  6. [収集と配信] タブに移動して [データ ソースの追加] をクリックします空の [データ ソース] セクションを含む [収集と配信] タブのスクリーンショット。

  7. [データ ソース] タブの下で、ドロップダウンから [Windows イベント ログ] を選択します。

  8. 収集するイベント ログを選択します。 [エラー]、[警告]、[情報] が選択されていることを確認してください。 いくつかの選択されたチェック ボックスを示す [データ ソースの追加] タブのスクリーンショット。

  9. [次へ : ターゲット] をクリックします>

  10. [ターゲット] タブの下で [ターゲットの追加] をクリックします。

  11. [ターゲットの種類]、[サブスクリプション]、[宛先の詳細] セクションに、コレクター VM とそのサブスクリプションの詳細を入力します。 [種類]、[サブスクリプション]、[宛先の詳細] を示す [ターゲット] タブのスクリーンショット。

  12. 正しい VM を選択すると、Microsoft Monitoring Agent が仮想マシン上に自動的にインストールされます。 ご利用の VM をワークスペースに接続して拡張機能をインストールするまで数分かかります。

Note

多少の遅延が発生し、ログが使用可能になるまでに最大で 10 分かかる場合があります。

Azure Monitor を使用したアラート ルールの作成

イベントが Log Analytics にプッシュされたら、次のクエリを実行して、スケジュール イベントを探すことができます。

  1. ページの上部にある [ログ] を選択し、次の内容をテキスト ボックスに貼り付けます。

    Event
| where EventLog == "Application" and Source contains "AzureScheduledEvents" and RenderedDescription contains "Scheduled" and RenderedDescription contains "EventStatus" 
| project TimeGenerated, RenderedDescription
| extend ReqJson= parse_json(RenderedDescription)
| extend EventId = ReqJson["EventId"]
,EventStatus = ReqJson["EventStatus"]
,EventType = ReqJson["EventType"]
,NotBefore = ReqJson["NotBefore"]
,ResourceType = ReqJson["ResourceType"]
,Resources = ReqJson["Resources"]
| project-away RenderedDescription,ReqJson

  2. [保存] を選択してから、名前として「ogQuery」を入力し、種類は [クエリ] のままとし、 VMLogs に「VMLogs」と入力して、 [保存] を選択します。

    クエリの保存

  3. [新しいアラート ルール] を選択します。

  4. [ルールの作成] ページでは、 [リソース] として collectorworkspace をそのまま使用します。

  5. [条件] で、エントリ [Whenever the customer log search is <login undefined>](顧客のログ検索が <ログイン未定義> のとき常に) を選びます。 [シグナル ロジックの構成] ページが開きます。

  6. [しきい値] に「0」を入力して、 [完了] を選択します。

  7. [アクション] で、 [アクショングループの作成] を選択します。 [アクション グループの追加] ページが開きます。

  8. [アクション グループ名] に「myActionGroup」と入力します。

  9. [短い名前] に「myActionGroup」と入力します。

  10. [リソース グループ] で、myResourceGroupAvailability を選択します。

  11. [アクション] の [アクション名] に「電子メール」 と入力し、 [電子メール/SMS/プッシュ/音声] を選択します。 [電子メール/SMS/プッシュ/音声] ページが開きます。

  12. [電子メール] を選択し、ご自分の電子メール アドレスを入力して、 [OK] を選択します。

  13. [アクション グループの追加] ページで、 [OK] を選択します。

  14. [ルールの作成] ページの [アラートの詳細] で、 [アラート ルール名] に「myAlert」と入力し、 [説明] に「電子メールによるアラート ルール」と入力します。

  15. 完了したら、[アラート ルールの作成] を選択します。

  16. 可用性セット内の VM のいずれかを再起動します。 数分以内に、アラートがトリガーされたことを知らせる電子メールが届きます。

ご自分のアラート ルールを管理するには、リソース グループに移動し、左側のメニューから [アラート] を選択し、次にページの上部にある [アラート ルールの管理] を選択します。

次のステップ

詳細については、GitHub の「Scheduled events service」 (スケジュール化されたイベント サービス) ページを参照してください。