Azure Monitor メトリック アラートのトラブルシューティング
この記事では、Azure Monitor のメトリック アラートに関する一般的な質問とそのトラブルシューティングの方法について説明します。
Azure Monitor のアラートは、監視データで重要な状態が見つかると事前に通知します。 管理者は、その通知を見て、システムのユーザーが問題に気付く前に問題を識別して対処できます。 アラートの詳細については、「Microsoft Azure のアラートの概要」を参照してください。
メトリック警告が発生するはずなのに発生しなかった
メトリック警告が発生するはずなのに発生せず、Azure portal に一覧表示されていない場合は、次の手順を試してください。
次のメトリック警告ルールの構成を確認します。
[集計の種類] と [集約粒度 (期間)] が、想定どおりに構成されていることを確認します。 [集計の種類] によって、メトリック値の集計方法が決まります。 詳細については、「Azure Monitor メトリックによる集計と表示の説明」をご覧ください。 [集約粒度 (期間)] により、アラート ルールが実行されるたびに評価でメトリック値をどこまで遡って集計するかが制御されます。
[しきい値] または [感度] が、想定どおりに構成されていることを確認します。
動的しきい値を使用するアラート ルールについては、詳細設定が構成されているかどうかを確認します。 [違反の数] によってアラートがフィルター処理される可能性があり、[次よりも前のデータを無視します] が、しきい値の計算方法に影響する場合があります。
Note
動的しきい値がアクティブになるためには、少なくとも 3 日の期間と、30 個のメトリック サンプルが必要です。
警告は発生したが、通知が送信されなかったかどうかを確認します。
発生した警告のリストを調べて、発生した警告が見つかるかどうかを確認します。 リストにアラートがあっても、そのアクションまたは通知の一部に問題がある場合は、「Azure Monitor のアラートの問題のトラブルシューティング」を参照してください。
警告が既にアクティブであるかどうかを確認します。
警告が発生すると予想されるメトリックの時系列で、警告が既に発生しているかどうかを確認します。 メトリック アラートはステートフルです。つまり、特定のメトリックの時系列でアラートが発生すると、問題が検出されなくなるまで、その時系列ではそれ以上のアラートは発生しません。 このような設計により、ノイズが減少します。 連続する 3 回の評価においてアラート条件が満たされない場合、アラートは自動的に解決されます。
使用されているディメンションを確認します。
1 つのメトリックに対してディメンション値を複数選択した場合、警告ルールでは、(ディメンション値の組み合わせによって定義される) メトリックの時系列ごとに、しきい値の違反が監視されます。 ディメンションが選択されていない集計メトリック時系列も監視するには、ディメンションを選択せずに、メトリックに対して別のアラート ルールを構成します。
集計と時間の細分性を確認します。
メトリック グラフを使用している場合は、次のことを確認します。
- メトリック グラフで選択されている [集計] が、アラート ルールの [集計の種類] と同じである。
- 選択されている[時間粒度] が、アラート ルールの [集約粒度 (期間)] と同じであり、[自動] に設定されていない。
警告ルールに時系列の最初の評価期間がないかどうかを確認します。
以下のような場合に、[評価の頻度] よりも大きい [集計の細分性 (期間)] を選択するよう徹底することで、追加された時系列の最初の評価を見落とす可能性を減らすことができます。
- 複数のディメンションを監視するメトリック警告ルールに新しいディメンション値の組み合わせが追加されたとき
- 複数のリソースを監視するメトリック警告ルールの範囲に新しいリソースが範囲に追加されたとき
- 連続して生成されないメトリック (スパース メトリック) を監視するメトリック警告ルールに関してメトリックが生成されていない 24 時間以上の期間の後にメトリックが生成されたとき
条件が満たされるたびにメトリック警告がトリガーされるわけではない
メトリック アラートは既定ではステートフルであるため、特定の時系列に対して既にアラートが発生している場合、その他のアラートは発生しません。 特定のメトリック警告ルールをステートレスにして、警告の条件が満たされているすべての評価について警告を受け取る場合は、これらのいずれかのオプションを使用します。
たとえば、Azure Resource Manager、PowerShell、REST、または Azure CLI を使用して、プログラムでアラート ルールを作成する場合は、
autoMitigateプロパティをFalseに設定します。Azure portal を使用して警告ルールを作成する場合は、[警告ルールの詳細] セクションで [警告を自動的に解決する] オプションをオフにします。 ステートレス メトリック アラートの通知の頻度は、アラート ルールで構成された頻度によって異なります。
アラートの頻度が 5 分未満: 条件が継続して満たされている間、1 分から 6 分の間に通知が 1 回送信されます。
アラートの頻度が 5 分を超える: 条件が継続して満たされている間、構成された頻度とその頻度の 2 倍の間で通知が 1 回送信されます。 たとえば、頻度が 15 分のアラート ルールの場合、通知は 15 分から 30 分の間のどこかで送信されます。
Note
メトリック アラート ルールをステートレスにすると、発生したアラートが解決されなくなります。 そのため、条件が満たされなくなった後も、発生したアラートは 30 日の保有期間まで発生状態のままになります。
しきい値が動的な警告ルールの発動頻度が少なすぎるメトリック警告ルール
感度を高く構成していたとしても、動的しきい値を使用するアラート ルールの発動頻度が少なく、感度の高さが十分でないことがあります。 これは、メトリックの分布の不規則性が高いときに発生することがあります。 問題を解決するために、次のいずれかの解決策を検討します。
- シナリオに適した補完的なメトリックの監視に移ります (該当する場合)。 たとえば、失敗率ではなく成功率の変化を確認します。
- [集約粒度 (期間)] で別の値を選択してみます。
- 過去 10 日間に、メトリックの動作が大幅に変化したかどうか (停止など) を確認します。 突然変化すると、メトリックに対して計算された上限と下限のしきい値に影響を与え、それらが広がる可能性があります。 しきい値の計算で停止が考慮されなくなるまで数日待ちます。 [詳細設定] の [次よりも前のデータを無視します] オプションを使用するようにアラート ルールを編集することもできます。
- データに週単位の季節性があるが、メトリックに十分な履歴がない場合、計算されたしきい値によって、上限と下限が広がる可能性があります。 たとえば、この計算では平日と週末を同じ方法で扱い、データに適合しないことがある広い境界を作成する可能性があります。 この問題は、十分なメトリック履歴が使用可能になると自動的に解決されるはずです。 その後、適切な季節性が検出され、計算されたしきい値が適宜更新されます。
メトリック アラートが発生するはずがないときに発生した
メトリック警告が発生してはならないことが確実な場合に発生した場合は、次の手順が問題の解決に役立つことがあります。
発生したアラートのリストを調べて、発生したアラートを見つけます。 詳細を表示するアラートを選択します。 [このアラートが発生した理由] で提供される情報を調べて、アラートがトリガーされた時点でのメトリック グラフ、[メトリック値]、および [しきい値] を確認します。
Note
動的しきい値を使用しており、しきい値が正しくないと思われる場合は、しかめっ面アイコンを使って、フィードバックをお寄せください。 このフィードバックは、機械学習のアルゴリズムの研究に影響を与え、将来の検出の改善に役立ちます。
1 つのメトリックに複数のディメンション値を選択した場合は、(ディメンション値の組み合わせによって定義される) メトリック時系列の ''いずれか'' がしきい値を超えるとアラートがトリガーされます。 メトリック警告でのディメンションの使用の詳細については、「ディメンションを使用してターゲットを絞り込む」を参照してください。
アラート ルールの構成を調べて、適切に構成されていることを確認します。
- [集計の種類]、[集約粒度 (期間)]、および [しきい値] または [感度] が、想定どおりに構成されていることを確認します。
- 動的しきい値が使用されているアラート ルールの場合は、詳細設定が構成されているかどうかを確認します。[違反の数] でアラートがフィルター処理され、[次よりも前のデータを無視します] がしきい値の計算方法に影響することがあります。
Note
動的しきい値がアクティブになるようにするには、少なくとも 3 日の期間と、30 個のメトリック サンプルが必要です。
メトリック グラフを使用している場合は、次のことを確認します。
- メトリック グラフで選択されている [集計] が、アラート ルールの [集計の種類] と同じである。
- 選択されている [時間粒度] が、アラート ルールの [集約粒度 (期間)] と同じであり、[自動] に設定されていない。
解決されていない同じ条件を監視するアラートが既にあるのに、アラートが生成される場合は、自動的にアラートを解決しないようにアラート ルールが構成されているかどうかを確認します。 つまり、警告ルールがステートレスになり、発生した警告が警告ルールによって自動解決されず、同じ時系列で警告を再度生成する前に、発生した警告が解決されることが要求されません。 自動解決しないようにアラート ルールが構成されているかどうかを確認するには、次のようにします。
- Azure portal でアラート ルールを編集します。 [アラート ルールの詳細] セクションの [アラートを自動的に解決する] チェック ボックスがオフになっているかどうかを確認します。
- アラート ルール定義のデプロイまたは取得に使用されるスクリプトを確認します。
autoMitigateプロパティがfalseに設定されているかどうかを確認します。
しきい値が動的な警告ルールが発動回数が多すぎるか邪魔になるメトリック警告ルール
動的しきい値を使用するアラート ルールが発動しすぎて邪魔になるなら、場合によっては、動的しきい値アラート ルールの感度を下げる必要があります。 次のいずれかのオプションを使用します。
- しきい値の感度: 逸脱に対する耐性を上げるには、感度を [低] に設定します。
- 違反の数 ([詳細設定] の下): 一定の時間内に逸脱が複数回発生した場合にのみトリガーするアラート ルールを構成します。 この設定により、ルールは一時的な逸脱の影響を受けにくくなります。
しきい値が動的なメトリック警告ルールに、予期される値の範囲外の値が表示されている
メトリック値で大きな変動が示されている場合、動的しきい値によって作成されるメトリック値を中心としたモデルが大きくなり、その結果として境界が予想よりも低くなったり高くなったりする可能性があります。 このシナリオは次の場合に発生することがあります。
感度が低く設定されている。
メトリックで、変動幅が大きい不規則な動作が示されている (データにスパイクやディップとして示されている)。
より高い感度を選択するか、[遡って確認する期間] でより大きな値を選択して、モデルの感度を低くすることを検討してください。 [次よりも前のデータを無視します] オプションを使って、モデルを作成するために使用される履歴データから最近の不規則性を除外することもできます。
メトリック警告ルールの構成の問題
アラート対象のメトリックが見つからない
特定のメトリックに対してアラートを生成したいが、アラート ルールの作成時に表示できない場合は、次のことを確認してください。
- リソースのメトリックが表示されない場合は、リソースの種類がメトリックのアラートでサポートされているかどうかを確認します。
- リソースの一部のメトリックは表示されるものの、特定のメトリックが見つからない場合は、そのメトリックが使用可能かどうかを確認してください。 使用可能な場合は、メトリックの説明を参照して、リソースの特定のバージョンやエディションでのみ使用可能になっていないかどうかを確認してください。
- そのリソースにメトリックを使用できない場合は、リソース ログで使用可能であり、ログ アラートを使って監視できる可能性があります。 詳細については、Azure リソースからリソース ログを収集して分析する方法に関するページを参照してください。
アラート対象のメトリックが見つからない: 仮想マシンのゲスト メトリック
メモリやディスク領域など、仮想マシンのゲスト オペレーティング システム メトリックについてアラートを作成するには、このデータを Azure Monitor メトリックに収集するために必要なエージェントがインストールされていることを確めます。
仮想マシンのゲスト オペレーティング システムからデータを収集する方法の詳細については、こちらの Web サイトを参照してください。
Note
Log Analytics ワークスペースに送信されるようにゲスト メトリックを構成した場合、これらのメトリックは Log Analytics ワークスペース リソースの下に表示され、それらを監視するアラート ルールを作成した後でデータ ''のみ'' の表示が開始されます。 これを行うには、ログのメトリック アラートを構成する手順に従います。
現在、1 つのアラート ルールを使用して複数の仮想マシンのゲスト メトリックを監視することは、メトリック アラートではサポートされていません。 しかし、ログ アラート ルールを使用できます。 これを行うには、ゲスト メトリックが Log Analytics ワークスペースに収集されていることを確認し、ワークスペースでログ アラート ルールを作成します。
アラート対象のメトリック ディメンションが見つからない
メトリックの特定のディメンション値に対してアラートを生成したいが、これらの値が見つからない場合:
- ディメンション値がディメンション値一覧に表示されるまでに数分かかる場合があります。
- 表示されるディメンション値は、過去 1 日間に収集されたメトリック データに基づいています。
- ディメンション値がまだ生成されていない場合、または表示されない場合は、[カスタム値を追加] オプションを使用してカスタム ディメンション値を追加できます。
- ディメンションのすべての可能な値に関してアラートを生成し、将来の値も含める場合は、[現在および将来のすべての値] オプションを選びます。
- Application Insights リソースのカスタム メトリック ディメンションは、既定ではオフになっています。 これらのカスタム メトリックのディメンションのコレクションを有効にする場合は、「Application Insights のログベースのメトリックと事前に集計されたメトリック」を参照してください。
まだ生成されていないカスタム メトリックに対して警告ルールを構成する必要があります
メトリック アラート ルールを作成する場合、メトリック名は Metric Definitions API に対して検証され、それが存在することが確認されます。 場合によっては、カスタム メトリックに対して、それが生成される前にアラート ルールを作成する必要があります。 たとえば、Resource Manager テンプレートを使用して、カスタム メトリックを生成する Application Insights リソースをそのメトリックを監視するアラート ルールと共に作成する場合です。
カスタム メトリックの定義を検証しようとしたときにデプロイ エラーが発生しないようにするには、アラート ルールの criteria セクションで skipMetricValidation パラメーターを使用します。 このパラメーターを使用すると、メトリックの検証はスキップされます。 Resource Manager テンプレートでこのパラメーターを使用する方法については、次の例を参照してください。 詳細については、メトリック警告ルールを作成するための Resource Manager テンプレートの完全なサンプルに関する記事を参照してください。
"criteria": {
"odata.type": "Microsoft.Azure.Monitor.SingleResourceMultipleMetricCriteria",
"allOf": [
{
"name" : "condition1",
"metricName": "myCustomMetric",
"metricNamespace": "myCustomMetricNamespace",
"dimensions":[],
"operator": "GreaterThan",
"threshold" : 10,
"timeAggregation": "Average",
"skipMetricValidation": true
}
]
}
Note
数日間出力されていない既存のカスタム メトリックでアラート ルールを定義するときは、skipMetricValidation パラメーターも使用する必要がある場合があります。
メトリック警告ルールを構成するときの警告とエラー
現在、このメトリック警告では動的しきい値を使用することができません
動的しきい値は、ほとんどのメトリックでサポートされていますが、すべてではありません。 メトリックのリストについては、「動的しきい値でサポートされていないメトリック」を参照してください。
メトリックは、選択した範囲では使用できません。 これは、メトリックが特定のバージョンまたは SKU エラーにのみ適用される場合に発生する可能性があります
「Azure Monitor のサポートされるメトリック」のメトリックの説明を確認して、リソースの特定のバージョンまたはエディションでのみ使用できるかどうか、またはこの特定の種類で使用できるかどうかを確認してください。
たとえば、SQLデータベースリソースまたはストレージファイルサービスでは、特定のバージョンのリソースでのみサポートされる特定のメトリックがあります。
表示できるシグナルはありません。 この警告ルール エラーの範囲を変更してみてください
このエラーは、アラート ルールのスコープに問題があることを示しています。 これは、複数リソース構成をサポートするリソースの種類 (仮想マシンや SQL データベースなど) をスコープとするアラート ルールを編集し、同じ種類の別のリソースを別のリージョンから追加しようとすると発生する可能性があります。 リージョンが異なる同じ種類の複数のリソースに対するアラートは、メトリック アラートではサポートされません。
メトリック警告ルールのサービス制限が小さすぎます
許可されるサブスクリプションあたりのメトリック警告ルール数は、サービス制限の対象になります。
使用中のメトリック警告ルールの数の確認に関するページを参照して、現在使用中のメトリック警告ルールの数を確認します。
サービス制限に達した場合は、次の手順が問題の解決に役立つ場合があります。
- 今後使用されないメトリック アラート ルールを削除または無効にしてみます。
- 複数のリソースを監視するメトリック警告ルールを使用するように切り替えます。 この機能を使用すると、クォータに対してカウントされるアラート ルールを 1 つだけ使用して、1 つのアラート ルールで複数のリソースを監視できます。 この機能とサポートされているリソースの種類の詳細については、メトリック警告を参照してください。
- クォータ制限を引き上げる必要がある場合は、サポート リクエストを開き、次の情報を提供します。
- クォータ制限を引き上げる必要があるサブスクリプション ID。
- クォータを引き上げるリソースの種類。 [メトリック警告] を選択します。
- 要求されるクォータ制限。
次のステップ
警告と通知に関する一般的なトラブルシューティング情報については、「Azure Monitor のアラートの問題のトラブルシューティング」を参照してください。