タイトル
Azureで実現する「監視」と「ロギング」〜Azure Monitor・Log Analytics・アラート設定の基礎〜
- シーズン：Azure勉強会
- メモ：システムを止めないための“観測力”を身につけよう
なぜ「監視」と「ロギング」が重要なのか？
- 障害を早期に検知し、影響を最小限に抑える
- ログを活用することで、「気づける運用」が可能に
- クラウド環境では自動化・一元管理がカギ
Azure Monitorとは？
Azure全体の監視基盤。リソースの状態やパフォーマンスを可視化し、ログ分析・アラート通知・自動対応までを一元的に行う。
主な機能
- メトリック収集（CPU、応答時間など）
- ログ分析（エラー、操作履歴など）
- 可視化（ダッシュボード、ワークブック）
- 通知・自動化（アラート、Logic App 連携）
メトリック監視でリアルタイムを掴む
- 各リソースが自動的にメトリック（数値データ）を送信
- 例：CPU使用率、ネットワーク遅延、ディスクIO
- リアルタイム監視に向いており、アラート設定の基礎
- 保持期間：標準で93日間
ログを深掘りする「Log Analytics」
Azure Monitor Logsの分析基盤。様々なリソースのログを横断的に分析できる。分析にはKusto Query Language (KQL)を使用。
活用例
- エラー頻度の傾向把握
- 特定ユーザー操作の追跡
- システム横断的な障害調査
Kusto Query Language（KQL）の基本構文
ログをSQLライクな形式で検索・集計できる。
例：直近1時間のエラー件数を集計するクエリ：
AppTraces
| where SeverityLevel == "Error"
| where TimeGenerated > ago(1h)
| summarize count() by bin(TimeGenerated, 5m)
ポイント：
- where：フィルタ条件
- summarize：集計処理
- bin()：時間単位のグルーピング
異常を自動検知する「アラート」の仕組み
Azure Monitor Alertsは、異常をトリガーに通知や自動処理を行う。
構成要素
- シグナル：監視対象（メトリック・ログなど）
- ルール：条件・閾値
- アクション：メール通知やLogicApp連携など
アラート × 自動化で運用をスマートに
- 通知先：メール / Teams / PagerDuty / Logic Apps / Functions
- 自動対応例：
- VMスケールアウト
- Functionで再起動スクリプト実行
- チャット通知で即時共有
クラウド監視・ロギングサービス比較（Azure × AWS × GCP）
| 分類 | Azure | AWS | GCP | 主な役割 |
|---|---|---|---|---|
| 全体統合監視 | Azure Monitor | Amazon CloudWatch | Cloud Monitoring | 各クラウド全体のメトリクス・ログを統合的に収集・可視化 |
| ログ収集・分析 | Log Analytics（Azure Monitor Logs） | CloudWatch Logs / AWS OpenSearch Service | Cloud Logging | 各リソースのログ収集・検索・分析を行う |
| クエリ分析言語 | KQL（Kusto Query Language） | CloudWatch Logs Insights（専用クエリ言語） | Logs Explorer（Logging Query Language） | ログを検索・集計・トレンド分析するためのクエリ言語 |
| アラート設定 | Azure Monitor Alerts | CloudWatch Alarms | Alerting Policies（Cloud Monitoring） | メトリックやログ条件を基にアラートを発火 |
| 通知・自動対応 | Action Groups + Logic Apps + Functions | SNS + Lambda + EventBridge | Notification Channels + Cloud Functions / Pub/Sub | アラートをトリガーに通知や自動処理を実行 |
| ダッシュボード | Azure Dashboard / Workbook | CloudWatch Dashboard | Cloud Monitoring Dashboard | メトリクスやログを可視化するGUIツール |
| トレース・APM | Application Insights | AWS X-Ray | Cloud Trace / Cloud Profiler | アプリケーションの遅延やトレース分析 |
| ログ格納期間・コスト | 93日（拡張可）／従量課金 | 期限なし（保存期間指定可）／従量課金 | 30日（拡張可）／従量課金 | データ保持期間・料金体系に違いあり |
| 自動化連携の柔軟性 | Logic Apps でGUI連携 | EventBridge/Lambda でコード連携 | Cloud Functions + Pub/Sub で連携 | 自動化手段のアプローチが異なる |
各クラウドの特徴まとめ
Azure Monitor 系列の特徴
- 統合感が非常に強い（メトリック・ログ・アラートが同一基盤）
- KQLが強力：分析クエリがSQLライクで柔軟
- Logic Appsとの親和性が高く、ノーコード自動化が得意
→ 「運用自動化を設計から意識して作りたい」チームに向いている。
AWS CloudWatch 系列の特徴
- 安定した老舗的存在。メトリクス、ログ、アラームが一貫
- Lambda連携が強力で、自動復旧やスケーリングに直結
- ダッシュボードも柔軟だが、ログ検索性はやや限定的
→ 「IaC（コード）で完全制御したい」開発志向チーム向け。
GCP Cloud Operations → Google Cloud Operations Suite 系列の特徴
- GoogleらしいUIと分析志向。クエリが直感的
- Cloud Functions / Pub/Subとの統合でリアルタイム処理に強い
- BigQuery連携でログ分析のスケーラビリティが圧倒的
→ 「分析・可視化を中心にしたデータドリブン運用」に向く。
監視・ロギングの最適化まとめ
- Azure Monitorでメトリックを可視化
- Log Analyticsでログを深掘り分析
- アラートで迅速かつ自動対応
ベストプラクティス
- 全リソースを対象に監視設定
- KQLテンプレートを共有して再利用
- 通知過多を防ぐ粒度調整
- 定期的にルール・しきい値を見直し
総括：「監視は“仕組み”で続けることが鍵」
ふりかえり
確認問題
- 初級
- 中級
- 上級
ふりかえり。確認問題１
問題：Azure Monitorが主に提供している機能はどれ？
A. 仮想マシンのスナップショット作成
B. Azureリソースのメトリクスとログの収集・可視化
: C. ユーザーのアクセス権限の管理
確認問題１回答
正解：B
Azure Monitorは「リソースの監視と分析」の中心的サービス。
メトリクス（CPU使用率などの数値）やログ（イベント履歴）を統合的に扱います。
ふりかえり。確認問題２
問題：Log Analyticsで収集したログデータを検索・分析するために使用されるクエリ言語は？
A. SQL
B. Kusto Query Language (KQL)
C. PowerShell Script
確認問題２回答
正解：B
KQLはAzure専用のログ分析クエリ言語。
例えば「一定期間内のエラー数」や「CPU使用率が閾値を超えたVM」などを簡潔に抽出できます。
ふりかえり。確認問題３
問題：Azure Monitorのアラートで「自動的にスクリプトや修復アクションを実行する」ための機能はどれ？
A. Logic App
B. Action Group
C. Automation Runbook
確認問題３回答
正解：C
Automation Runbookをアラートに連携することで、「異常検知 → 自動復旧（例：VM再起動やスケールアウト）」が可能になります。
通知専用なら Action Group、自動処理まで含めるなら Runbook を組み合わせます。
- Automation Runbook: 実行する処理内容を記載したスクリプト
- Logic App: ノーコード／ローコードでワークフローを自動化
- Action Group: アラートの通知ルールや連絡先の管理
ふりかえり。確認問題 Extra
問題：Azure Monitorにおける「Application Insights」の役割は？
A. Webアプリケーションのコードレベルでのパフォーマンス監視
B. 仮想ネットワークの通信監視
C. Azureリソースの料金分析
確認問題 Extra 回答
正解：A
Application Insightsはアプリ開発者向けの監視機能。
トランザクション単位で遅延・例外をトレースし、ユーザー操作ごとの動作も分析できます。
- 仮想ネットワークの通信監視: Network Watcher
- Azureリソースの料金分析: Cost Management + Billing
参考（感謝）
- AIで作成