Azure Monitor アラートの種類

この記事では、作成できる Azure Monitor アラートの種類と、各種類のアラートを使用するタイミングについて説明します。

以下の 4 種類のアラートがあります。

適切なアラートの選択

この表は、各種類のアラートを使用するタイミングを判断するのに役立ちます。 価格の詳細については、価格のページを参照してください。

アラートの種類 使用するタイミング 料金情報
メトリック アラート メトリック アラートは、操作がほとんどまたはまったく必要ないデータに関するアラートを受け取る場合に便利です。 事前に計算されたメトリック データがシステムに既に保存されているため、メトリック アラートはログ アラートよりもコストが低くなります。 監視するデータがメトリック データにある場合は、メトリック アラートを使用することをお勧めします。 各メトリック アラート ルールは、監視される時系列の数に基づいて課金されます。
ログ アラート ログ アラートを使用すると、データに対して高度なロジック操作を実行できます。 監視するデータがログで使用にある場合、または高度なロジックが必要な場合は、ログ アラートを使用したデータ操作に KQL の堅牢な機能を使用できます。 ログ アラートは、メトリック アラートよりもコストが高くなります。 各ログ アラート ルールは、ログ クエリが評価される間隔に基づいて課金されます (クエリ評価の頻度が高いほどコストが高くなります)。 さらに、大規模な監視用に構成されたログ アラートの場合、コストはクエリの結果のディメンションによって作成された時系列の数にも依存します。
アクティビティ ログ アラート アクティビティ ログでは、リソースで発生したすべてのアクションの監査が提供されます。 リソースに対して特定のイベント (再起動、シャットダウン、リソースの作成や削除など) が発生したときにアラートを受け取るには、アクティビティ ログ アラートを使用します。 詳細については、 価格に関するページを参照してください。

メトリック アラート

メトリック アラート ルールでは、リソース メトリックの条件を定期的に評価することで、リソースが監視されます。 条件が満たされると、アラートが発生します。 メトリック時系列は、一定期間にキャプチャされた一連のメトリック値です。

次のメトリックを使用してルールを作成できます。

メトリック アラート ルールには、次の機能が含まれます。

メトリック アラート ルールのターゲットは次のとおりです。

  • VM などの 1 つのリソース。 サポートされているリソースの種類については、この記事を参照してください。
  • リソース グループなど、同じ Azure リージョン内の同じ種類の複数のリソース

複数の条件

1 つのリソースに対してアラート ルールを作成するときに、複数の条件を適用できます。 たとえば、Azure 仮想マシンを監視するアラート ルールを作成して、"CPU の割合が 90% を超えている" かつ "キューの長さが 300 項目を超えている" の両方が成立した場合にアラートを生成することができます。 アラート ルールに複数の条件がある場合、アラート ルール内のすべての条件が true であればアラートが発生し、3 回連続したチェックで少なくとも 1 つの条件が満たされなかった場合に解決されます。

ディメンションを使用してターゲットを絞り込む

ディメンションは、メトリック値に関する追加データを含む、名前と値のペアです。 ディメンションを使用すると、すべてのディメンション値の集計を監視する代わりに、メトリックをフィルター処理し、特定の時系列を監視することができます。 たとえば、ストレージ アカウントのトランザクション メトリックには、各トランザクションによって呼び出される API の名前 (GetBlob、DeleteBlob、PutPage など) を含む API 名ディメンションがある場合があります。 任意の API 名 (集計されたデータ) に多数のトランザクションがある場合にアラートを生成するか、ディメンションを使用して特定の API 名に対してトランザクション数が多い場合にのみアラートを生成するように選択できます。 複数のディメンションを使用する場合は、メトリック アラート ルールで、メトリックのさまざまなディメンション内の複数のディメンション値を監視できます。 すべてのディメンション値の組み合わせが、アラート ルールによって個別に監視されます。 メトリック アラート ルールでディメンションを使用する方法の詳細については、この記事を参照してください。

ディメンションによる分割を使用してリソース中心型アラートを作成する

複数の Azure リソースで同じ条件を監視するには、ディメンションによる分割を使用できます。 ディメンションで分割すると、サブスクリプションまたはリソース グループに対して大規模なリソース中心型アラートを作成できます。 組み合わせをグループ化することで、アラートが別々のアラートに分割されます。 Azure リソース ID 列で分割すると、指定したリソースがアラート ターゲットになります。

また、スコープ内の複数のリソースに適用される条件が必要な場合は、分割しないことも可能です。 たとえば、リソース グループ スコープ内の少なくとも 5 台のマシンで CPU 使用率が 80% を超えたらアラートを生成する場合などです。

複数のリソースを監視する

同じ Azure リージョンに存在するリソースについて、同じ種類の複数のリソースに同じメトリック アラート ルールを適用することで、大規模な監視が可能になります。 監視対象リソースごとに個別の通知が送信されます。

次の Azure クラウド内のこれらのサービスに対するプラットフォーム メトリックがサポートされています。

サービス グローバル Azure Government 中国
仮想マシン* はい はい はい
SQL Server データベース はい はい はい
SQL Server エラスティック プール はい はい はい
NetApp ファイル容量プール はい はい はい
NetApp ファイル ボリューム はい はい はい
キー コンテナー はい はい はい
Azure Cache for Redis はい はい はい
Azure Stack Edge デバイス はい はい はい
Recovery Services コンテナー はい いいえ いいえ

注意

マルチリソース メトリック アラートは、次のシナリオではサポートされていません。

  • 仮想マシンのゲスト メトリックに関するアラート
  • 仮想マシンのネットワーク メトリック (受信ネットワーク合計、送信ネットワーク合計、受信フロー数、送信フロー数、受信フローの最大作成速度、送信フローの最大作成速度) に関するアラート。

1 つのメトリック警告ルールで監視の範囲を指定するには、次の 3 つの方法があります。 たとえば、仮想マシンではスコープを次のように指定できます。

  • サブスクリプション内の (1 つの Azure リージョン内の) 仮想マシンのリスト
  • サブスクリプション内の 1 つまたは複数のリソース グループ内の (1 つの Azure リージョン内の) すべての仮想マシン
  • 1 つのサブスクリプション内の (1 つの Azure リージョン内の) すべての仮想マシン

動的しきい値

動的しきい値では、高度な機械学習 (ML) を使用して次のことが行われます。

  • メトリックの履歴の動作を学習する
  • パターンを特定し、時間単位、日単位、週単位のパターンなど、時間の経過に伴うメトリックの変化に適応する
  • サービスの問題の可能性を示す異常を認識する
  • メトリックに最適なしきい値を計算する

機械学習により、新しいデータを継続的に使用して詳細を学習することで、しきい値がより正確になります。 システムは、時間の経過に伴うメトリックの動作と、そのパターンからの偏差に基づくアラートに適応するため、各メトリックの "適切な" しきい値を知る必要はありません。

動的しきい値は、次の場合に役立ちます。

  • 1 つのアラート ルールを使用して、数百のメトリック シリーズに対してスケーラブルなアラートを作成する。 アラート ルールが少ないほど、アラート ルールの作成と管理に費やす時間が短縮されます。
  • 構成するしきい値を認識せずにルールを作成する。
  • メトリックに関する広範なドメインの知識なしに、大まかな概念を使用してメトリック アラートを構成する。
  • 予期されるパターンを含まない、ノイズの多い (低精度) しきい値またはワイドな (低再現率) しきい値を抑制する。
  • ノイズの多いメトリック (コンピューターの CPU やメモリなど)、および分散度が低いメトリック (可用性やエラー率など) を処理する。

メトリック アラート ルールで動的しきい値を使用する方法の詳細については、この記事を参照してください。

ログ アラート

ログ アラート ルールでは、Log Analytics クエリを使用してリソースを監視し、設定された頻度でリソース ログを評価します。 条件が満たされると、アラートが発生します。 Log Analytics クエリを使用できるため、ログ アラートを使用すると、データに対して高度なロジック操作を実行したり、ログ データのデータ操作に KQL の堅牢な機能を使用したりできます。

ログ アラート ルールのターゲットは次のとおりです。

  • VM などの 1 つのリソース。
  • リソース グループなど、同じ Azure リージョン内の同じ種類の複数のリソース。 これは現在、選択したリソースの種類で使用できます。
  • クロスリソース クエリを使用する複数のリソース。

ログ アラートでは、さまざまな監視シナリオで使用できる、次の異なる 2 つを測定できます。

  • テーブル行: 返される行の数を使用して、Windows イベント ログ、Syslog、アプリケーション例外などのイベントを処理できます。
  • 数値列の計算: 任意の数値列に基づく計算を使用して、任意の数のリソースを含めることができます。 (たとえば、CPU 使用率など)。

ログ アラートがステートフルかステートレスかを構成できます (現在プレビュー段階)。

注意

ログ アラートは、ログ内の不足データを検出しようとする場合ではなく、ログ内の特定のデータを検出しようとする場合に最適に機能します。 ログは半構造化データであるため、VM ハートビートなどの情報に関するメトリック データよりも本質的に高い潜在性を示します。 ログ内の不足データを検出しようとした場合の誤発生を回避するには、メトリック アラートの使用を検討してください。 ログのメトリック アラートを使用して、ログからメトリック ストアにデータを送信できます。

ログ アラート ルールのディメンション

ログ アラート ルールの作成時にディメンションを使用すると、1 つのルールでリソースの複数のインスタンスの値を監視できます。 たとえば、Web サイトまたはアプリを実行している複数のインスタンスで CPU 使用率を監視できます。 各インスタンスは個別に監視され、インスタンスごとに通知が送信されます。

ログ アラート ルールのディメンションによる分割

複数の Azure リソースで同じ条件を監視するには、ディメンションによる分割を使用できます。 ディメンションで分割すると、サブスクリプションまたはリソース グループに対して大規模なリソース中心型アラートを作成できます。 数値列または文字列列を使用して組み合わせをグループ化することで、アラートが別々のアラートに分割されます。 Azure リソース ID 列で分割すると、指定したリソースがアラート ターゲットになります。 また、スコープ内の複数のリソースに適用される条件が必要な場合は、分割しないことも可能です。 たとえば、リソース グループ スコープ内の少なくとも 5 台のマシンで CPU 使用率が 80% を超えたらアラートを生成する場合などです。

API を使用する

ScheduledQueryRules API を使用して、ワークスペース内の新しいルールを管理します。

注意

Log Analytics のログ アラートは、従来の Log Analytics Alert API を使用して管理されていました。 現在の ScheduledQueryRules API への切り替えの詳細について確認してください。

Azure の請求書のログ アラート

ログ アラートは、リソース プロバイダー microsoft.insights/scheduledqueryrules の下に次のように一覧表示されます。

  • Application Insights のログ アラートが正しいリソース名でリソース グループとアラート プロパティと共に表示されます。
  • scheduledQueryRules API を使用して作成されている場合、Log Analytics のログ アラートは、正しいリソース名でリソース グループとアラート プロパティと共に表示されます。
  • 従来の Log Analytics API から作成されたログ アラートは、Azure リソースで追跡されず、一意のリソース名は適用されません。 これらのアラートは、非表示リソースとして microsoft.insights/scheduledqueryrules でまだ作成され、<WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId> というリソース名前付け構造が使用されます。 従来の API のログ アラートは、上記の非表示リソース名で、リソース グループとアラート プロパティと共に表示されます。

注意

サポートされていないリソース文字 (<、>、%、&、 、?、/ など) は、非表示リソース名では _ に置き換えられ、これは課金情報にも反映されます。

アクティビティ ログ アラート

アクティビティ ログ アラートでは、定義された条件に一致する新しいアクティビティ ログ イベントをアクティビティ ログで確認することで、リソースが監視されます。

アクティビティ ログ アラートは、次の種類のシナリオに使用できます。

  • 特定のリソース グループまたはサブスクリプション内のリソースに対して特定の操作が発生した場合。 たとえば、次の場合に通知を受け取ることができます。
    • 運用リソース グループ内のすべての仮想マシンが削除された場合。
    • サブスクリプション内のユーザーに新しい役割が割り当てられた場合。
  • サービス正常性イベントが発生した場合。 サービス正常性イベントには、サブスクリプション内のリソースに適用されるインシデント イベントとメンテナンス イベントの通知が含まれます。

次の項目に関するアクティビティ ログ アラートを作成できます。

  • アラート イベント以外の任意のアクティビティ ログ イベント カテゴリ
  • JSON オブジェクトの最上位プロパティの任意のアクティビティ ログ イベント。

アクティビティ ログ アラートは Azure リソースであるため、Azure Resource Manager テンプレートを使用して作成できます。 これらは、Azure Portal で作成、更新、削除することもできます。

アクティビティ ログ アラートでは、アラートが作成されたサブスクリプション内のイベントのみが監視されます。

スマート検出アラート

プロジェクト用に Application Insights を設定した後、アプリで特定の最少限のデータが生成されると、スマート検出では 24 時間かけてアプリの通常の動作を学習します。 アプリのパフォーマンスには、一般的な動作パターンがあります。 他よりもエラーが発生しやすい要求または依存関係があります。負荷が増えると、全体的なエラー率が上がります。 スマート検出は機械学習を使用し、これらの異常を検出します。 スマート検出は、アプリから受け取ったデータ (特に失敗率) を監視します。 Application Insights では、Web アプリで要求の失敗率が異常に増加すると、ほぼリアルタイムで自動的にユーザーにアラートを送信します。

Web アプリから Application Insights にデータが送られると、スマート検出は現在の動作と過去数日間に見られたパターンを比較します。 以前のパフォーマンスと比べてエラー率の異常な上昇が検出された場合に、分析がトリガーされます。 アラートの詳細には、問題のトリアージと診断に役立つよう、失敗の特性および関連するアプリケーション データの分析が表示されます。 また、より詳しい診断を行うために、Application Insights ポータルへのリンクも含まれています。 この機能は、機械学習アルゴリズムを使用して通常のエラー率を予測するため、セットアップや構成は不要です。

メトリック アラートでは問題のある可能性が示されますが、スマート検出では診断作業が自動的に開始され、実行する必要のある分析の多くがユーザーに代わって実行されます。 結果はわかりやすくまとめられるので、問題の原因をすぐに把握できます。

スマート検出は、クラウドまたは独自サーバーでホストされ、アプリケーションの要求または依存データを生成するあらゆる Web アプリで利用できます。

次のステップ