新しいアラートへの移行オプションについて

パブリック クラウド ユーザー向けの従来のアラートは廃止されています。 Azure Government クラウドおよび 21Vianet によって運営される Microsoft Azure 向けの従来のアラートは、2024 年 2 月 29 日に廃止されます。

この記事では、手動移行と自発的移行ツールがどのように機能するかについて説明します。このツールは、残りのアラート ルールを移行するために使用されます。 また、一般的な問題をいくつか取り上げて、その解決方法を紹介します。

従来のアラートの新しいアラートへの手動移行

残りのアラートを手動で移行することに関心のあるお客様は、以降のセクションを参考にして、それを既に実行することができます。 また、それには、廃止されているため直接移行できないメトリックも含まれます。

仮想マシンのゲスト メトリック

ゲスト メトリックに新しいメトリック アラートを作成するには、その前にゲスト メトリックを Azure Monitor ログ ストアに送信する必要があります。 アラートを作成するには、以下の手順のようにします。

• Log Analytics へのゲストメトリック収集の有効化
• Azure Monitor でのログ検索アラートの作成

ゲスト メトリックとそれに対するアラートを収集するオプションは他にもあります。詳細については、こちらを参照してください。

ストレージと従来のストレージのアカウントのメトリック

これらのメトリックに対するアラートを除いて、ストレージ アカウントに対するすべてのクラシック アラートを移行できます。

• PercentAuthorizationError
• PercentClientOtherError
• PercentNetworkError
• PercentServerOtherError
• PercentSuccess
• PercentThrottlingError
• PercentTimeoutError
• AnonymousThrottlingError
• SASThrottlingError
• ThrottlingError

パーセント メトリックに対するクラシック アラート ルールは、従来のストレージ メトリックと新しいストレージ メトリック間のマッピングに基づいて移行する必要があります。 使用可能な新しいメトリックは絶対値であるため、しきい値を適切に変更する必要があります。

AnonymousThrottlingError、SASThrottlingError、および ThrottlingError に関するクラシック アラート ルールについては、同じ機能を提供する一体型のメトリックがないため、2 つの新しいアラートに分割する必要があります。 しきい値を適切に調整する必要があります。

Azure Cosmos DB のメトリック

これらのメトリックに対するアラートを除いて、Azure Cosmos DB メトリックに対するすべてのクラシック アラートを移行できます。

• 1 秒あたりの平均要求数
• 整合性レベル
• HTTP 2xx
• HTTP 3xx
• 1 分あたりの最大 RUPM 消費量
• 1 秒あたりの最大 RU 数
• その他の Mongo 要求の料金
• その他の Mongo 要求のレート
• 測定された読み取り待機時間
• 測定された書き込み待機時間
• サービスの可用性
• ストレージの容量

1 秒あたりの平均要求数、整合性レベル、1 分あたりの最大 RUPM 消費量、1 秒あたりの最大 RU 数、測定された読み込み待機時間、測定された書き込み待機時間、ストレージ容量は現在、新しいシステムで使用できません。

HTTP 2xx、HTTP 3xx、サービス可用性などの要求メトリックに関するアラートは、要求のカウント方法がクラシックのメトリックと新しいメトリックの間で異なるため、移行されません。 これらにメトリックに関するアラートは、しきい値を調整して手動で再作成する必要があります。

非推奨のメトリックに対するクラシック アラート ルール

以下は、以前はサポートされていましたが、結局非推奨とされたメトリックに対するクラシック アラート ルールです。 ごく一部のお客様は、このようなメトリックに対する無効なクラシック アラート ルールを持っている場合があります。 これらのアラート ルールは無効であるため、移行されません。

同等の新しいアラート ルールとアクション グループはどのように作成されるか

移行ツールにより、クラシック アラート ルールは同等の新しいアラート ルールとアクション グループに変換されます。 ほとんどのクラシック アラート ルールでは、同等の新しいアラート ルールは、windowSize や aggregationType など、同じプロパティを持つ同じメトリックに対するものとなります。 ただし、一部のクラシック アラート ルールは、新しいシステムの、別個かつ同等のメトリックに対するものとなります。 次の原則は、後のセクションで指定されていなければクラシック アラートの移行に適用されます。

• 頻度: クラシック アラート ルールまたは新しいアラート ルールが条件をチェックする頻度を定義します。 クラシック アラート ルールの frequency は、ユーザーは構成できず、すべてのリソースの種類で常に 5 分でした。 同等のルールの頻度も 5 分に設定されます。
• 集計の種類: 関心のあるウィンドウ全体にわたるメトリックの集計方法を定義します。 aggregationType も、ほとんどのメトリックについて、クラシック アラートと新しいアラートの間に違いはありません。 場合によってはクラシック アラートと新しいアラートの間でメトリックが異なるため、そうしたメトリックに対して定義される同等の aggregationType または primary Aggregation Type が使用されます。
• 単位: アラートが作成される対象のメトリックのプロパティ。 一部の同等メトリックの単位は異なっています。 しきい値は、必要に応じて適切に調整されます。 たとえば、元のメトリックが秒単位であるのに、同等の新しいメトリックがミリ秒単位である場合、確実に同じ動作となるように、元のしきい値には 1000 が掛けられます。
• ウィンドウ サイズ: しきい値と比較するため、メトリック データを集計するウィンドウを定義します。 5 分、15 分、30 分、1 時間、3 時間、6 時間、12 時間、1 日といった標準の windowSize 値では、同等の新しいアラート ルールのために行われた変更はありません。 その他の値の場合、最も近い windowSize が使用されます。 ほとんどのお客様にとって、この変更の影響はありません。 ごく一部のお客様については、まったく同じ動作を得るためにしきい値の調整が必要な可能性があります。

以降のセクションでは、新しいシステムで別個かつ同等のメトリックを持つメトリックについて詳しく説明します。 クラシック アラート ルールと新しいアラート ルールで同じままのメトリックはすべて、一覧に記載されていません。 新しいシステムでサポートされるメトリックの一覧は、ここにあります。

Microsoft.Storage/storageAccounts と Microsoft.ClassicStorage/storageAccounts

BLOB、テーブル、ファイル、キューなどのストレージ アカウント サービスの場合、以下のメトリックは次に示す同等のメトリックにマッピングされています。

Microsoft.DocumentDB/databaseAccounts

Azure Cosmos DB の場合、同等のメトリックは以下のとおりです。

同等のアクション グループはどのように作成されるか

クラシック アラート ルールには、アラート ルール自体に関連付けられているメール、Webhook、ロジック アプリ、Runbook のアクションがあります。 新しいアラート ルールでは、複数のアラート ルールにわたって再利用できるアクション グループが使用されます。 そのアクションをいくつのアラート ルールが使用しているかに関わらず、移行ツールにより同じアクションに対して 1 つのアクション グループが作成されます。 移行ツールによって作成されたアクション グループは、"Migrated_AG*" という名前付け形式を使用します。

展開の段階

移行ツールは、クラシック アラート ルールを使用しているすべてのお客様に対して段階的に展開中です。 ツールを使用してサブスクリプションを移行する準備ができたら、サブスクリプションの所有者に電子メールが届きます。

ほとんどのサブスクリプションが、現在は移行準備完了としてマークされます。 まだ移行準備ができていないのは、以下のリソースの種類に対するクラシック アラート ルールがあるサブスクリプションのみです。

• Microsoft.classicCompute/domainNames/slots/roles
• Microsoft.insights/components

移行をトリガーできるユーザー

サブスクリプション レベルで、組み込みロールの監視共同作業者を割り当てられたすべてのユーザーが移行をトリガーできます。 また、次の権限を持つカスタム ロールが割り当てられたユーザーも移行をトリガーできます。

• */read
• Microsoft.Insights/actiongroups/*
• Microsoft.Insights/AlertRules/*
• Microsoft.Insights/metricAlerts/*
• Microsoft.AlertsManagement/smartDetectorAlertRules/*

一般的な問題と解決方法

移行をトリガーしたら、移行が完了したこと、または何らかのアクションが必要なことを通知するメールが、指定したアドレスに届きます。 このセクションでは、一般的な問題とその対処方法について説明します。

検証に失敗しました

サブスクリプション内のクラシック アラートに対する最近のいくつかの変更が原因で、サブスクリプションを移行できません。 これは一時的な問題です。 移行の状態が [Ready for migration](移行準備完了) に戻ったら、移行を再開できます。

スコープ ロックによりルールを移行できない

移行の一環として、新しいメトリック アラートと新しいアクション グループが作成され、クラシック アラート ルールが削除されますが、 スコープ ロックによって、リソースの作成または削除が妨げられる可能性があります。 スコープ ロックによっては、一部またはすべてのルールを移行できない可能性があります。 この問題は、移行ツールに関するページに一覧表示されている、サブスクリプション、リソース グループ、またはリソースのスコープ ロックを削除し、移行を再度トリガーすることで解決できます。 スコープ ロックを無効にすることはできず、移行プロセスの間は削除する必要があります。 スコープ ロックの管理の詳細はこちら。

"Deny" 効果が使用されたポリシーによってルールの移行が妨げられる

移行の一環として、新しいメトリック アラートと新しいアクション グループが作成され、クラシック アラート ルールが削除されますが、 Azure ポリシーの割り当てによって、リソースの作成が妨げられる可能性があります。 ポリシーの割り当てによっては、一部またはすべてのルールを移行できない可能性があります。 プロセスをブロックしているポリシー割り当ては、移行ツールに関するページに一覧表示されます。 この問題は、次のいずれかの方法で解決できます。

• 移行プロセスの間に、ポリシー割り当てからサブスクリプション、リソース グループまたは個別のリソースを除外します。 ポリシーの除外スコープの管理の詳細。
• ポリシー割り当てに対して "強制モード" を Disabled (無効) に設定します。 ポリシー割り当ての enforcementMode プロパティの詳細
• サブスクリプション、リソースグループ、または個々のリソースの Azure Policy 除外 (プレビュー) をポリシー割り当てに設定します。 Azure Policy の除外構造の詳細
• 効果を削除するか、「無効」、「監査」、「追加」または「修正」 に変更する (これにより、たとえば、タグの欠落に関連する問題を解決できます)。 ポリシー効果の管理い関する詳細.

次のステップ

• 移行を準備する