Azure Monitor の警告とは

警告は、Azure Monitor データがインフラストラクチャまたはアプリケーションに問題がある可能性があることを示しているときに事前に通知することで、ユーザーが問題に気付く前に検出して対処するのに役立ちます。

Azure Monitor データ プラットフォームでは、任意のメトリックまたはログ データ ソースに対してアラートを生成できます。

次の図は警告のしくみを示しています。

Azure Monitor の警告を説明する図。

"警告ルール" では、テレメトリを監視し、指定されたリソースで何かが起こっていることを示すシグナルをキャプチャします。 アラート ルールではシグナルを取り込み、シグナルが条件の基準を満たしているかどうかを確認します。 条件が満たされている場合、アラートがトリガーされ、関連付けられたアクション グループが開始され、アラートの状態が更新されます。

アラート ルールでは、次が結合されます。

  • 監視対象のリソース。
  • リソースからのシグナルまたはテレメトリ。
  • 条件。

複数のリソースを監視している場合、条件はリソースごとに個別に評価されます。 警告はリソースごとに別個に発生します。

警告がトリガーされると、その警告は以下のもので構成されます。

  • 警告処理ルール: これらのルールを使用して、発生した警告に処理を適用できます。 アラート処理ルールでは、発生したアラートを変更します。 警告処理ルールを使用して、アクション グループを追加または抑制したり、フィルターを適用したり、定義済みのスケジュールに従ってルールを処理したりすることができます。
  • アクション グループ: これらのグループは、通知または自動化されたワークフローをトリガーして、警告がトリガーされたことをユーザーに知らせることができます。 アクション グループには次のものが含まれます。
    • メール、SMS、プッシュ通知などの通知方法。
    • Automation の Runbook。
    • Azure Functions。
    • ITSM インシデント。
    • ロジック アプリ。
    • セキュア Webhook。
    • Webhook。
    • イベント ハブ。
  • 警告条件: これらの条件はシステムによって設定されます。 アラートが発生すると、アラートの監視条件が "発生" に設定されます。 警告発生の原因になった状態が解消されると、監視条件は [解決済み] に設定されます。
  • ユーザーの応答: この応答はユーザーによって設定され、ユーザーが変更するまで変わりません。

過去 30 日間に生成されたすべての Azure リソースのすべてのアラート インスタンスは、Azure portal の [アラート] ページで確認できます。

アラートの種類

次の表では、各アラートの種類の簡単な説明を示します。 各警告の種類と、ニーズに最も適した警告の種類を選択する方法の詳細については、「Azure Monitor アラートの種類」を参照してください。

アラートの種類 [説明]
メトリック アラート メトリック アラートでは、リソース メトリックを定期的に評価します。 メトリックはプラットフォーム メトリック、カスタム メトリック、メトリックに変換された Azure Monitor からのログまたは Application Insights メトリックにすることができます。 メトリック警告では、複数の条件と動的しきい値を適用することもできます。
ログ アラート ログ アラートでは、ユーザーは Log Analytics クエリを使用して、定義済みの頻度でリソース ログを評価できます。
アクティビティ ログ アラート アクティビティ ログ アラートは、定義された条件と一致する新しいアクティビティ ログ イベントが発生したときにトリガーされます。 Resource Health アラートと Service Health アラートは、サービスとリソースの正常性を報告するアクティビティ ログ アラートです。
スマート検出アラート Application Insights リソースでのスマート検出により、Web アプリケーションの潜在的なパフォーマンスの問題や失敗の異常に関する警告を自動的に受け取ることができます。 Application Insights リソースのスマート検出を移行して、さまざまなスマート検出モジュールのアラート ルールを作成できます。
Prometheus アラート (プレビュー) Prometheus 警告は、Azure Kubernetes Service (AKS) を含む Kubernetes クラスターのパフォーマンスと正常性に関する警告に使用されます。 警告ルールは、オープンソース クエリ言語である PromQL に基づいています。

選択されたリソースに対してアラート ルールを定義していない場合は、Azure portal で推奨される既定のアラート ルールを有効にすることができます。

注意

アラート ルールの推奨機能は、現在プレビュー段階であり、以下でのみ有効になっています。

  • 仮想マシン
  • AKS リソース
  • Log Analytics ワークスペース

Azure の警告のロールベースのアクセス制御

アクセス許可があるリソースのアラートに対してのみ、アクセス、作成、または管理を行うことができます。

アラート ルールを作成するには以下が必要です。

  • アラート ルールのターゲット リソースに対する読み取りアクセス許可。
  • アラート ルールが作成されるリソース グループに対する書き込みアクセス許可。 Azure portal からアラート ルールを作成する場合は、そのアラート ルールが同じリソース グループ (ターゲット リソースが存在している) に既定で作成されます。
  • 警告ルールに関連付けられているアクション グループに対する読み取りアクセス許可 (該当する場合)。

すべての Azure Resource Manager スコープでサポートされているこれらの組み込みの Azure ロールには、警告情報にアクセスし、警告ルールを作成するための次のアクセス許可があります。

  • 監視共同作成者: 共同作成者は警告を作成し、スコープ内のリソースを使用できます。
  • 監視閲覧者: 閲覧者は警告を表示し、スコープ内のリソースを読み取ることができます。

ターゲット アクション グループまたはルールの場所が 2 つの組み込みロールとは異なるスコープにある場合は、適切なアクセス許可を持つユーザーを作成してください。

警告と状態

ログまたはメトリック アラートがステートフルであるかステートレスであるかを構成できます。 アクティビティ ログ アラートはステートレスです。

  • ステートレス アラートは、前に発生した場合でも、条件が満たされるたびに発生します。

    ステートレス メトリック アラートの通知の頻度は、アラート ルールで構成された頻度によって異なります。

    • 警告の頻度が 5 分未満: 条件が継続して満たされている間、1 分から 6 分の間に通知が 1 回送信されます。
    • アラートの頻度が 5 分を超える: 条件が継続して満たされている間、構成された頻度とその頻度の 2 倍の間で通知が 1 回送信されます。 たとえば、頻度が 15 分の警告ルールの場合、通知は 15 分から 30 分の間のどこかで送信されます。
  • ステートフルな警告は、条件が満たされたときに発生します。 次の表に示すように、条件が解決されるまで、もう一度発生したり、それ以上のアクションがトリガーされたりすることはありません。

    アラートの種類 アラートは次の場合に解決されます
    メトリック アラート 3 回連続するチェックでは、アラート条件が満たされません。
    ログ アラート 指定した時間の範囲に警告の条件が満たされていません。 時間の範囲は、アラートの頻度によって異なります。
    • 1 分: アラート条件が 10 分間満たされていません。
    • 5 から 15 分: 警告の条件が 3 つの頻度の期間にわたって満たされていません。
    • 15 分から 11 時間: 警告の条件が 2 つの頻度の期間にわたって満たされていません。
    • 11 ~ 12 時間: アラート条件が 1 つの頻度の期間に満たされていません。

警告が解決されたと見なされると、警告ルールは Webhook またはメールを使用して解決済みの通知を送信します。 Azure portal のモニターの状態は [解決済み] に設定されます。

価格

価格について詳しくは、「Azure Monitor の価格」を参照してください。

次のステップ