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 の警告のロールベースのアクセス制御
アクセス許可があるリソースのアラートに対してのみ、アクセス、作成、または管理を行うことができます。
アラート ルールを作成するには以下が必要です。
- アラート ルールのターゲット リソースに対する読み取りアクセス許可。
- アラート ルールが作成されるリソース グループに対する書き込みアクセス許可。 Azure portal からアラート ルールを作成する場合は、そのアラート ルールが同じリソース グループ (ターゲット リソースが存在している) に既定で作成されます。
- 警告ルールに関連付けられているアクション グループに対する読み取りアクセス許可 (該当する場合)。
すべての Azure Resource Manager スコープでサポートされているこれらの組み込みの Azure ロールには、警告情報にアクセスし、警告ルールを作成するための次のアクセス許可があります。
- 監視共同作成者: 共同作成者は警告を作成し、スコープ内のリソースを使用できます。
- 監視閲覧者: 閲覧者は警告を表示し、スコープ内のリソースを読み取ることができます。
ターゲット アクション グループまたはルールの場所が 2 つの組み込みロールとは異なるスコープにある場合は、適切なアクセス許可を持つユーザーを作成してください。
価格
価格について詳しくは、「Azure Monitor の価格」を参照してください。