Azure Monitor

解決する課題

物理的にもサービス的にも分散した Azure 環境で、「今どうなっているか」を一箇所から把握できます。

• システムが今どんな状態か（メトリクス）を知りたい
• 異常を自動で検知して通知/対処したい
• ログを一元的に集めて横断検索したい（Log Analytics / KQL）
• アプリの分散トレース・依存関係を可視化したい（Application Insights）

主要概念と用語

• メトリクス（Azure Monitor Metrics）: 軽量な時系列の数値。プラットフォーム メトリクスは既定で自動収集され、約 1 分粒度・93 日保持。時系列 DB に格納される
• ログ（Azure Monitor Logs）: イベント/トレース/レコードを Log Analytics ワークスペースに格納し、**KQL（Kusto 照会言語）**でクエリ・集計する
• Application Insights: APM（アプリケーション パフォーマンス監視）。リクエスト・依存関係・例外・分散トレースを収集（AWS の CloudWatch Application Signals / X-Ray 相当）
• Data Collection Rule（DCR）/ Azure Monitor Agent（AMA）: VM の OS 内部の指標（メモリ・ディスク等）やログ、syslog を集める新世代エージェントと収集設定。旧 Log Analytics Agent（MMA）は 2024 年に廃止
• アラート ルール（メトリクス/ログ/アクティビティ ログ）: 条件成立でアラートを発火。状態は監視可能（新規 / 確認済み / 終了）
• アクション グループ: アラート時の通知/アクションの束（メール・SMS・プッシュ・Webhook・Logic Apps・関数・自動化 Runbook）
• 診断設定（Diagnostic Settings）: 各リソースのリソース ログやメトリクスを、Log Analytics / ストレージ / Event Hubs に送る設定
• ブック（Workbooks）/ ダッシュボード: 可視化。Managed Grafana 連携も可能

仕様・制限・クォータ

• プラットフォーム メトリクスは既定で約 1 分粒度・93 日保持。より長期や横断分析が必要なら、診断設定で Log Analytics やストレージへ送る
• カスタム メトリクスは任意の粒度で送信可（保持は同じく 93 日）
• ログ（Log Analytics）の保持は既定 30 日（Application Insights は 90 日）、テーブル単位で最大 730 日まで対話的保持、さらにアーカイブで最大 12 年まで延長可
• テーブル プランは Analytics / Basic / Auxiliary を選べ、取り込みコストとクエリ可能性が変わる
• メトリクス アラートの評価頻度は最短 1 分。ログ アラートは最短 1 分（コストは頻度に比例）
• ワークスペースはリージョン リソース。複数ワークスペースをまたぐクエリは可能だが設計で集約方針を決める

内部の仕組み

各 Azure リソースは、プラットフォーム メトリクスを Azure Monitor の時系列メトリクス ストアへ自動送信します。詳細なリソース ログは既定では収集されず、リソースごとに診断設定を有効化して初めて Log Analytics などへ流れます。VM の OS 内部の指標（メモリ・ディスク空き容量など）やゲスト ログは、**Azure Monitor Agent（AMA）＋ Data Collection Rule（DCR）**を構成して収集します。

アラート ルールは一定の評価期間でメトリクス/ログを評価し、条件成立でアラートを生成、紐づくアクション グループを起動します。

設計パターン / ベストプラクティス

• 集中ログ ワークスペース: サブスクリプション横断で 1〜数個の Log Analytics ワークスペースに集約し、RBAC とコストを統制
• アラート → アクション グループ → 通知（メール/Teams/PagerDuty Webhook）や自動対応（Logic Apps・Automation Runbook・Functions）
• オートスケールの起点に Azure Monitor メトリクスを使い、VMSS / App Service を負荷に応じて増減
• 動的しきい値（Dynamic Thresholds）や複数リソースへの1 ルール適用で、誤検知とルール乱立を抑制
• アプリ層は Application Insights で分散トレース、インフラ層はメトリクス＋ログと役割分担

運用・監視

• 監視データが来ない → 診断設定が未構成、または AMA/DCR の割り当て・マネージド ID 権限を確認
• アラートが鳴らない → 評価期間・データ欠損、アクション グループの宛先/抑制（Alert Processing Rule）を確認
• コスト増 → ログ取り込み量（Verbose ログの送りすぎ）、保持期間、頻度の高いログ アラートを点検
• ノイズ過多 → 動的しきい値・アラートのグループ化・Alert Processing Rule で抑制

コスト

課金は主にログ取り込み量（GB）・メトリクス・アラート ルール数・通知数で発生します。取り込み量と保持を抑えるのが効きます。

セキュリティ

• ログ ワークスペースへのアクセスは Microsoft Entra ID + Azure RBAC（リソース コンテキスト/テーブル レベル RBAC）で制御
• データは保存時に暗号化。要件に応じて **Customer-Managed Key（CMK）**を Key Vault で管理
• エージェント/収集にはマネージド ID を使い、資格情報のハードコードを避ける
• 監査は Azure Monitor アクティビティ ログ（コントロール プレーン操作の証跡）と役割分担。Microsoft Sentinel（SIEM）連携で脅威検知へ拡張

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# Log Analytics ワークスペースを作成
az monitor log-analytics workspace create \
  --resource-group demo-rg \
  --workspace-name demo-law \
  --location japaneast

# VM のリソース ログ/メトリクスを Log Analytics へ送る診断設定を作成
az monitor diagnostic-settings create \
  --name vm-to-law \
  --resource "/subscriptions/<sub-id>/resourceGroups/demo-rg/providers/Microsoft.Compute/virtualMachines/demo-vm" \
  --workspace demo-law \
  --metrics '[{"category":"AllMetrics","enabled":true}]'

# CPU 使用率の平均が 80% を超えたらアクション グループへ通知するメトリクス アラート
az monitor metrics alert create \
  --name high-cpu \
  --resource-group demo-rg \
  --scopes "/subscriptions/<sub-id>/resourceGroups/demo-rg/providers/Microsoft.Compute/virtualMachines/demo-vm" \
  --condition "avg Percentage CPU > 80" \
  --window-size 5m --evaluation-frequency 1m \
  --action "/subscriptions/<sub-id>/resourceGroups/demo-rg/providers/microsoft.insights/actionGroups/ops-ag"

# Log Analytics に対して KQL でエラー ログを集計
az monitor log-analytics query \
  --workspace <workspace-id> \
  --analytics-query "AppTraces | where SeverityLevel >= 3 | summarize count() by bin(TimeGenerated, 1h)"