変更要約: AZ-305 第1章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
1.3監視の設計
可観測性の設計——Azure Monitor、Log Analytics（KQL）、Application Insights、アラート/アクショングループ、Network Watcher——を理解します。メトリック・ログ・トレースで運用を可視化します。
運用の健全性は監視で支えます。Azure Monitor を中心に、メトリック・ログ・アプリの可観測性を設計します。
1.3.1監視の構成
- Azure Monitor：メトリックとログを集約する監視の中心。
- Log Analytics：ログを集約し KQL で分析するワークスペース。
- Application Insights：アプリの性能・依存関係・例外を追跡（APM）。
- アラート/アクショングループ：閾値/クエリで発報し、通知や自動アクションを起動。
「監視の中心＝Azure Monitor」「ログ集約と KQL 分析＝Log Analytics」「アプリの APM＝Application Insights」「通知/自動対応＝アラート＋アクショングループ」「ネットワーク診断＝Network Watcher」 は AZ-305 で頻出です。横断的なログ分析は Log Analytics ワークスペースに集約します。
AZ-305 の監視設計は「何を・どこに集め・どう通知/分析するか」を要件から組み立てます。Azure Monitor はプラットフォームメトリック（自動収集の数値時系列）とログの二系統を扱い、各リソースの診断設定（Diagnostic Settings）でプラットフォームログ/メトリックを Log Analytics ワークスペース・ストレージ（長期/監査保管）・Event Hubs（外部 SIEM への転送）に送ります。Log Analytics は KQL でログを横断分析でき、複数サブスクリプションのワークスペース設計（集中型 vs 分散型）が論点です。Application Insights はアプリの APM として、依存関係マップ・トランザクション検索・ライブメトリック・可用性テスト（外形監視）を提供し、ワークスペースベースで Log Analytics と統合します。アラートはメトリック/ログ（KQL）/アクティビティログを条件に発報し、アクショングループでメール/SMS/Webhook/Logic Apps/Automation Runbook/ITSM 連携を起動、アラート処理ルールで抑制やメンテナンス時のミュートを行います。Network Watcher は IP フロー検証・接続モニター・NSG フローログ・パケットキャプチャでネットワークを診断します。設計の要は、ログを適切なワークスペースに集約し、保持期間（コスト）とアクセス制御を設計したうえで、重大度に応じたアラートとアクションを結びつけることです。
| 監視の目的 | サービス | 要点 |
|---|---|---|
| メトリック/ログの一元収集 | Azure Monitor＋診断設定 | Log Analytics/ストレージ/Event Hubs へ送信 |
| ログの横断分析 | Log Analytics（KQL） | ワークスペース設計・保持期間 |
| アプリの性能/例外追跡 | Application Insights | 依存関係マップ・可用性テスト |
| 通知と自動対応 | アラート＋アクショングループ | メール/Webhook/Runbook/ITSM |
シナリオ：複数サブスクリプションの VM・App Service・ネットワークのログを一元的に分析し、重大なエラーは即通知、それ以外は分析用に保管したい。→ 各リソースの診断設定で集中型 Log Analytics ワークスペースへログを送信し、KQL で横断分析。アプリは Application Insights で APM。ログアラート（KQL）で重大エラーを検知し、アクショングループで当番へ通知＋必要なら Automation Runbook を起動します。長期保管が要るログはストレージにもアーカイブします。
FAQ：Log Analytics ワークスペースは集中型と分散型どちらで設計する？ 横断分析・一元的な RBAC/保持管理を重視するなら集中型（少数のワークスペース）。データ主権（リージョン分離）・チーム単位の分離・課金分離が要るなら分散型。多くは「中央に集約しつつ、規制やリージョン要件で必要な分だけ分ける」ハイブリッドが現実解です。
ひっかけ：アプリのコード内パフォーマンス（依存関係の遅延・例外）を「Log Analytics だけ」で賄おうとするのは設計として弱い——APM は Application Insights が担います。また、リソースのログは診断設定を構成しないと Log Analytics に流れません（既定では送られない）点に注意。Network Watcher は VM/アプリのメトリックではなくネットワーク層の診断用です。
1.3.2この節のまとめ
- 監視＝Azure Monitor＋Log Analytics（KQL）
- アプリ＝Application Insights／通知＝アラート＋アクショングループ
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 複数リソースのログを一元的に集約し、KQL で横断的に分析したい。何を使いますか？
Q2. Web アプリの応答時間・依存関係・例外を追跡してパフォーマンス問題を特定したい。何を使いますか？
Q3. メトリックが閾値を超えたら、メールや Webhook、自動化を起動したい。何を設定しますか？