この記事では、Azure Monitor のアラートと通知に関する一般的な問題について説明します。 Azure Monitor のアラートは、監視データで重要な状態が見つかると事前に通知します。
Azure メトリックまたはログ検索のアラートのトラブルシューティングに関する詳細については、次をご覧ください。
トラブルシューティングの前に
アラートは意図したとおりに発生しても、適切な通知が期待したように行われない場合は、最初にアクション グループをテストして、適切に構成されていることを確認してください。
それ以外の場合は、この記事の残りの部分の情報を使って問題のトラブルシューティングを行ってください。
ログ検索アラート ルールの作成に失敗しました
Azure portal で、"ログ検索アラート ルールの作成がエラーで失敗しました - "アラート ルールの作成に失敗しました <Rule Name>。 サーバーに問題が発生しました。数分後にもう一度お試しください。"
これは、ログ アラート ルールのプロパティ内のすべてのデータの合計サイズが 64 KB (または 32 K の文字列文字) を超えた場合に発生する可能性があります。 アラート ルールで大きなクエリが使用されているかどうか、多くのディメンション、アクション グループ、または長い説明が含まれているかどうかを確認します。その合計サイズは 64 KB を超える可能性があります。
予想されるメールが届かなかった
アラートが発生したことは Azure portal で確認できるが、構成したメールを受け取らなかった場合は、次の手順のようにします。
アラート処理ルールによってメールが抑制されたのか?
確認するには、発生したアラートをポータルでクリックし、抑制されたアクション グループの履歴タブを確認します。
アクションの種類は "Email Azure Resource Manager Role" ですか?
このアクションでは、サブスクリプション スコープと種類が ユーザー または グループである 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 など) がある場合、その設定。
アクション グループから誤って登録解除したか?
注
アクション グループの登録を解除すると、配布リストのすべてのメンバーもサブスクライブ解除されます。 配布リストのメール アドレスは引き続き使用できます。 ただし、配布リストのユーザーには、サブスクリプションを解除すると、配布リスト全体のサブスクリプションが解除されることを知らせる必要があります。
この問題を回避するには、アクション グループ内のすべてのユーザーのメール アドレスを個別に追加します。 1 つのアクション グループには、最大 1000 個のメール アドレスを含めることができます。 その後、特定のユーザーが登録を解除する場合は、他のユーザーに影響を与えずに登録を解除できます。 また、登録を解除したユーザーを確認することもできます。
アラート メールには、アクション グループから登録解除するためのリンクが用意されています。 このアクション グループから誤って登録を解除したかどうかを確認するには、次のいずれかを実行します。
ポータルでアクション グループを編集し、[状態] 列を確認します。
![アクション グループの [状態] 列のスクリーンショット。](media/alerts-troubleshoot/action-group-status.png)
メールの中から配信停止確認メールを探してください。
再登録 - 受信した登録解除確認メール内のリンクを使用するか、アクション グループからメール アドレスを削除してから再度そのアドレスを追加します。
1 つのメール アドレスに多数のメールを送信して、サービスの制限を超えているか?
電子メールは、電子メール アドレスごとに 1 時間に 100 通以下にレート制限されています。 このしきい値を超えた場合、それ以上メール通知は送信されません。 自分のメール アドレスが一時的にレート制限されているというメッセージが届いていないか確認します。
レート制限なしで大量の通知を受け取りたい場合は、次のような別のアクションを使うことを検討します。
これらのアクションはいずれもレート制限されません。
![アクション グループの [状態] 列のスクリーンショット。](media/alerts-troubleshoot/action-group-status.png#lightbox)
予期される SMS、音声通話、またはプッシュ通知を受け取らなかった
ポータルで発生したアラートが表示されていても、構成した SMS、音声通話、またはプッシュ通知を受信しなかった場合は、次の手順に従います。
アラート処理ルールによってアクションが抑制されたのか?
確認するには、発生したアラートをポータルでクリックし、抑制されたアクション グループの履歴タブを確認します。
意図しないものだった場合は、アラート処理ルールを変更、無効化、または削除します。
SMS/音声: 電話番号は正しいか?
SMS アクションの国番号または電話番号の入力に誤りがないか確認してください。
SMS/音声: サービスの制限を超えているか?
SMS 通話と音声通話は、電話番号ごとに 5 分ごとに 1 回の通知に 制限されます 。 このしきい値を超えると、通知は破棄されます。
- 音声通話 - 通話履歴を調べて、前の 5 分間に Azure から別の通話があったかどうか確認します。
- SMS - 電話番号がレート制限が適用されているというメッセージがないか SMS の履歴を確認します。
レート制限なしで大量の通知を受け取りたい場合は、次のような別のアクションを使うことを検討します。
これらのアクションはいずれもレート制限されません。
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 が呼び出される 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の場合は、呼び出しを再試行できます。
アクションまたは通知が複数回発生した
警告の通知 (メールや SMS など) を 2 回以上受信した場合や、警告のアクション (Webhook または Azure 関数など) が複数回トリガーされた場合は、以下の手順に従います。
本当に同じアラートか?
複数の同じようなアラートがほぼ同時に発生する場合があります。 そのため、同じアラートによってアクションが何回もトリガーされたように見えるかもしれません。 たとえば、イベント状態フィールドでフィルター処理をしないことによって、アクティビティ ログ警告ルールがイベントの開始時と終了時 (成功か失敗かを問わず) の両方で発動するように構成されている場合があります。 もう 1 つの例は、ディメンションを定義するときにログ検索アラートで、すべてのディメンションの組み合わせを確認します。これは、さまざまな組み合わせを確認しているため、同様のアラートが発生する可能性があるためです。
これらのアクションまたは通知が異なるアラートからのものかどうか確認するには、アラートのタイムスタンプや、アラート ID またはその関連付け ID など、アラートの詳細を調べます。 または、トリガーされたアラートの一覧をポータルで確認します。 当てはまる場合、アラート ルールのロジックを調整するか、アラートのソースを構成することが必要になります。
複数のアクション グループでアクションが繰り返されるか?
アラートが発生すると、アラートのアクション グループが 1 つ 1 つ、個別に処理されます。 そのため、(メール アドレスなどの) 1 つのアクションが、トリガーされた複数のアクション グループに出現する場合、そのアクションはアクション グループごとに 1 回ずつ呼び出されます。
トリガーされたアクショングループを確認するには、[アラートの履歴] タブを確認します。アラート ルールに定義されているアクション グループと、アラート処理ルールによってアラートに追加されたアクション グループの両方が表示されます:
予期しない内容がアクションまたは通知に含まれている
フォールバック メール プロバイダーの使用をトリガーする障害が発生したか?
アクション グループでは、電子メール通知を確実に配信するために 2 つの異なる電子メール プロバイダーを使用しています。 プライマリ メール プロバイダーは回復性が高く、迅速ですが、障害が発生することがあります。 障害が発生した場合は、セカンダリ メール プロバイダーがメール要求を処理します。 セカンダリ プロバイダーはフォールバック ソリューションにすぎません。 プロバイダーの違いにより、セカンダリ プロバイダーから送信されるメールではメール エクスペリエンスが低下する可能性があります。 エクスペリエンスが低下すると、電子メールの書式設定とコンテンツにわずかな相違が生じます。 2 つのシステム間でメール テンプレートが異なるため、2 つのシステム間で同等性を維持することは実現不可能です。
フォールバック ソリューションによって生成される通知には、次の注意が含まれています。
"これは、電子メール エクスペリエンスが低下していることを示すものです。 書式設定がオフになっているか、詳細が見つからない可能性があります。 低下したメール エクスペリエンスの詳細については、こちらを参照してください。"
通知にはこの注意が含まれず、アラートを受け取ったものの、そのフィールドの一部が欠落しているか正しくないと思われる場合は、ペイロードの形式を確認します。 ペイロードは、共通スキーマ形式またはアクティビティログアラート、ログ検索アラート (Application Insights とログ分析の両方)、およびメトリックアラートといった異なるアラート種類間で異なるスキームを意味する非共通形式のいずれかになります。 ペイロードを表示するには、webhook アクションを使用し、IP に送信して結果を確認できます。
警告ルールを構成するときに、どのような形式を使用したか?
アクションの種類 (メール、Webhook など) ごとに、既定のレガシ形式と、共通スキーマ形式の、2 つの形式があります。 アクション グループを作成するときは、アクションの形式を指定します。 アクション グループ内のアクションが異なると、形式が異なる場合があります。
たとえば、Webhook アクションの場合は次のようになります。
アクション レベルで指定された形式が想定どおりかどうか確認します。 たとえば、ある形式を想定して (Webhook、関数、ロジック アプリなどの) 警告に応答するコードを開発したのに、後になってアクション内で自分または別の人が別の形式を指定したという場合があります。
また、 アクティビティ ログ アラート、 ログ検索アラート (Application Insights とログ分析の両方)、 メトリック アラート、 および共通アラート スキーマのペイロード形式 (JSON) を確認します。
検索結果がログ検索アラート通知には含まれない。
ログ検索アラート API バージョン 2021-08-01 以降では、アラート通知ペイロードから検索結果が削除されました。 検索結果は、以前の API バージョン (2018-04-16) で作成された警告ルールでのみ利用できます。 Azure portal で新しい警告ルールを作成すると、新しいバージョンのルールが既定で作成されます。 更新バージョンを使用するための変更と推奨される調整については、「ログ アラート ルールの作成エクスペリエンスの変更」に従ってください。
解決されたログ検索アラート通知で MetricValue フィールドに "null" が含まれる。
これは仕様です。 ステートフル ログ検索アラートでは、値ベースではなく、時間ベースの解決ロジックが使われます。 Azure Monitor は、アラートが解決した原因が値ではなく、経過時間であるため、null メトリック値を送信しています。
ディメンション リストが空であるか、アラート タイトルにディメンション名が含まれていない
クエリが行を返さない場合、リソース ID フィールド (ディメンションフィールドとタイトル フィールドを設定するための基礎) は空です。 たとえば、結果を返さないログ検索アラート ルールがある場合、しきい値が 0 の場合、アラートは想定どおりに起動しますが、ディメンション リストが空であるか、アラート タイトルにディメンション名が含まれません。
アクティビティ ログ アラートに情報が含まれない
アクティビティ ログ アラートは、Azure アクティビティ ログに書き込まれたイベントに基づくアラートです。イベントの例には、Azure リソースの作成、更新、削除に関するイベント、サービス正常性とリソース正常性のイベント、Azure Advisor や Azure Policy からの情報などがあります。 アクティビティ ログに基づく警告を受信したが、必要なフィールドの一部が欠落しているか正しくない場合は、まず、アクティビティ ログ自体の中でイベントを確認します。 Azure リソースがアクティビティ ログ イベントで探しているフィールドを書き込んでいない場合、それらのフィールドは対応するアラートに含まれません。
メール、SMS、またはプッシュ通知からのカスタム プロパティがありません。
カスタム プロパティは、webhook、Azure Functions、Azure Logic Apps などのアクションのペイロードにのみ渡されます。 カスタム プロパティは通知 (電子メール/SMS/プッシュ) には含まれません。
警告処理ルールが期待どおりに動作しない
アラートが発生したことはポータルで確認できるが、関連する警告処理ルールが想定どおりに機能しない場合は、次の手順のようにします。
アラート処理ルールは有効になっていますか?
[アラート処理ルールの状態] フィールドを確認して、関連するアクションロールが有効になっていることを確認します。 既定では、ポータルには有効になっている警告ルールのみが表示されますが、すべてのルールを表示するようにフィルターを変更できます。
有効になっていない場合は、警告処理ルールを選んで [有効にする] をクリックすると有効にできます。
サービス正常性アラートか?
サービス正常性アラートは、警告処理ルールの影響を受けません。 そのため、サービス正常性アラートを含むスコープに対して警告処理ルールが構成されている場合、サービス正常性アラートがスコープ内にあっても、警告処理ルールはそれらに影響しません。
警告処理ルールがアラートを処理したか?
発生したアラートをポータルで選び、[履歴] タブを見て、警告処理ルールが処理されたかどうかを確認します。
すべてのアクション グループを抑制する警告処理ルールの例を次に示します。
別のアクション グループを追加する警告処理ルールの例を次に示します。
警告処理ルールのスコープとフィルターは発生したアラートと一致しているか?
警告処理ルールが発動すべきなのに発動しなかった、または発動すべきでないのに発動したと思われる場合は、警告処理ルールのスコープとフィルターの条件を注意深く調べて、発生したアラートのプロパティと比較します。
Azure アラートの場合:
スコープは、アラート ルールが適用されるリソースの範囲を定義します。 これは、単一のリソース、リソース グループ、またはサブスクリプション全体であってもかまいません。 スコープによって、アラート ルールの評価に含まれるリソースが決まります。
ターゲット リソースは、アラートをトリガーした特定のリソースを参照します。 これは、個々の仮想マシン、データベース、またはその他の Azure リソースです。 アラートがトリガーされるのは、この特定のリソースで条件が満たされたことが原因です。
たとえば、複数の仮想マシンを含むスコープを持つアラート ルールがある場合、アラートはそれらのすべての仮想マシンを監視します。 いずれかのユーザーがアラートの条件を満たしている場合は、アラートがトリガーされます。 ただし、ターゲット リソースは、アラートが発生する原因となった特定の仮想マシンです。 たとえば、ログ検索アラートでは、アラートのスコープが Log Analytics ワークスペースで、 _ResourceId 列が選択されている場合、ターゲット リソースはリソース ID の値を取得し、最初の意図とは異なるリソースでアラートがトリガーされます。
要約すると、ターゲット リソースは監視対象の個々のリソースですが、スコープによって、アラート ルールが適用されるより広範なリソース セットが定義されます。
Azure portal での警告処理ルールの作成、更新、削除の問題
アラート処理ルールの作成、更新、または削除中にエラーが発生した場合は、次の手順に従います:
アクセス許可を確認します。
共同作成者の監視の組み込みロール、または警告処理ルールとアラートに関連した特定のアクセス許可のいずれかが必要です。
警告処理ルールのパラメーターを確認します。
警告処理ルールのドキュメント、または警告処理ルールの PowerShell Set-AzAlertProcessingRule コマンドを確認します。