Azure Monitor の警告とは
警告は、Azure Monitor データがインフラストラクチャまたはアプリケーションに問題がある可能性があることを示しているときに事前に通知することで、ユーザーが問題に気付く前に検出して対処するのに役立ちます。
Azure Monitor データ プラットフォームでは、任意のメトリックまたはログ データ ソースに対してアラートを生成できます。
次の図は警告のしくみを示しています。
警告ルールでは、データを監視し、指定されたリソースで何かが起こっていることを示すシグナルをキャプチャします。 アラート ルールではシグナルを取り込み、シグナルが条件の基準を満たしているかどうかを確認します。
アラート ルールでは、次が結合されます。
- 監視対象のリソース。
- リソースからのシグナルまたはデータ。
- 条件。
アラート ルールの条件に一致した場合、アラートがトリガーされます。 関連付けられたアクション グループがアラートにより始動し、アラートの状態が更新されます。 複数のリソースを監視している場合、アラート ルールの条件はリソースごとに個別に評価され、各リソースに対してアラートが個別に発生します。
アラートは 30 日間保存され、30 日間の保持期間の後に削除されます。 Azure の全リソースの全アラート インスタンスを Azure portal のアラート ページで確認できます。
アラートの構成:
- アクション グループ: これらのグループは通知をトリガーして、アラートがトリガーされたことをユーザーに知らせたり、自動化されたワークフローを開始したりできます。 アクション グループには次のものが含まれます。
- メール、SMS、プッシュ通知などの通知方法。
- Automation の Runbook。
- Azure Functions。
- ITSM インシデント。
- ロジック アプリ。
- セキュア Webhook。
- Webhook。
- イベント ハブ。
- 警告条件: これらの条件はシステムによって設定されます。 アラートが発生すると、アラート条件が [発生] に設定されます。 アラート発生の原因になった状態が解消されると、アラート条件は [解決済み] に設定されます。
- ユーザーの応答: この応答はユーザーによって設定され、ユーザーが変更するまで変わりません。 ユーザー応答は、[新規]、[確認済み]、[終了] のいずれかになります。
- アラート処理ルール: アラート処理ルールを使用して、トリガーされたアラートが発生しているときに変更を加えることができます。 警告処理ルールを使用して、アクション グループを追加または抑制したり、フィルターを適用したり、定義済みのスケジュールに従ってルールを処理したりすることができます。
アラートの種類
次の表では、各アラートの種類の簡単な説明を示します。 各警告の種類と、ニーズに最も適した警告の種類を選択する方法の詳細については、「Azure Monitor アラートの種類」を参照してください。
| アラートの種類 | [説明] |
|---|---|
| メトリック アラート | メトリック アラートでは、リソース メトリックを定期的に評価します。 メトリックはプラットフォーム メトリック、カスタム メトリック、メトリックに変換された Azure Monitor からのログまたは Application Insights メトリックにすることができます。 メトリック警告では、複数の条件と動的しきい値を適用することもできます。 |
| ログ検索アラート | ログ検索アラートを通じ、ユーザーは Log Analytics クエリを使用して、事前に定義した頻度でリソース ログを評価できます。 |
| アクティビティ ログ アラート | アクティビティ ログ アラートは、定義された条件と一致する新しいアクティビティ ログ イベントが発生したときにトリガーされます。 Resource Health アラートと Service Health アラートは、サービスとリソースの正常性を報告するアクティビティ ログ アラートです。 |
| スマート検出アラート | Application Insights リソースでのスマート検出により、Web アプリケーションの潜在的なパフォーマンスの問題や失敗の異常に関する警告を自動的に受け取ることができます。 Application Insights リソースのスマート検出を移行して、さまざまなスマート検出モジュールのアラート ルールを作成できます。 |
| Prometheus アラート | Prometheus アラートは、Prometheus 用 Azure Monitor マネージド サービスに保存されている Prometheus メトリックに基づくアラートに使用されます。 警告ルールは、オープンソース クエリ言語である PromQL に基づいています。 |
警告と状態
アラートは、ステートフルまたはステートレスにすることができます。
- ステートレス アラートは、前に発生した場合でも、条件が満たされるたびに発生します。
- ステートフル アラートは、ルール条件が満たされたときに発生し、条件が解決されるまで、もう一度発生したり、さらにアクションがトリガーされたりすることはありません。
各アラート ルールは個別に評価されます。 同じ条件に対して別のアラートが構成されているかどうかを確認するための検証はありません。 同じ条件に対して複数のアラート ルールが構成されている場合、その条件が満たされると、それらのアラートがそれぞれ発生します。
アラートは 30 日間保存され、30 日間の保持期間の後に削除されます。
ステートレス アラート
ステートレス アラートは、条件が満たされるたびに発生します。 すべてのステートレス アラートのアラート条件は常に fired です。
- アクティビティ ログ アラートはすべてステートレスです。
- ステートレス メトリック アラートの通知の頻度は、アラート ルールで構成された頻度によって異なります。
- 警告の頻度が 5 分未満: 条件が継続して満たされている間、1 分から 6 分の間に通知が 1 回送信されます。
- アラートの頻度が 5 分以上: 条件が継続して満たされている間、構成された頻度とその頻度の 2 倍の間で通知が 1 回送信されます。 たとえば、頻度が 15 分の警告ルールの場合、通知は 15 分から 30 分の間のどこかで送信されます。
ステートフル アラート
ステートフル アラートは、ルール条件が満たされたときに発生し、条件が解決されるまで、もう一度発生したり、さらにアクションがトリガーされたりすることはありません。
ステートフル アラートのアラート条件は、解決済みと見なされるまで fired です。 アラートが解決されたと見なされると、アラート ルールは Webhook またはメールを使用して解決済みの通知を送信し、アラート条件が resolved に設定されます。
ステートフル アラートの場合、アラート自体は 30 日後に削除されますが、アラート条件はアラートが解決されるまで格納されるため、別のアラートが発生するのを防ぎ、アラートが解決されたときに通知を送信できます。
ステートフル ログ アラートの制限を含むアラートの制限については「サービスの制限」を参照してください。
次の表では、ステートフル アラートが解決済みと見なされる状況について説明します。
| アラートの種類 | アラートは次の場合に解決されます |
|---|---|
| メトリック アラート | 3 回連続するチェックでは、アラート条件が満たされません。 |
| ログ検索アラート | 指定した時間の範囲に警告の条件が満たされていません。 時間の範囲は、アラートの頻度によって異なります。
|
推奨されるアラート ルール
Azure portal で、推奨される既定の警告ルールを有効にすることができます。
次に基づいて、推奨される警告ルールの一覧がシステムによってコンパイルされます。
- リソースを監視するための重要なシグナルとしきい値についてのリソース プロバイダーの知識。
- 顧客が一般的に、このリソースの警告を何に対して行っているかを示すデータ。
注意
推奨されるアラート ルールは、次に対して有効になります。
- 仮想マシン
- AKS リソース
- Log Analytics ワークスペース
大規模な警告
大規模な警告ルールを作成するために、次のいずれかの手法を利用できます。 それぞれの選択肢に長所と短所があり、それが警告ルールのコストとメンテナンスに影響を与える可能性があります。
メトリック アラート
同じ Azure リージョナルに存在する同じ種類の複数のリソースを監視するために 1 つのメトリック アラート ルールを使用することができます。 監視対象リソースごとに個別の通知が送信されます。
複数のリソースをサポートしない Azure サービスのメトリック アラート ルールの場合、Azure CLI、PowerShell、Azure Resource Manager テンプレートなどの自動化ツールを使用し、複数のリソースに対して同じ警告ルールを作成します。 サンプル ARM テンプレートについては、「Azure Monitor のメトリック アラート ルール用の Resource Manager テンプレート サンプル」を参照してください。
各メトリック アラート ルールは、監視される時系列の数に基づいて課金されます。
ログ検索アラート
ログ検索アラート ルールを使用すると、Log Analytics ワークスペースにデータを送信するすべてのリソースを監視できます。 これらのリソースの送信元にはあらゆるサブスクリプションまたはリージョンが想定されます。 Log Analytics ワークスペースの設定時にデータ コレクション ルールを使用すると、ログ検索アラート ルールに必要なデータを収集できます。
[ディメンションで分割] を使用することで、ワークスペース中心のアラートではなく、リソース中心のアラートを作成することもできます。 resourceId 列で分割すると、条件に一致するアラートがリソースごとに 1 つ取得されます。
ディメンションによる分割を使用するログ検索アラート ルールは、クエリの結果として生成されるディメンションにより作成される時系列の数に基づき課金されます。 データが Log Analytics ワークスペースに既に収集されている場合、追加コストは発生しません。
Log Analytics ワークスペースでメトリック データを大規模に使用する場合、データ インジェストに基づいて価格が変更されます。
大規模な警告に Azure ポリシーを使用する
Azure ポリシーを使用して大規模なアラートを設定できます。 これには、大規模なアラートを簡単に実装できるという利点があります。 これが実装されるしくみは、Azure Monitor ベースライン アラートで確認できます。
ポリシーを使用して警告ルールを作成する場合、大規模な警告ルール セットを保守管理する間接費が増える可能性があることにご注意ください。
Azure の警告のロールベースのアクセス制御
アクセス許可があるリソースのアラートに対してのみ、アクセス、作成、または管理を行うことができます。
アラート ルールを作成するには以下が必要です。
- アラート ルールのターゲット リソースに対する読み取りアクセス許可。
- アラート ルールが作成されるリソース グループに対する書き込みアクセス許可。 Azure portal からアラート ルールを作成する場合は、そのアラート ルールが同じリソース グループ (ターゲット リソースが存在している) に既定で作成されます。
- 警告ルールに関連付けられているアクション グループに対する読み取りアクセス許可 (該当する場合)。
すべての Azure Resource Manager スコープでサポートされているこれらの組み込みの Azure ロールには、警告情報にアクセスし、警告ルールを作成するための次のアクセス許可があります。
- 監視共同作成者: 共同作成者は警告を作成し、スコープ内のリソースを使用できます。
- 監視閲覧者: 閲覧者は警告を表示し、スコープ内のリソースを読み取ることができます。
ターゲット アクション グループまたはルールの場所が 2 つの組み込みロールとは異なるスコープにある場合は、適切なアクセス許可を持つユーザーを作成してください。
価格
価格について詳しくは、「Azure Monitor の価格」を参照してください。