Azure Monitor のアラートの問題のトラブルシューティング
この記事では、Azure Monitor のアラートと通知に関する一般的な問題について説明します。 Azure Monitor のアラートは、監視データで重要な状態が見つかると事前に通知します。
Azure メトリックまたはログ検索のアラートのトラブルシューティングに関する詳細については、次をご覧ください。
トラブルシューティングの前に
アラートは意図したとおりに発生しても、適切な通知が期待したように行われない場合は、最初にアクション グループをテストして、適切に構成されていることを確認してください。
それ以外の場合は、この記事の残りの部分の情報を使って問題のトラブルシューティングを行ってください。
予想されるメールが届かなかった
アラートが発生したことは Azure portal で確認できるが、構成したメールを受け取らなかった場合は、次の手順のようにします。
警告処理ルールによってメールが抑制されたのか?
確認するには、発生したアラートをポータルでクリックし、抑制されたアクション グループの履歴タブを確認します。
アクションの種類が "Azure Resource Manager のロールへのメール" か?
このアクションは Azure Resource Manager ロールの割り当てのみを参照しますが、この割り当てのスコープはサブスクリプションであり、種類は [ユーザー] です。 リソース レベルまたはリソース グループ レベルではなくサブスクリプション レベルでロールを割り当てたことを確認します。
メール サーバーとメールボックスは外部メールを受け付けているか?
次の 3 つのアドレスからのメールがブロックされていないことを確認します。
- azure-noreply@microsoft.com
- azureemail-noreply@microsoft.com
- alerts-noreply@mail.windowsazure.com
内部向けのメーリング リストや配信リストでは、外部のメール アドレスからのメールをブロックするのが一般的です。 上記のメール アドレスからのメールを許可していることを確認します。 テストするには、(メーリング リストではなく) 通常の仕事用メール アドレスをアクション グループに追加し、そのメールにアラートが届くかどうか確認します。
受信トレイのルールまたはスパム フィルターによってメールが処理されたか?
これらのメールを削除したり、サイド フォルダーに移動したりする受信トレイのルールがないことを確認します。 たとえば、受信トレイのルールは、特定の送信者や、件名に含まれる特定の単語を捕捉することがあります。 以下の点も確認してください。
- メール クライアント (Outlook、Gmail など) のスパム設定
- メール サーバー (Exchange、Microsoft 365、G Suite など) の送信者制限/スパム設定/検査設定
- メール セキュリティ アプライアンス (Barracuda、Cisco など) がある場合、その設定。
アクション グループから誤って登録解除したか?
アラート メールには、アクション グループから登録解除するためのリンクが用意されています。 このアクション グループから誤って登録を解除したかどうかを確認するには、次のいずれかを実行します。
- ポータルでアクション グループを開き、[状態] 列を確認します。
![アクション グループの [状態] 列のスクリーンショット。](media/alerts-troubleshoot/action-group-status.png)
- メールから登録解除の確認を探します。
再登録 - 受信した登録解除確認メール内のリンクを使用するか、アクション グループからメール アドレスを削除してから再度そのアドレスを追加します。
1 つのメール アドレスに多数のメールを送信して、サービスの制限を超えているか?
電子メールは、電子メール アドレスごとに 1 時間に 100 通以下にレート制限されています。 このしきい値を超えた場合、それ以上メール通知は送信されません。 自分のメール アドレスが一時的にレート制限されているというメッセージが届いていないか確認します。
レート制限なしで大量の通知を受け取りたい場合は、次のような別のアクションを使うことを検討します。
- Webhook
- ロジック アプリ
- Azure 関数
- Automation Runbook
これらのアクションはいずれもレート制限されません。
![アクション グループの [状態] 列のスクリーンショット。](media/alerts-troubleshoot/action-group-status.png#lightbox)
予期される SMS、音声通話、またはプッシュ通知を受け取らなかった
アラートが発生したことはポータルで確認できるが、構成した SMS、音声通話、またはプッシュ通知を受け取らなかった場合は、次の手順のようにします。
警告処理ルールによってアクションが抑制されたのか?
確認するには、発生したアラートをポータルでクリックし、抑制されたアクション グループの履歴タブを確認します。
意図しないものだった場合は、警告処理ルールを変更、無効化、または削除します。
SMS/音声: 電話番号は正しいか?
SMS アクションの国番号または電話番号の入力に誤りがないか確認してください。
SMS/音声: サービスの制限を超えているか?
SMS と音声通話による通知は、各電話番号で 5 分ごとに 1 件以下にレート制限されています。 このしきい値を超えると、通知は破棄されます。
- 音声通話 - 通話履歴を調べて、前の 5 分間に Azure から別の通話があったかどうか確認します。
- SMS - 電話番号がレート制限が適用されているというメッセージがないか SMS の履歴を確認します。
レート制限なしで大量の通知を受け取りたい場合は、次のような別のアクションを使うことを検討します。
- Webhook
- ロジック アプリ
- Azure 関数
- Automation Runbook
これらのアクションはいずれもレート制限されません。
SMS: アクション グループから誤って登録解除したか?
SMS の履歴を開き、(DISABLE action_group_short_name 応答を使用して) この特定のアクション グループからの、または (STOP 応答を使用して) すべてのアクション グループからの SMS 配信をオプトアウトしていないか確認します。
再登録するには、適切な SMS コマンド (ENABLE action_group_short_name または START) を送信します。または、アクション グループから SMS アクションを削除してから、再度追加します。 詳細については、「アクション グループの SMS アラート動作」を参照してください。
端末で誤って通知をブロックしていないか?
ほとんどの携帯電話では、特定の電話番号やショート コードからの通話や SMS をブロックしたり、(Azure mobile app などの) 特定のアプリからのプッシュ通知をブロックしたりできます。 端末で誤って通知をブロックしていないか確認するには、お使いの端末のオペレーティング システムとモデルのドキュメントを参照するか、別の端末と電話番号を使ってテストしてください。
予期されるアクションがトリガーされなかった
アラートが発生したことはポータルで確認できるが、構成したアクションがトリガーされなかった場合は、次の手順のようにします。
警告処理ルールによってアクションが抑制されたのか?
確認するには、発生したアラートをポータルでクリックし、抑制されたアクション グループの履歴タブを確認します。
意図しないものだった場合は、警告処理ルールを変更、無効化、または削除します。
Webhook はトリガーしたか?
送信元 IP アドレスはブロックされているか?
Webhook の呼び出し元 IP アドレスを許可リストに追加します。
Webhook エンドポイントは正しく機能しているか?
構成した Webhook エンドポイントが正しいこと、およびエンドポイントが正常に動作していることを確認します。 Webhook のログを確認するか、調査ができるように Webhook のコードをインストルメント化します (たとえば、受信ペイロードをログに記録します)。
正しい形式を使って Slack または Microsoft Teams を呼び出しているか?
これらのエンドポイントはそれぞれ、特定の JSON 形式を想定しています。 この手順に従って、代わりにロジック アプリ アクションを構成してください。Webhook が応答しなくなったか、エラーを返していますか?
Webhook アクション グループでは通常、呼び出されたときに次の規則に従います。
- Webhook の呼び出し時、最初の呼び出しが失敗した場合、少なくとも 1 回の再試行、さらにさまざまな待ち時間間隔 (5、20、40 秒) で最大 5 回の再試行が行われます。
- 1 回目から 2 回目の試行までの待ち時間は 5 秒です
- 2 回目から 3 回目の試行までの待ち時間は 20 秒です
- 3 回目から 4 回目の試行までの待ち時間は 5 秒です
- 4 回目から 5 回目の試行までの待ち時間は 40 秒です
- 5 回目から 6 回目の試行までの待ち時間は 5 秒です
- Webhook を呼び出そうとする試みが失敗した場合、アクション グループは 15 分間エンドポイントを呼び出しません。
- 再試行ロジックは、呼び出しを再試行できることを前提としています。 状態コード: 408、429、503、504、または
HttpRequestException、WebException、TaskCancellationExceptionは、呼び出しの再試行を許可します。
- Webhook の呼び出し時、最初の呼び出しが失敗した場合、少なくとも 1 回の再試行、さらにさまざまな待ち時間間隔 (5、20、40 秒) で最大 5 回の再試行が行われます。
アクションまたは通知が複数回発生した
アラートの通知 (メールや SMS など) を 2 回以上受信した場合や、アラートのアクション (Webhook または Azure 関数など) が複数回トリガーされた場合は、以下の手順に従います。
本当に同じアラートか?
複数の同じようなアラートがほぼ同時に発生する場合があります。 そのため、同じアラートによってアクションが何回もトリガーされたように見えるかもしれません。 たとえば、イベント状態フィールドでフィルター処理をしないことによって、アクティビティ ログ アラート ルールがイベントの開始時と終了時 (成功か失敗かを問わず) の両方で発動するように構成されている場合があります。
これらのアクションまたは通知が異なるアラートからのものかどうか確認するには、アラートのタイムスタンプや、アラート ID またはその関連付け ID など、アラートの詳細を調べます。 または、発生したアラートの一覧をポータルで確認します。 当てはまる場合、アラート ルールのロジックを調整するか、アラートのソースを構成することが必要になります。
複数のアクション グループでアクションが繰り返されるか?
アラートが発生すると、アラートのアクション グループが 1 つ 1 つ、個別に処理されます。 そのため、(メール アドレスなどの) 1 つのアクションが、トリガーされた複数のアクション グループに出現する場合、そのアクションはアクション グループごとに 1 回ずつ呼び出されます。
トリガーされたアクショングループを確認するには、[アラートの履歴] タブを確認します。アラート ルールに定義されているアクション グループと、警告処理ルールによってアラートに追加されたアクション グループの両方が表示されます:
予期しない内容がアクションまたは通知に含まれている
フォールバック メール プロバイダーの使用をトリガーする障害が発生したか?
アクション グループでは、電子メール通知を確実に配信するために 2 つの異なる電子メール プロバイダーを使用しています。 プライマリ メール プロバイダーは回復性が高く、迅速ですが、障害が発生することがあります。 障害が発生した場合は、セカンダリ メール プロバイダーがメール要求を処理します。 セカンダリ プロバイダーはフォールバック ソリューションにすぎません。 プロバイダーの違いにより、セカンダリ プロバイダーから送信されるメールではメール エクスペリエンスが低下する可能性があります。 エクスペリエンスが低下すると、電子メールの書式設定とコンテンツにわずかな相違が生じます。 2 つのシステム間でメール テンプレートが異なるため、2 つのシステム間で同等性を維持することは実現不可能です。
フォールバック ソリューションによって生成される通知には、次の注意が含まれています。
"これは、電子メール エクスペリエンスが低下していることを示すものです。 書式設定がオフになっているか、詳細が見つからない可能性があります。 低下したメール エクスペリエンスの詳細については、こちらを参照してください。"
通知にはこの注意が含まれず、アラートを受け取ったものの、そのフィールドの一部が欠落しているか正しくないと思われる場合は、ペイロードの形式を確認します。
アラート ルールを構成するときに、どのような形式を使用したか?
アクションの種類 (メール、Webhook など) ごとに、既定のレガシ形式と、共通スキーマ形式の、2 つの形式があります。 アクション グループを作成するときは、アクションの形式を指定します。 アクション グループ内のアクションが異なると、形式が異なる場合があります。
たとえば、Webhook アクションの場合は次のようになります。
アクション レベルで指定された形式が想定どおりかどうか確認します。 たとえば、ある形式を想定して (Webhook、関数、ロジック アプリなどの) アラートに応答するコードを開発したのに、後になってアクション内で自分または別の人が別の形式を指定したという場合があります。
また、アクティビティ ログ アラート、ログ検索アラート (Application Insights とログ分析の両方)、メトリック アラート、一般的なアラート スキーマ、非推奨のクラシック メトリック アラートのペイロード形式 (JSON) も確認してください。
検索結果がログ検索アラート通知には含まれない。
ログ検索アラート API バージョン 2021-08-01 以降では、アラート通知ペイロードから検索結果が削除されました。 検索結果は、以前の API バージョン (2018-04-16) で作成されたアラート ルールでのみ利用できます。 Azure portal で新しいアラート ルールを作成すると、新しいバージョンのルールが既定で作成されます。 更新バージョンを使用するための変更と推奨される調整については、「ログ アラート ルールの作成エクスペリエンスの変更」に従ってください。
解決されたログ検索アラート通知で MetricValue フィールドに "null" が含まれる。
これは仕様です。 ステートフル ログ検索アラートでは、値ベースではなく、時間ベースの解決ロジックが使われます。 Azure Monitor は、アラートが解決した原因が値ではなく、経過時間であるため、null メトリック値を送信しています。
ディメンション リストが空であるか、アラート タイトルにディメンション名が含まれていない
結果を返さないログ検索アラート ルールがある場合、アラートは期待どおりに発生しますが、ディメンション リストが空であるか、アラート タイトルにディメンション名が含まれません。 クエリが行を何も返さない場合、(ディメンションとタイトル フィールドを設定する基になる) リソース ID フィールドは空です。
アクティビティ ログ アラートに情報が含まれない
アクティビティ ログ アラートは、Azure アクティビティ ログに書き込まれたイベントに基づくアラートです。イベントの例には、Azure リソースの作成、更新、削除に関するイベント、サービス正常性とリソース正常性のイベント、Azure Advisor や Azure Policy からの情報などがあります。 アクティビティ ログに基づくアラートを受信したが、必要なフィールドの一部が欠落しているか正しくない場合は、まず、アクティビティ ログ自体の中でイベントを確認します。 アクティビティ ログ イベント内で自分が探しているフィールドを Azure リソースが書き込んでいなかった場合、それらのフィールドは対応するアラートには含まれません。
メール、SMS、またはプッシュ通知からのカスタム プロパティがありません。
カスタム プロパティは、Webhook、Azure 関数、ロジック アプリなどのアクションのペイロードにのみ渡されます。 通知 (メール、SMS、プッシュ) にはカスタム プロパティは含まれません。
警告処理ルールが期待どおりに動作しない
アラートが発生したことはポータルで確認できるが、関連する警告処理ルールが想定どおりに機能しない場合は、次の手順のようにします。
警告処理ルールは有効になっていますか?
[警告処理ルールの状態] フィールドを確認して、関連するアクションロールが有効になっていることを確認します。 既定では、ポータルには有効になっているアラート ルールのみが表示されますが、すべてのルールを表示するようにフィルターを変更できます。
有効になっていない場合は、警告処理ルールを選んで [有効にする] をクリックすると有効にできます。
サービス正常性アラートか?
サービス正常性アラートは、警告処理ルールの影響を受けません。 そのため、サービス正常性アラートを含むスコープに対して警告処理ルールが構成されている場合、サービス正常性アラートがスコープ内にあっても、警告処理ルールはそれらに影響しません。
警告処理ルールがアラートを処理したか?
発生したアラートをポータルで選び、[履歴] タブを見て、警告処理ルールが処理されたかどうかを確認します。
すべてのアクション グループを抑制する警告処理ルールの例を次に示します。
別のアクション グループを追加する警告処理ルールの例を次に示します。
警告処理ルールのスコープとフィルターは発生したアラートと一致しているか?
警告処理ルールが発動すべきなのに発動しなかった、または発動すべきでないのに発動したと思われる場合は、警告処理ルールのスコープとフィルターの条件を注意深く調べて、発生したアラートのプロパティと比較します。
Azure portal での警告処理ルールの作成、更新、削除の問題
警告処理ルールの作成、更新、または削除中にエラーが発生した場合は、次の手順に従います:
アクセス許可を確認します。
共同作成者の監視の組み込みロール、または警告処理ルールとアラートに関連した特定のアクセス許可のいずれかが必要です。
警告処理ルールのパラメーターを確認します。
警告処理ルールのドキュメント、または警告処理ルールの PowerShell Set-AzAlertProcessingRule コマンドを確認します。