Azure Monitorの実践ガイド｜メトリクス・ログ・アラートで運用を可視化

「サーバーが落ちているのに誰も気づかなかった」「パフォーマンスが劣化していたが原因が特定できなかった」――クラウド環境の運用でこうした事態を防ぐには、適切な監視体制の構築が不可欠です。

この記事では、Azure Monitorを使ってメトリクスの収集からログ分析、アラート設定、ダッシュボード構築までを実践的に解説します。IT担当者やエンジニアがすぐに運用に活かせる内容です。

Azure Monitorとは？クラウド監視の統合プラットフォーム

Azure Monitorは、Azureリソースおよびオンプレミス環境の監視データを一元的に収集・分析・活用するためのプラットフォームです。「何が起きているか」を把握するだけでなく、「何か起きる前に対処する」プロアクティブな運用を実現します。

Azure Monitorの主要コンポーネント

Azure Monitorは複数のサービスで構成されています。

• メトリクス：CPU使用率やメモリ消費量など、数値データをリアルタイムで収集
• ログ（Log Analytics）：テキスト形式のログデータを収集し、KQLで分析
• アラート：条件に基づいた通知やアクションの自動実行
• Application Insights：アプリケーションのパフォーマンスと利用状況の監視
• ダッシュボード：監視データの可視化とレポーティング
• Workbooks：インタラクティブなレポート作成ツール

これらを組み合わせることで、インフラからアプリケーションまで、システム全体を統合的に監視できます。

監視データの流れ

Azure Monitorのデータフローは以下のように整理できます。

データソース（Azureリソース、OS、アプリケーション）→データ収集（自動収集、エージェント、SDK）→データストア（メトリクスDB、Log Analyticsワークスペース）→分析・アクション（クエリ、アラート、ダッシュボード）

Azureリソースの基本的なメトリクスは自動的に収集されますが、OSレベルのログやアプリケーションログは追加設定が必要です。

メトリクスの収集と分析

メトリクスは数値ベースの時系列データで、Azureリソースの状態をリアルタイムに把握するための基本要素です。

プラットフォームメトリクス

Azureリソースは作成時点から自動的にプラットフォームメトリクスを収集します。追加設定は不要です。主なリソースと代表的なメトリクスを以下に示します。

仮想マシン（VM）：

• Percentage CPU（CPU使用率）
• Available Memory Bytes（使用可能メモリ）
• Disk Read/Write Operations（ディスクI/O）
• Network In/Out（ネットワーク通信量）

App Service：

• Http Server Errors（HTTPエラー数）
• Response Time（応答時間）
• Requests（リクエスト数）
• CPU Time / Memory Working Set（リソース消費量）

SQL Database：

• DTU Percentage / CPU Percentage（リソース使用率）
• Failed Connections（接続失敗数）
• Deadlocks（デッドロック数）
• Storage Percentage（ストレージ使用率）

メトリクスの保持期間は93日間です。長期保存が必要な場合は、Log Analyticsワークスペースまたはストレージアカウントにエクスポートします。

メトリクスエクスプローラーの使い方

Azure Portalの「メトリクス」ブレードからメトリクスエクスプローラーにアクセスできます。基本的な操作手順は以下のとおりです。

1. スコープの選択：監視対象のリソースを選択します。リソースグループ全体を選択して複数リソースを横断的に確認することも可能です。

2. メトリクスの選択：表示するメトリクス（例：CPU使用率）を選択します。

3. 集計方法の設定：Average（平均）、Max（最大）、Min（最小）、Sum（合計）、Count（件数）から適切な集計を選びます。

4. 時間範囲の調整：過去1時間から過去30日まで、確認したい期間を設定します。

5. フィルターと分割：ディメンション（例：インスタンス名）でフィルタリングやグラフの分割が可能です。

App ServiceのCPU使用率とレスポンスタイムを同一グラフに表示すれば、パフォーマンス低下の原因がリソース不足かどうかを即座に判断できます。

Log Analyticsによるログの収集と分析

Log Analyticsは、Azure Monitorのログデータを格納・分析するワークスペースです。メトリクスだけでは把握できない詳細な状況を、ログデータから深掘りできます。

Log Analyticsワークスペースの構成

まずLog Analyticsワークスペースを作成します。ワークスペースの設計で重要なポイントは以下のとおりです。

• ワークスペースの数：基本は単一ワークスペースに集約。アクセス制御やコンプライアンスの要件がある場合のみ分割
• リージョン：監視対象のリソースと同一リージョンに配置してデータ転送コストを削減
• データ保持期間：デフォルト30日。要件に応じて最大730日まで延長可能（追加コストあり）
• 日次データ量の見積もり：課金はデータ取り込み量に基づくため、事前に見積もりを行う

データ収集の設定

Log Analyticsにデータを送信する方法は複数あります。

診断設定（Diagnostic Settings）：

AzureリソースのリソースログやプラットフォームメトリクスをLog Analyticsに送信します。各リソースの「診断設定」から有効化します。

Azure Monitor Agent（AMA）：

仮想マシンのOSレベルのログ（Syslog、Windowsイベントログ）やパフォーマンスカウンターを収集します。データ収集ルール（DCR）で収集対象を定義します。

Application Insights SDK：

アプリケーションコードに組み込み、リクエストの追跡やエラーの記録を行います。.NET、Java、Node.js、Pythonなどの主要言語に対応しています。

KQLによるログ分析

Log AnalyticsのデータはKQL（Kusto Query Language）で分析します。SQLに似た構文で、直感的にクエリを記述できます。

実践的なKQLクエリの例を紹介します。

過去1時間のエラーログを抽出：

AppServiceHTTPLogs
| where TimeGenerated > ago(1h)
| where ScStatus >= 500
| project TimeGenerated, CsUriStem, ScStatus, TimeTaken
| order by TimeGenerated desc

CPU使用率が80%を超えた時間帯を特定：

Perf
| where ObjectName == "Processor" and CounterName == "% Processor Time"
| where CounterValue > 80
| summarize AvgCPU = avg(CounterValue) by bin(TimeGenerated, 5m), Computer
| order by TimeGenerated desc

アプリケーションの応答時間の推移を可視化：

AppRequests
| where TimeGenerated > ago(24h)
| summarize AvgDuration = avg(DurationMs), P95Duration = percentile(DurationMs, 95) by bin(TimeGenerated, 15m)
| render timechart

KQLの習得は一定の学習コストがかかりますが、一度覚えればトラブルシューティングの効率が劇的に向上します。

アラートの設計と設定

監視データを収集するだけでは不十分です。異常を検知したら即座に通知し、対処につなげるアラートの設定が重要です。

アラートの種類

Azure Monitorのアラートは以下の4種類に分類されます。

• メトリクスアラート：メトリクスの閾値超過を検知。応答が速く（1分間隔で評価）、コストも低い
• ログアラート：KQLクエリの結果に基づいて検知。柔軟な条件設定が可能
• アクティビティログアラート：リソースの作成・削除・設定変更などの管理操作を検知
• サービス正常性アラート：Azureサービスの障害やメンテナンス情報を通知

実践的なアラート設定例

本番環境で設定すべき基本的なアラートを紹介します。

インフラ監視のアラート：

• VM CPU使用率が90%を5分間継続（メトリクスアラート、重大度：警告）
• VMディスク使用率が85%超過（メトリクスアラート、重大度：警告）
• VMハートビートが5分間途絶（メトリクスアラート、重大度：重大）

アプリケーション監視のアラート：

• HTTP 5xxエラーが5分間で10件以上（メトリクスアラート、重大度：重大）
• 応答時間の95パーセンタイルが5秒超過（ログアラート、重大度：警告）
• アプリケーション可用性が99.9%を下回る（メトリクスアラート、重大度：重大）

セキュリティ監視のアラート：

• NSGルールの変更（アクティビティログアラート、重大度：情報）
• ストレージアカウントのパブリックアクセスが有効化（アクティビティログアラート、重大度：重大）

アクショングループの設定

アラートが発火した際のアクションは「アクショングループ」で定義します。通知先や自動対処の方法を設定します。

• メール通知：チームのメーリングリストへ通知
• SMS通知：オンコール担当者へ即時通知
• Webhook：SlackやTeamsへの連携
• Azure Functions：Azure Functionsを呼び出して自動復旧を実行
• Logic Apps：チケット自動作成などのワークフローを起動

アラートの乱発（アラート疲れ）を防ぐため、閾値の設定は慎重に行いましょう。最初は緩めの閾値から始め、運用データを蓄積しながら徐々に最適化するのが実践的です。

ダッシュボードとWorkbooksによる可視化

収集した監視データを関係者全員が把握できるように、ダッシュボードやWorkbooksで可視化します。

Azureダッシュボード

Azure Portalのダッシュボード機能で、メトリクスのグラフやログクエリの結果を一画面にまとめられます。

運用チーム向けダッシュボードの構成例：

• 上段：システム全体の正常性サマリー（稼働中/障害のリソース数）
• 中段左：主要メトリクスのグラフ（CPU、メモリ、レスポンスタイム）
• 中段右：直近のアラート一覧
• 下段：リソースグループごとのコスト推移

ダッシュボードは共有機能で他のユーザーに公開できます。RBACと連携してアクセス権限を制御することも可能です。

Azure Workbooks

Workbooksは、より高度なインタラクティブレポートを作成するためのツールです。パラメーターの切り替え、条件分岐、複数データソースの組み合わせなど、ダッシュボードでは実現できない柔軟な表現が可能です。

Workbooksでは以下のような高度なレポートが作成できます。

• 時間範囲やリソースを動的に切り替えるインタラクティブなレポート
• メトリクスとログを組み合わせた複合分析
• 月次のSLAレポート（稼働率、インシデント数、平均復旧時間）
• キャパシティプランニング用のトレンド分析

Azureにはテンプレートが多数用意されているため、ゼロから作成する必要はありません。テンプレートをベースにカスタマイズするのが効率的です。

Application Insightsによるアプリケーション監視

インフラの監視に加え、アプリケーションレイヤーの監視も重要です。Application InsightsはAzure Monitorの一部で、アプリケーションのパフォーマンスと利用状況を詳細に監視します。

主な監視機能

リクエストの追跡：

各HTTPリクエストの応答時間、ステータスコード、依存関係呼び出し（データベース、外部API）を自動的に記録します。遅いリクエストや失敗したリクエストを即座に特定できます。

例外の記録：

アプリケーションで発生した例外（エラー）を自動収集します。スタックトレースやリクエストのコンテキスト情報も保存されるため、再現困難なバグの調査に役立ちます。

分散トレーシング：

マイクロサービスアーキテクチャでは、1つのリクエストが複数のサービスをまたいで処理されます。Application Insightsの分散トレーシング機能で、リクエストの全体像を把握できます。

可用性テスト：

世界各地のAzureリージョンからWebアプリケーションに定期的にHTTPリクエストを送り、応答を確認します。外部からの可用性監視として有効です。

スマート検出

Application Insightsの「スマート検出」は、機械学習を使って異常を自動検知する機能です。応答時間の急激な増加、エラー率の上昇、メモリリークの兆候などを、閾値の手動設定なしに検出します。

検出結果はメールで通知され、詳細な分析レポートも提供されます。新しくデプロイしたアプリケーションでも、ベースラインが自動的に学習されるため、すぐに利用を開始できます。

Azure Monitor導入のステップと運用改善サイクル

Azure Monitorの導入は段階的に進めるのが効果的です。以下のステップで進めましょう。

ステップ1：基本的な監視の有効化

• Log Analyticsワークスペースの作成
• 主要リソースの診断設定を有効化
• VMにAzure Monitor Agentをインストール
• サービス正常性アラートの設定

ステップ2：アラートの整備

• CPU、メモリ、ディスクの基本メトリクスアラートを設定
• アプリケーションのHTTPエラーアラートを設定
• アクショングループで通知先を設定
• アクティビティログアラートでセキュリティ関連の変更を監視

ステップ3：可視化と分析

• 運用ダッシュボードの作成
• Application Insightsの導入（Webアプリケーションがある場合）
• 定常的なKQLクエリの保存と共有
• Workbooksによる月次レポートの自動化

ステップ4：継続的な改善

• アラートの閾値を運用データに基づいて最適化
• 不要なログ収集を停止してコストを削減
• インシデント発生時の振り返りで監視項目を追加
• Well-Architected Frameworkの運用性指標に基づいてレビュー

監視は「設定して終わり」ではありません。システムの変更に合わせて継続的に改善し続けることが、安定したクラウド運用の鍵です。クラウドコスト削減の観点からも、不要な監視データの見直しは定期的に行いましょう。