適切な種類のアラート ルールを選ぶ
この記事では、作成できる Azure Monitor アラートの種類について説明します。 これは、各種類のアラートを使用するタイミングを理解するのに役立ちます。 価格の詳細については、価格のページを参照してください。
アラートの種類は次のとおりです。
Azure Monitor アラートの種類
| アラートの種類 | 使用する場合 | 料金情報 |
|---|---|---|
| メトリック アラート | メトリック データは、既に事前に計算されたシステムに格納されます。 メトリック アラートは、操作がほとんどまたはまったく必要ないデータに関するアラートを受け取る場合に便利です。 監視するデータがメトリック データにある場合は、メトリック アラートを使用します。 | 各メトリック アラート ルールは、監視される時系列の数に基づいて課金されます。 |
| ログ検索アラート | ログ検索アラートを使用すると、データに対して高度なロジックの操作を実行できます。 監視するデータがログに含まれるか、高度なロジックが必要な場合は、ログ検索アラートを使用すると、データ操作に Kusto 照会言語 (KQL) の堅牢な機能を使用できます。 | 各ログ検索アラート ルールは、ログ クエリが評価されるサイクル間隔に基づいて課金されます。 クエリ評価の頻度が高いほど、コストが高くなります。 さらに、ディメンションによる分割を使用した大規模な監視用に構成されたログ検索アラートの場合、コストはクエリの結果として得られるディメンションによって作成された時系列の数にも依存します。 |
| アクティビティ ログ アラート | アクティビティ ログでは、リソースで発生したすべてのアクションの監査が提供されます。 リソースに対して特定のイベント (再起動、シャットダウン、リソースの作成や削除など) が発生したときにアラートを受け取るには、アクティビティ ログ アラートを使用します。 Service Health アラートと Resource Health アラートは、サービスまたはリソースのいずれかに問題がある場合にユーザーに通知できます。 | 詳細については、 価格に関するページを参照してください。 |
| Prometheus アラート | Prometheus アラートは、Prometheus 用 Azure Monitor マネージド サービスに保存されている Prometheus メトリックに基づくアラートに使用されます。 警告ルールは、オープンソース クエリ言語である PromQL に基づいています。 | Prometheus アラート ルールは、ルールによって照会されたデータに対してのみ課金されます。 詳細については、 価格に関するページを参照してください。 |
メトリック アラート
メトリック アラート ルールでは、リソース メトリックの条件を定期的に評価することで、リソースが監視されます。 条件が満たされると、アラートが発生します。 メトリック時系列は、一定期間にキャプチャされた一連のメトリック値です。
次のメトリックを使用してルールを作成できます：
- プラットフォームのメトリック
- カスタム メトリック
- Application Insights のカスタム メトリック
- メトリックに変換された、Log Analytics ワークスペースから選択されたログ
メトリック アラート ルールには、次の機能が含まれます。
- アラート ルールでは、1 つのリソースに対して複数の条件を使用できます。
- 複数のメトリック ディメンションを監視することで、粒度を追加できます。
- 機械学習によって駆動される動的しきい値を使用できます。
- メトリック アラートがステートフルかステートレスかを構成できます。 既定では、メトリック アラートはステートフルです。
メトリック アラート ルールのターゲットは次のとおりです。
- 仮想マシン (VM) などの 1 つのリソース。 サポートされるリソースの種類に関しては、Azure Monitor のメトリック アラートでサポートされるリソースを参照してください。
- リソース グループなど、同じ Azure リージョン内の同じ種類の複数のリソース。
メトリック アラート ルールに複数の条件を適用する
1 つのリソースに対してアラート ルールを作成するときに、複数の条件を適用できます。 たとえば、Azure 仮想マシンを監視するアラート ルールを作成して、"CPU の割合が 90% を超えている" かつ "キューの長さが 300 項目を超えている" の両方が成立した場合にアラートを生成することができます。 アラート ルールに複数の条件がある場合、アラート ルール内のすべての条件が true であればアラートが発生し、3 回連続したチェックで少なくとも 1 つの条件が満たされなかった場合に解決されます。
ディメンションを使ってターゲットを絞り込む
メトリック アラート ルールでディメンションを使用する手順については、「1 つのメトリック アラート ルールで複数の時系列を監視する」を参照してください。
ディメンションごとの分割を使って複数のリソースに対する同じ条件を監視する
複数の Azure リソースで同じ条件を監視するには、ディメンションによる分割を使用できます。 ディメンションによる分割を使用すると、サブスクリプションまたはリソース グループに対して大規模なリソース中心型アラートを作成できます。 組み合わせをグループ化することで、アラートが別々のアラートに分割されます。 Azure リソース ID 列で分割すると、指定したリソースがアラート ターゲットになります。
また、スコープ内の複数のリソースに適用される条件が必要な場合は、分割しない決断をすることも可能です。 たとえば、リソース グループ スコープ内の少なくとも 5 台のマシンで CPU 使用率が 80% を超えたらアラートを生成する場合などです。
1 つのアラート ルールで複数のリソースを監視する
同じ Azure リージョンに存在するリソースについて、同じ種類の複数のリソースに同じメトリック アラート ルールを適用することで、大規模な監視が可能になります。 監視対象リソースごとに個別の通知が送信されます。
次の Azure クラウド内のこれらのサービスに対するプラットフォーム メトリックがサポートされています。
| サービス | リソース プロバイダー | グローバル Azure | Government | 中国 |
|---|---|---|---|---|
| 仮想マシン | "Microsoft.Compute/virtualMachines" | はい | イエス | はい |
| SQL Server データベース | "Microsoft.Sql/servers/databases" | はい | イエス | はい |
| SQL Server エラスティック プール | "Microsoft.Sql/servers/elasticpools" | はい | イエス | はい |
| NetApp ファイル容量プール | "Microsoft.NetApp/netAppAccounts/capacityPools" | はい | イエス | はい |
| NetApp ファイル ボリューム | "Microsoft.NetApp/netAppAccounts/capacityPools/volumes" | はい | イエス | はい |
| Azure Key Vault | "Microsoft.KeyVault/vaults" | はい | イエス | はい |
| Azure Cache for Redis | "Microsoft.Cache/redis" | はい | イエス | はい |
| Azure Stack Edge デバイス | (このリソースには特定のリソース プロバイダーがありません。スタック エッジ デバイスの動作により、メトリックは複数のリソース プロバイダーから取得されます。このリソースのアラートの詳細については、このドキュメントを参照してください。 Azure Stack Edge でのアラートの確認) | はい | イエス | はい |
| Recovery Services コンテナー | "Microsoft.RecoveryServices/Vaults" | はい | いいえ | いいえ |
| Azure Database for PostgreSQL - フレキシブル サーバー | "Microsoft.DBforPostgreSQL/flexibleServers" | はい | イエス | はい |
| ベア メタル マシン (Operator Nexus) | "Microsoft.NetworkCloud/bareMetalMachines" | はい | イエス | はい |
| ストレージ アプライアンス (Operator Nexus) | "Microsoft.NetworkCloud/storageAppliances" | はい | イエス | はい |
| クラスター (Operator Nexus) | "Microsoft.NetworkCloud/clusters" | はい | イエス | はい |
| ネットワーク デバイス (Operator Nexus) | Microsoft.NetworkCloud/l2Networks, Microsoft.NetworkCloud/l3Networks | はい | イエス | はい |
| データ収集ルール | "Microsoft.Insights/datacollectionrules" | はい | イエス | はい |
注意
マルチリソース メトリック アラートは、以下ではサポートされていません。
- VM ゲスト メトリックに関するアラート。
- VM ネットワーク メトリック (受信ネットワーク合計、送信ネットワーク合計、受信フロー数、送信フロー数、受信フローの最大作成速度、送信フローの最大作成速度) に関するアラート。
1 つのメトリック警告ルールで監視の範囲を指定するには、次の 3 つの方法があります。 たとえば、VM ではスコープを次のように指定できます。
- サブスクリプション内の 1 つの Azure リージョン内の VM のリスト。
- サブスクリプション内の 1 つまたは複数のリソース グループ内の 1 つの Azure リージョン内のすべての VM。
- サブスクリプション内の 1 つの Azure リージョン内のすべての VM。
動的しきい値を使って高度な機械学習を適用する
動的しきい値では、高度な機械学習 を使用して次のことが行われます：
- メトリックの履歴の動作を学習する。
- パターンを特定し、時間単位、日単位、週単位のパターンなど、時間の経過に伴うメトリックの変化に適応する。
- サービスイシューの可能性を示す異常を認識する。
- メトリックに最適なしきい値を計算する。
機械学習により、新しいデータを継続的に使用して詳細を学習することで、しきい値がより正確になります。 システムは時間の経過に伴うメトリックの動きに適応し、そのパターンからの逸脱に基づいてアラートを生成するため、メトリックごとに "適切な" しきい値を把握する必要はありません。
動的しきい値は、次の場合に役立ちます。
- 1 つのアラート ルールを使用して、数百のメトリック シリーズに対してスケーラブルなアラートを作成する。 警告ルールの数が少ない場合は、警告ルールの作成と管理に費やす時間が少なくなります。
- 構成するしきい値を認識せずにルールを作成する。
- メトリックに関する広範なドメインの知識なしに、大まかな概念を使用してメトリック アラートを構成する。
- 予期されるパターンを含まない、ノイズの多い (低精度) しきい値または幅の広い (低再現率) しきい値を抑制する。
- ノイズの多いメトリック (コンピューターの CPU やメモリなど)、および分散度が低いメトリック (可用性やエラー率など) を処理する。
メトリック アラート ルールで動的しきい値を使用する手順の詳細については、「動的しきい値」を参照してください。
ログ検索アラート
ログ検索アラート ルールは Log Analytics クエリを使用してリソースを監視することで、一定の頻度でリソース ログを評価します。 条件が満たされると、アラートが発生します。 ログ分析 クエリを使用できるため、データに対して高度なロジック操作を実行し、堅牢な KQL フィーチャーを使用してログ データを操作できます。
ログ検索アラート ルールのターゲットは次のとおりです。
- VM などの 1 つのリソース。
- リソース グループやサブスクリプションなど、リソースの 1 つのコンテナー。
- リソース間のクエリを使用する複数のリソース。
ログ検索アラートでは、さまざまな監視シナリオで使用できる次の異なる 2 つのものを測定できます。
- テーブル行: 返される行の数を使用して、Windows イベント ログ、Syslog、アプリケーション例外などのイベントを処理できます。
- 数値列の計算: 任意の数値列に基づく計算を使用して、任意の数のリソースを含めることができます。 たとえば、CPU の割合です。
ログ検索アラートがステートフルか、ステートレスかを構成できます。
ステートフルなログ検索アラートには次の制限があることに注意してください。
- 評価ごとに最大 300 個のアラートをトリガーできます。
firedアラート条件で最大 5,000 個のアラートを設定できます。
Note
ログ検索アラートが最適に機能するのは、ログ内の不足データを検出しようとする場合ではなく、ログ内の特定のデータを検出しようとする場合です。 ログは半構造化データであるため、VM ハートビートなどの情報に関するメトリック データよりも本質的に高い潜在性を示します。 ログ内の不足データを検出しようとした場合の誤発生を回避するには、メトリック アラートの使用を検討してください。 ログのメトリック アラートを使用して、ログからメトリック ストアにデータを送信できます。
ディメンションを使って複数インスタンスのリソースを監視する
ログ検索アラート ルールの作成時にディメンションを使用すると、1 つのルールでリソースの複数のインスタンスの値を監視できます。 たとえば、Web サイトまたはアプリを実行している複数のインスタンスで CPU 使用率を監視できます。 各インスタンスは個別に監視されます。 通知はインスタンスごとに送信されます。
ディメンションごとの分割を使って複数のリソースに対する同じ条件を監視する
複数の Azure リソースで同じ条件を監視するには、ディメンションによる分割を使用できます。 ディメンションによる分割を使用すると、サブスクリプションまたはリソース グループに対して大規模なリソース中心型アラートを作成できます。 アラートは、数値または文字列の列を使用して組み合わせをグループ化すると、別々のアラートに分割されます。 Azure リソース ID 列で分割すると、指定したリソースがアラート ターゲットになります。
また、スコープ内の複数のリソースに適用される条件が必要な場合は、分割しない決断をすることも可能です。 たとえば、リソース グループ スコープ内の少なくとも 5 台のマシンで CPU 使用率が 80% を超えたらアラートを生成する場合などです。
ログ検索アラート ルールに API を使う
ScheduledQueryRules API を使用して、ワークスペース内の新しいルールを管理します。
Note
Log Analytics のログ検索アラートは、従来の Log Analytics Alert API を使用して以前は管理されていました。 現在の ScheduledQueryRules API への切り替えの詳細について確認してください。
Azure の請求書のログ検索アラート
ログ アラートは、以下の情報とともにリソース プロバイダー microsoft.insights/scheduledqueryrules の下に一覧表示されます。
- Application Insights のログ検索アラートは、正しいリソース名でリソース グループとアラート プロパティとともに表示されます。
- Log Analytics のログ検索アラートは、ScheduledQueryRules API を使用して作成された場合、正しいリソース名でリソース グループとアラート プロパティとともに表示されます。
- 従来の Log Analytics API から作成されたログ アラートは Azure リソースを追跡せず、一意のリソース名は強制されていません。 これらのアラートは、非表示リソースとして
microsoft.insights/scheduledqueryrulesに従って引き続き作成され、そのリソース名前付け構造は<WorkspaceName>|<savedSearchId>|<scheduleId>|<ActionId>です。 従来の API のログ検索アラートは、前述の非表示リソース名でリソース グループとアラート プロパティとともに表示されます。
Note
<、>、%、&、 、? などのサポートされていないリソース文字 / など) は、非表示リソース名ではアンダースコア (_) に置き換えられます。 この文字の変更は、課金情報にも反映されます。
アクティビティ ログ アラート
アクティビティ ログ アラートでは、定義された条件に一致する新しいアクティビティ ログ イベントをアクティビティ ログで確認することで、リソースが監視されます。
アクティビティ ログ アラートは、次の種類のシナリオに使用できます：
- 特定のリソース グループまたはサブスクリプション内のリソースに対して特定の操作が発生した場合。 たとえば、次の場合に通知を受け取ることができます：
- 運用リソース グループ内の VM が削除された。
- サブスクリプション内のユーザーに新しいロールが割り当てられた。
- Service Health イベントが発生した。 Service Health イベントには、サブスクリプション内のリソースに適用されるインシデントおよびメンテナンスの各イベントの通知が含まれます。
次の項目に関するアクティビティ ログ アラートを作成できます。
- アラート イベント以外の任意のアクティビティ ログ イベント カテゴリ。
- JSON オブジェクトの最上位プロパティの任意のアクティビティ ログ イベント。
アクティビティ ログ アラートは Azure リソースであるため、Azure Resource Manager テンプレートを使用して作成できます。 これらは、Azure Portal で作成、更新、削除することもできます。
アクティビティ ログ アラートでは、アラートが作成されたサブスクリプション内のイベントのみが監視されます。
サービス正常性アラート
Service Health アラートは、アクティビティ アラートの一種です。 認証済みの Service Health エクスペリエンスによって、現在使用されているサービスとリソースが把握されているため、Service Health は、停止、計画メンテナンス作業、およびその他の正常性の勧告をユーザーに通知します。
Service Health を使用する最善の方法は、サービスの問題、計画メンテナンス、その他の変更によって、使用する Azure サービスとリージョンに影響がある可能性がある場合に、お好みの通信チャネルを使用して通知を受け取れるように Service Health アラートを設定することです。
Resource Health アラート
Resource Health アラートは、アクティビティ アラートの一種です。 「Resource Health の概要」は、Azure のリソースに影響するサービスの問題の原因を突き止めたり、それに関するサポートを利用したりするのに役立ちます。 リソースの現在と過去の正常性について報告します。
Resource Health は、さまざまな Azure サービスからの信号を基に、リソースが正常であるかどうかを評価します。 リソースが正常でない場合、Resource Health はさらなる情報を分析して問題の原因を特定します。 また、問題を修正するために Microsoft が実施しているアクションについても報告を行い、その問題に対処するためにユーザーが実行できるアクションを特定します。
スマート検出アラート
プロジェクト用に Application Insights を設定し、アプリで一定量のデータが生成されると、スマート検出は 24 時間かけてアプリの通常の動作を学習します。 アプリのパフォーマンスには、一般的な動作パターンがあります。 他よりも失敗しやすい要求や依存関係呼び出しがあります。負荷が増えると、全体的な失敗率が上がる可能性があります。
スマート検出では、これらの異常を検出するために機械学習を使用します。 スマート検出によって、アプリから受け取ったデータ (特に失敗率) が監視されます。 Application Insights では、Web アプリで要求の失敗率が異常に増加すると、ほぼリアルタイムで自動的にユーザーにアラートを送信します。
Web アプリから Application Insights にデータが送られると、スマート検出で現在の動作と過去数日間に見られたパターンが比較されます。 以前のパフォーマンスと比べてエラー率の異常な上昇が検出された場合に、解析がトリガーされます。
問題のトリアージと診断に役立つよう、アラートの詳細には、失敗の特性および関連するアプリケーション データの分析が表示されます。 また、より詳しい診断を行うために、Application Insights ポータルへのリンクも含まれています。 このフィーチャーは、機械学習アルゴリズムを使用して通常のエラー率を予測するため、セットアップや構成は不要です。
メトリック アラートでは問題が発生している可能性があることが示されますが、スマート検出によって診断作業が開始されます。 それ以外の場合は、自分で行う必要がある解析の多くを実行します。 結果はわかりやすくまとめられるので、問題の原因をすぐに把握できます。
スマート検出は、クラウドまたは独自サーバーでホストされ、アプリケーションの要求または依存関係データを生成するあらゆる Web アプリで利用できます。
Prometheus アラート
Prometheus アラートは、Prometheus の Azure Monitor マネージド サービスに保存されているメトリックを監視するために使用されます。 Prometheus アラート ルールは、Prometheus ルール グループの一部として構成されます。 これらは、PromQL 式の結果が true に解決されると発生します。 発生した Prometheus アラートは、他の種類のアラートと同様に表示および管理されます。
次のステップ
- アラートの概要について把握します。
- アラート ルールを作成します。
- スマート検出の詳細について理解します。