Azure Log Analytics エージェントから Azure Monitor エージェントへの移行

この記事の内容

  • Azure VM の監視がどのような仕組みで動いているかを解説します
  • Log Analytics エージェント・診断エージェントなど複数エージェントの役割を整理します
  • Azure Monitor エージェント（AMA）による一元化のメリットを説明します
  • データ収集ルール（DCR）を使った新しい設定方法を紹介します
  • 移行の手順と、移行にあたって注意すべき現時点の制限事項をまとめます

はじめに

2024年8月31日までに、Log Analytics エージェントの代わりに Azure Monitor エージェントの使用を開始するよう、Microsoft からメールで通知が届いています。サポートが終了するため、新しいエージェントへの移行が必要です。

ただし、移行の手順そのものはシンプルでも、「なぜこれでよいのか」「本当にこれで大丈夫なのか」を理解するためには、Azure 上の VM 監視の仕組み全体を把握しておく必要があります。本記事ではまず全体像を整理し、その上で移行の考え方を説明します。

用語の整理

この分野は名称の変遷が複雑です。もともと OMS（Operations Management Suite） と呼ばれていたものが Log Analytics に変わり、さらに Azure Monitor へと変わってきました。そのため、同じものを指していてもドキュメントによって以下のように単語が異なることがあります。

  • OMS エージェント ＝ Log Analytics エージェント
  • Log Analytics ワークスペース ＝ Azure Monitor ワークスペース（表記揺れあり）
  • メトリック ＝ パフォーマンスカウンターに相当するもの

ドキュメントを読む際は、同じ概念を異なる単語で表している可能性があることを念頭に置いてください。

現在の監視アーキテクチャ全体像

ホスト VM のメトリック（追加設定不要）

Azure 上に VM が存在する場合、何も設定しなくても Azure Monitor メトリック に対してホスト VM のメトリックが自動的に収集・保存されます。Azure ポータルの仮想マシン画面でメトリックを確認すると、名前空間として「仮想マシンホスト」が表示されており、CPU・メモリ・ディスク・ネットワークなどの情報を確認できます。

ゲスト VM の情報収集（エージェントが必要）

ゲスト OS 内部の詳細な情報を収集したい場合は、追加の構成が必要です。これには大きく2種類のアプローチがあります。

1. Log Analytics エージェントを使う方法

Log Analytics ワークスペースを作成し、その中で収集する情報を設定します。設定内容はワークスペースを通じて VM に伝わり、VM に Log Analytics エージェントがインストールされます。エージェントは以下のようなデータを Log Analytics ワークスペースへ送信します。

  • Windows イベントログ（アプリケーション・セキュリティ・システムなど）
  • パフォーマンスカウンター
  • Syslog（Linux の場合）
  • IIS ログ
  • カスタムログ（任意のログファイルパスを指定）

収集したデータは Log Analytics ワークスペース上で KQL クエリを使って検索・分析できます。たとえば Heartbeat や Event などのテーブルにクエリを実行することで、各種ログを確認できます。

2. 診断エージェント（Azure Diagnostics Extension）を使う方法

VM の診断設定から「ゲストレベルの監視を有効にする」ことで、Azure Diagnostics エージェント（Windows: WAD、Linux: LAD）がインストールされます。このエージェントはゲスト VM のメトリックとログを Azure Monitor メトリックに送信します。さらに、追加構成によってストレージアカウントやイベントハブに送信することも可能です。

ソリューションと依存関係エージェント

Log Analytics エージェントを基盤として、ソリューションと呼ばれる機能群が存在します。ソリューションとは「何を集めてどのように表示するか」をひとまとめにしたものです。

一部のソリューション（サービスマップなど）では、**Microsoft Dependency Agent（依存関係エージェント）**を追加でインストールする必要があります。Dependency Agent が Log Analytics エージェントと連携し、プロセスや依存関係の情報を収集することで、サービスマップの表示が実現されています。

Azure Security Center や Azure Sentinel なども、Log Analytics エージェントと Dependency Agent を基盤に動作しています。

データのエクスポート

Log Analytics ワークスペースに収集されたデータは、ストレージアカウントやイベントハブにエクスポートすることもできます（プレビュー）。ストレージアカウントへは約1時間ごとにデータが追加されます。イベントハブへはほぼリアルタイムでデータが流れるため、イベント駆動の処理に活用できます。

現状の課題

これまで見てきたように、現在の構成では以下のような課題があります。

  • エージェントの種類が複数存在する（Log Analytics エージェント、Diagnostics エージェント、Dependency Agent）
  • 設定箇所がそれぞれ異なる（ワークスペース設定・VM の診断設定など）
  • どこで何が設定されているか把握しづらい

Azure Monitor エージェント（AMA）による一元化

3つのエージェントを1つに統合

こうした課題を解消するために登場したのが **Azure Monitor エージェント（AMA）**です。従来の3種類のエージェントの機能を1つに集約します。

対象となる環境は以下のとおりです。

  • Azure VM
  • Azure Virtual Machine Scale Sets（VMSS）
  • Azure Arc で管理されているオンプレミス・他クラウドの VM

データの送信先

AMA は以下の2つにデータを送信できます。

送信先内容
Azure Monitor メトリックゲスト VM のメトリック（プレビュー）
Log Analytics ワークスペースゲスト VM のログ・メトリック

また、マルチホームに対応しており、1つのエージェントから複数の Log Analytics ワークスペースに同時送信することが可能です。

なお、現時点ではストレージアカウントやイベントハブへの直接送信には対応していません。

データ収集ルール（DCR）による一元管理

設定方法が大きく変わりました。従来は VM の診断設定・ワークスペースの設定など複数箇所に分散していた構成を、**データ収集ルール（Data Collection Rule / DCR）**という単一の場所で一括管理できるようになりました。

Azure Monitor > データ収集ルール から設定します。

設定の流れは以下のとおりです。

  1. ルール名・リソースグループ・リージョン・プラットフォームの種類（Windows / Linux）を設定する
  2. 対象リソースを追加する（サブスクリプションやリソースグループ単位で指定可能）
  3. データソースを追加する
    • パフォーマンスカウンター（Azure Monitor メトリックまたは Log Analytics ワークスペースに送信）
    • Windows イベントログ（XPath クエリでフィルタリング可能）
    • Syslog（Linux の場合）
  4. 送信先（ターゲット）を指定する

データソースを追加した後、送信先として「Azure Monitor ログ」（＝ Log Analytics ワークスペース）または「Azure Monitor メトリック」（プレビュー）を選択します。

注意： 送信先の Log Analytics ワークスペースは、DCR と同じリージョンである必要があります。

DCR を作成・適用すると、対象 VM への AMA のインストールは自動的に行われます。エージェントを手動でインストールする必要はありません。

マネージド ID の自動設定

AMA の動作には、システム割り当てマネージド ID が使用されます。DCR を適用すると VM に対してシステム割り当てマネージド ID が自動的に有効化され、ワークスペースへの送信権限が付与されます。既存のユーザー割り当て ID を使用している場合は、システム割り当て ID が追加されることに注意してください。

移行の手順

基本的な移行手順は次のとおりです。

  1. Azure Monitor > モニター設定 > データ収集ルール に移動する
  2. 新しいデータ収集ルールを作成する
  3. 収集対象・データソース・送信先を設定する
  4. 作成後、データが正常に収集されていることを確認する

大規模環境では、Azure Policy を使って DCR を一括適用することが効果的です。

移行時の注意事項

Log Analytics エージェントとの共存について

AMA と従来の Log Analytics エージェントは共存させることができます。ただし、同じデータを同じワークスペースに送信すると、データが重複します。データ量が2倍になれば料金も増加しますし、クエリ結果も重複して見づらくなります。

共存する際は以下のいずれかの対応が必要です。

  • 別の Log Analytics ワークスペースを用意して AMA からの送信先に使う
  • 既存の Log Analytics エージェント側の収集を止めてから、AMA で同じワークスペースに送信する

ソリューションの対応状況

Azure Security Center・Azure Sentinel などのソリューションは、Log Analytics エージェントと Dependency Agent の連携で動作しています。現時点では AMA への完全移行がプライベートプレビューまたはパブリックプレビューの段階にあるものが多く、これらのソリューションを利用している場合は移行に制限があります。

利用しているソリューションの AMA 対応状況を必ず事前に確認してください。

Azure Monitor メトリックへの送信がプレビュー段階

AMA からゲスト VM のメトリックを Azure Monitor メトリックに送信する機能は、執筆時点でプレビュー段階です。プレビュー機能を本番環境で使用しない方針の場合は、GA まで待つことを検討してください。

既存エージェントの削除は手動作業

AMA への移行を完了した後、古い Log Analytics エージェント・診断エージェント・Dependency Agent の削除は手動で行う必要があります。台数が多い場合は削除の自動化方法（スクリプト・Azure Policy など）を事前に検討してください。

新規環境での推奨アプローチ

これから新しく構築する環境については、今すぐ AMA を使用することをお勧めします。特に以下のようなシンプルなユースケースには AMA が適しています。

  • ゲスト VM のメトリックを Azure Monitor で確認したい
  • 基本的なイベントログやパフォーマンスカウンターを Log Analytics ワークスペースに収集したい

まとめ

  • Azure VM の監視は「ホスト VM メトリック（自動）」と「ゲスト VM の情報（エージェント必要）」の2層構造になっています
  • 従来は Log Analytics エージェント・診断エージェント・Dependency Agent の3種類が混在し、設定箇所も分散していました
  • Azure Monitor エージェント（AMA）はこれらを1つに統合し、データ収集ルール（DCR） で一元管理できます
  • 移行の手順自体はシンプルですが、ソリューションの対応状況やデータ重複に注意が必要です
  • ソリューション（Sentinel・Security Center 等）を利用している場合は、対応状況を確認してから移行のタイミングを判断してください
  • 新規環境ではすぐに AMA を採用し、既存環境は 2024年8月31日のサポート終了を見据えながら計画的に移行を進めることをお勧めします