Azure Monitor のアラートの問題のトラブルシューティング
この記事では、Azure Monitor のアラートと通知に関する一般的な問題について説明します。 Azure Monitor のアラートは、監視データで重要な状態が見つかると事前に通知します。 管理者は、その通知を見て、システムのユーザーが問題に気付く前に問題を識別して対処できます。 アラートの詳細については、「Microsoft Azure のアラートの概要」を参照してください。
Azure portal では、始動したアラートを確認できます。
予想どおりに動作しないメトリックまたはログ アラートに関するトラブルシューティング情報については、次の記事を参照してください。
Azure portal に従って意図どおりにアラートが始動しても適切に通知されない場合、残りの記事の情報を利用し、その問題を解決してください。
アラートのアクションまたは通知が想定どおりに機能しなかった
発生したアラートを Azure portal で確認できるが、そのアクションまたは通知の一部に問題がある場合は、以下のセクションを参照してください。
想定していたメールが届いていない
発生したアラートを 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 関数、オートメーション Runbook など、レート制限を受けない別のアクションの使用を検討してください。
想定していた SMS、音声通話、またはプッシュ通知が来なかったか?
発生したアラートをポータルで確認できるが、そのアラートに設定した SMS、音声通話、またはプッシュ通知が来ていない場合は、次の手順に従います。
アラート抑制ルールによってアクションが抑制されたのか?
確認するには、発生したアラートをポータルでクリックし、抑制されたアクション グループの履歴タブを確認します。
意図しないものだった場合は、アラート処理ルールを変更、無効化、または削除します。
SMS /音声: 電話番号は正しいか?
SMS アクションの国番号または電話番号の入力に誤りがないか確認してください。
SMS/音声: レート制限されているか?
SMS と音声通話による通知は、各電話番号で 5 分ごとに 1 件以下にレート制限されています。 このしきい値を超えると、通知は破棄されます。
- 音声通話 - 通話履歴を調べて、前の 5 分間に Azure から別の通話があったかどうか確認します。
- SMS - SMS の履歴を調べて、電話番号にレート制限が適用されたことを示すメッセージがないかどうかを確認します。
レート制限なしで大量の通知を受信することが必要な場合は、Webhook、ロジック アプリ、Azure 関数、オートメーション Runbook など、レート制限を受けない別のアクションの使用を検討してください。
SMS: アクション グループから誤って登録解除したか?
SMS の履歴を開き、(DISABLE action_group_short_name 応答を使用して) この特定のアクション グループからの SMS 配信、または (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 応答のタイムアウト期間は 10 秒です。 HTTP エンドポイントが応答しないときや次の HTTP 状態コードが返されるとき、Webhook 呼び出しは最大 2 回再試行されます。
4084295035041 つの再試行が 10 秒後に行われ、もう 1 回は 100 秒後に再試行されます。 2 回目の再試行が失敗した場合、エンドポイントは 15 分間、どのアクション グループでも呼び出されません。
アクションまたは通知が複数回発生した
アラートの通知 (メールや SMS など) を 2 回以上受信した場合や、アラートのアクション (Webhook または Azure 関数など) が複数回トリガーされた場合は、次の手順に従います。
本当に同じアラートか?
複数の同じようなアラートがほぼ同時に発生する場合があります。 そのため、同じアラートによってアクションが何回もトリガーされたように見えるかもしれません。 たとえば、イベント状態フィールドでフィルター処理しないことによって、アクティビティ ログのアラート ルールがイベントの開始時と (成功か失敗かを問わず) 終了時の両方で発動するように構成できます。
これらのアクションまたは通知が異なるアラートからのものかどうか確認するには、アラートのタイムスタンプや、アラート ID またはその関連付け ID など、アラートの詳細を調べます。 または、発生したアラートの一覧をポータルで確認します。 当てはまる場合、アラート ルールのロジックを調整するか、アラートのソースを構成することが必要になります。
複数のアクション グループでアクションが繰り返されるか?
アラートが発生すると、アラートのアクション グループが 1 つ 1 つ、個別に処理されます。 そのため、(メール アドレスなどの) 1 つのアクションが、トリガーされた複数のアクション グループに出現する場合、そのアクションはアクション グループごとに 1 回ずつ呼び出されます。
トリガーされたアクショングループを確認するには、[アラートの履歴] タブを確認します。アラート ルールに定義されているアクション グループと、アラート処理ルールによってアラートに追加されたアクション グループの両方が表示されます:
予期しない内容がアクションまたは通知に含まれている
アラートを受信したが、そのフィールドの一部が欠落しているか正しくないと思われる場合は、次の手順を実行します。
アクションの正しい形式を選択したか?
アクションの種類 (メール、Webhook など) ごとに、2 つの形式があります。既定のレガシ形式と、より新しい共通スキーマ形式です。 アクション グループを作成するときは、アクションごとに必要な形式を指定します。アクション グループ内のアクションごとに形式が異なる場合があります。
たとえば、Webhook アクションの場合は次のようになります。
アクション レベルで指定された形式が想定どおりかどうか確認します。 たとえば、ある形式を想定して (Webhook、関数、ロジック アプリなどの) アラートに応答するコードを開発したが、後からアクションで自分または別の人が別の形式を指定する場合があります。
また、アクティビティ ログ アラート、ログ検索アラート (Application Insights とログ分析の両方)、メトリック アラート、一般的なアラート スキーマ、非推奨のクラシック メトリック アラートのペイロード形式 (JSON) も確認してください。
アクティビティ ログ アラート: アクティビティ ログに情報があるか?
アクティビティ ログ アラートは、Azure アクティビティ ログに書き込まれたイベントに基づくアラートです。イベントの例には、Azure リソースの作成、更新、削除に関するイベント、サービス正常性とリソース正常性のイベント、Azure Advisor や Azure Policy からの情報などがあります。 アクティビティ ログに基づくアラートを受信したが、必要なフィールドの一部が欠落しているか正しくない場合は、まず、アクティビティ ログ自体でイベントを確認してください。 Azure リソースのアクティビティ ログ イベントで探しているフィールドが、そのリソースによって書き込まれなかった場合、それらのフィールドは対応するアラートに含まれません。
アラート処理ルールが想定どおりに動作していません
発生したアラートをポータルで確認できるが、関連するアラート処理ルールが想定どおりに機能しない場合は、次の手順に従います:
アラート処理ルールは有効になっていますか?
[アラート処理ルールの状態] フィールドを確認して、関連するアクションロールが有効になっていることを確認します。 既定では、ポータル ルールの一覧には有効になっているルールのみが表示されますが、すべてのルールを表示するようにフィルターを変更することもできます。
有効になっていない場合、アラート処理ルールを選択して [有効にする] をクリックすると有効化できます。
サービス正常性アラートか?
サービス正常性アラート (monitor service = "Service Health") は、アラート処理ルールの影響を受けません。
アラート処理ルールがアラートに対して動作しましたか?
発生したアラートをポータルでクリックして、アラート処理ルールがアラートを処理したかどうかを確認し、履歴タブを確認します。
すべてのアクション グループを抑制するアラート処理ルールの例を次に示します:
すべてのアクション グループを追加するアラート処理ルールの例を次に示します:
アラート処理ルールのスコープとフィルターは発生したアラートと一致していますか?
アラート処理ルールが発動するはずだが発動しなかった、または発動しないはずだったが発動したと思われる場合は、アラート処理ルールのスコープとフィルターの条件を、発生したアラートのプロパティとよく照合してください。
発生したアラートのアラート ID を調べる方法
(アラートのメール通知が届かなかった場合などに) 発生した特定のアラートに関してケースをオープンするときは、アラート ID を知らせる必要があります。
調べるには、次の手順に従います。
Azure portal で、発生したアラートの一覧に移動し、その特定のアラートを探します。 フィルターを使用すると探しやすくなります。
アラートをクリックすると、アラートの詳細が表示されます。
最初のタブ (概要タブ) のアラート フィールドで、ID が見つかるまで下にスクロールし、ID をコピーします。 このフィールドにある [クリップボードにコピー] ボタンも使用できます。
Azure portal でのアラート処理ルールの作成、更新、削除の問題
アラート処理ルールの作成、更新、または削除中にエラーが発生した場合は、次の手順に従います:
アクセス許可エラーが発生したか?
共同作成者の監視の組み込みロール、またはアラート処理ルールとアラートに関連した特定のアクセス許可のいずれかが必要です。
アラート処理ルールのパラメーターを確認しましたか?
アラート処理ルールのドキュメント、またはアラート処理ルールの PowerShell Set-AzActionRule コマンドを確認してください。
次のステップ
- ログ アラートを使用する場合は、ログ アラートのトラブルシューティングも参照してください。
- Azure portal に戻り、上記のガイダンスに従って問題が解決したかどうかを確認します。