変更要約: DP-300 第4章を深掘り（図ja化・比較表/シナリオ/FAQ/ひっかけ/深掘り段落を全節に追加）
4.2アラートと通知の構成
メトリックやログの条件で発報する アラート、通知や自動対応を担う アクショングループ、ジョブ失敗時の通知を理解します。問題の早期検知と自動対応で運用を安定させます。
自動化は「実行」だけでなく「異常の検知と通知」も含みます。CPU 高騰やジョブ失敗を早期に知り、自動対応につなげます。
4.2.1アラートと通知
- アラート：メトリック（CPU/DTU/ストレージ）やログの条件で発報する。
- アクショングループ：メール/SMS・Webhook・Logic Apps・Automation Runbook 実行などで通知/自動対応する。
- ジョブの通知：SQL Agent/Elastic Jobs の失敗時に通知を出し、見逃しを防ぐ。
- 自動是正：アラートから Runbook/Logic Apps を起動し、定型対応を自動化できる。
「条件で発報＝アラート」「通知/自動対応＝アクショングループ（メール・Webhook・Runbook）」「ジョブ失敗の通知」「アラート→Runbook で自動是正」 は DP-300 で頻出です。監視（前章）で計測し、アラートで通知、Automation で自動対応、と組み合わせます。
Azure Monitor の アラートルール は「対象リソース」「条件（シグナル）」「アクショングループ」「重大度（Sev0〜4）」で構成します。シグナルは メトリックアラート（CPU%/DTU%/ストレージ% などのしきい値・動的しきい値で自動学習も可）と ログ（スケジュール）アラート（Log Analytics の KQL の結果件数）に分かれます。アクショングループ は通知（メール/SMS/プッシュ/音声）と処理（Webhook・Logic Apps・Automation Runbook・Functions・ITSM 連携）をまとめ、複数アラートで再利用します。SQL Agent ジョブは オペレーター と通知でメール、Elastic Jobs/Automation は出力やステータスから失敗を検知してアラート化します。アラートの 状態（新規/確認済み/終了） と 抑制（アラート処理ルール） でノイズや重複通知を抑え、アラートストーム を防ぎます。設計の勘所は「監視（メトリック/ログ）で計測 → アラートで検知 → アクショングループで通知し、可能なら Runbook/Logic Apps で自動是正」という閉ループにすることです。
| アラート種別 | 発報元 | 例 |
|---|---|---|
| メトリックアラート | 数値メトリックのしきい値 | CPU% > 90 が 5 分継続 |
| ログ（スケジュール）アラート | Log Analytics の KQL 結果件数 | エラーログ件数の急増 |
| ジョブ失敗通知 | SQL Agent オペレーター/ジョブ状態 | 夜間バッチの失敗 |
シナリオ： ストレージ使用率が 90% を超えたら担当に通知し、可能なら自動で容量を拡張したい。→ メトリックアラート（ストレージ% > 90）を作り、アクショングループでメール通知＋容量拡張を行う Automation Runbook を実行します。重複通知はアラート処理ルールで抑制し、重大度を適切に設定します。
FAQ： Q. メトリックアラートとログアラートの使い分けは？ → A. CPU% など数値しきい値はメトリックアラート、特定パターンの発生回数（KQL）はログアラートです。Q. 同じアラートを何度も受け取って煩わしい時は？ → A. アラート処理ルールで抑制/グループ化し、アクショングループは再利用します。
ひっかけ： 「アラートが自動で問題を修復する」は誤りです。アラートは検知/発報まで。自動是正はアクショングループから Runbook/Logic Apps を起動して行います。また「通知先の設定（メール等）はアラートルールに直接書く」も誤り（通知/処理はアクショングループにまとめて再利用するのが基本）。
4.2.2この節のまとめ
- アラート＝条件で発報、アクショングループ＝通知/自動対応
- ジョブ失敗の通知＋Runbook で自動是正
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. CPU 使用率が一定を超えたら通知したい。Azure の何を構成しますか？
Q2. アラート発報時にメール送信や Runbook 実行などの対応をまとめて定義するものはどれですか？
Q3. 夜間バッチのジョブが失敗したことを見逃さないために有効なのはどれですか？