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

Azure Monitor エージェント (AMA) は、Azure および Azure 以外の環境 (オンプレミスやその他のクラウド) において、Windows と Linux のマシンで、Log Analytics エージェント (Microsoft Monitor Agent (MMA) や OMS とも呼ばれます) の後継となります。 このエージェントでは、データ収集ルール (DCR) を使用してデータ収集の構成を簡単かつ柔軟に構成する方法を導入しています。 この記事では、Log Analytics エージェントから Azure Monitor エージェントへの移行を成功させる方法に関するガイダンスを提供します。

移行作業は複雑です。 この記事の情報をガイドとして活用し、Azure Monitor エージェントへの移行を計画してください。

重要

Log Analytics エージェントは、2024 年 8 月 31 日に廃止される予定です。 この日以降に MMA または OMS エージェントを使うと、次のことが予想されます。

• データのアップロード: クラウド インジェスト サービスでは、MMA エージェントのサポートが段階的になくなります。そのため、MMA エージェントのサポートが減少し、時間の経過と同時に互換性の問題が発生する可能性があります。 MMA のインジェストは、2025 年 2 月 1 日まで変更されません。
• インストール: レガシ エージェントをインストールする機能は Azure Portal から削除され、レガシ エージェントのインストール ポリシーは削除されます。 MMA エージェント拡張機能のインストールやオフライン インストールの実行は引き続き行えます。
• カスタマー サポート: レガシ エージェントの問題のサポートを受けることができません。
• OS サポート: 新しい Linux または Windows ディストリビューション (Service Pack を含む) のサポートは、レガシ エージェントの廃止後には追加されません。

メリット

Azure Monitor エージェントを使用すると、次に示すメリットをすぐに得ることができます。

• データ収集ルールを使用したコスト削減:
  • レガシ エージェントの "全か無か" のアプローチと比べ、マシンまたはマシンのサブセットに対して対象を絞った詳細なデータ収集を行うことができます。
  • フィルタリング規則とデータ変換を許可して、アップロードされるデータ量全体を低減するため、インジェスト コストとストレージ コストを大幅に削減できます。
• セキュリティとパフォーマンス
  • マネージド ID と Microsoft Entra トークン (クライアント用) を通して強化されたセキュリティ。
  • 従来の Log Analytics (MMA/OMS) エージェントよりも 25% 優れたイベント スループット。
• 効率的なトラブルシューティングなど、管理の簡素化:
  • リージョン間およびテナント間のデータ収集 (Azure LightHouse を使用) など、複数の宛先 (複数の Log Analytics ワークスペース、つまり Windows と Linux 上の "マルチホーム") へのデータのアップロードをサポートします。
  • オンボードからデプロイを経て長期間にわたって行われる更新と変更まで、データ収集ライフサイクル全体にわたったエンタープライズ規模の一元化された "クラウド内" エージェント構成。
  • 構成の変更は、クライアント側でのデプロイを必要とすることなく、自動的にすべてのエージェントにロールアウトされます。
  • Microsoft Sentinel、Defender for Cloud、VM Insights など、より多くの機能やサービスの透明性が向上し、制御が強化されます。
• サポートされているサーバーとクライアント デバイス間でのすべてのデータ収集ニーズに対応する単一のエージェント。 単一のエージェントは目標ですが、Azure Monitor エージェントは現在 Log Analytics エージェントと収束しています。

開始する前に

• Azure Monitor エージェントをインストールするための前提条件を確認します。 Azure 以外のオンプレミス サーバーを監視するには、Azure Arc エージェントをインストールする必要があります。 Arc エージェントを使用すると、オンプレミスのサーバを Azure がターゲットにできるリソースとして可視化します。 Azure Arc エージェントのインストールに追加費用は発生しません。

• Azure Monitor エージェントがすべてのニーズに対応できることを確認します。 Azure Monitor エージェントは、データ収集用に一般提供 (GA) となっており、さまざまな Azure Monitor 機能やその他の Azure サービスによるデータ収集に使用されます。

• Azure Monitor エージェントに必要なアクセス許可があることを確認します。 監視するマシンにエージェントをインストールするために必要なアクセス許可が必要です。 詳細については、Azure Monitor エージェントをインストールするために必要なアクセス許可に関するページを参照してください。

大まかなガイダンス

移行を計画して実行するには、次の手順に従ってください。

• 移行しなければならないエージェントとその数を理解します。
• ワークスペースをどのように使用しているかを把握します。
• 構成されているソリューション、分析情報、データ コレクションを理解します。
• データ コレクションを構成し、コレクションを検証します。
• その他の依存関係とサービスについて理解します。
• レガシ エージェントを削除します。

Azure Monitor エージェント移行ヘルパー ブックは、上記の各手順で役立つブックベースの Azure Monitor ソリューションです。 このガイドでは、移行プロセスの各段階でブックとその他のツールを参照します。 詳細については、「Azure Monitor エージェントの移行ヘルパー ブック」を参照してください。

エージェントを理解する

DCR ジェネレーターを使用して、レガシ エージェントの構成を自動的にデータ収集ルールに変換します。¹ エージェントの詳細については、以下の質問を確認してください。

質問	アクション
移行する必要があるエージェントの数はいくつですか?	移行する必要があるエージェントの数を把握します。
Azure の外部にデプロイされているエージェントはありますか? これらのエージェントは、独自のデータ センターまたは別のクラウド環境にデプロイされていますか?	Azure の外部にあるサーバーの場合は、最初に Azure ARC 接続マシン エージェントをデプロイする必要があります。 詳細については、「Azure Connected Machine Agent の概要」を参照してください。
System Center Operations Manager (SCOM) を使用していますか? 今後 SCOM についてどのような計画がありますか?	引き続き SCOM を使用する予定の場合は、SCOM マネージド インスタンスの評価を開始します。 詳細については、SCOM マネージド インスタンスに関するページを参照してください。
現在エージェントをどのようにデプロイしていますか?	何らかの自動化された方法でレガシ エージェントをデプロイしている場合、新しいサーバーの自動デプロイを停止するタイミングを考慮し、新しいエージェントのデプロイに専念してください。 新しいサーバーの自動デプロイを停止すると、移行に必要な労力をそれ以上増やさずに、移行するエージェントの既存のインベントリに集中できるようになります。

Azure Monitor エージェントの移行ヘルパー ブックを使って、移行する必要のあるエージェントの数を把握できます。 詳細については、「Azure Monitor エージェントの移行ヘルパー ブック - エージェント」を参照してください。

ワークスペース、ソリューション、分析情報、データ収集について理解する

移行の前に、Log Analytics ワークスペースがどのように使用されているかを把握します。 それらがすべて使用中かどうか、どのエージェントがどのワークスペースにテレメトリを送信しているか確認します。 多くのワークスペースは長い期間にわたって少しずつ追加され、実際に使用されているワークスペースはどれか、テレメトリの収集に使用されているワークスペースはどれか、どのサーバーから収集しているか分からなくなっている可能性があります。 移行は、ワークスペースをクリーンアップして統合する良い機会となります。

ワークスペースを確認するときは、構成されているソリューションに注意してください。 この情報は、収集するデータとその使用方法を理解するために重要になります。

Azure Monitor エージェントの移行ヘルパー ブックは、使用しているワークスペースと、各ワークスペースに実装されているソリューション、およびソリューションを最後に使用した日時を理解するのに役立ちます。 各ソリューションには、移行に関する推奨事項があります。 詳細については、「Azure Monitor エージェントの移行ヘルパー ブック - ワークスペース」を参照してください

Azure Monitor ワークスペースの監査ブックを使用して、ワークスペースを理解することもできます。 Azure Monitor ワークスペース監査ブックを使用するには、GitHub リポジトリからブックをコピーし、Log Analytics ワークスペースにインポートします。

このブックでは、Log Analytics ワークスペースがすべて収集され、ワークスペースごとに次の内容が表示されます。

• ワークスペースにデータを送信しているすべてのデータ ソース。
• ワークスペースにハートビートを送信しているエージェント。
• ワークスペースにデータを送信しているリソース。
• ワークスペースにデータを送信している Application Insights リソース。

詳細については、Azure Monitor ワークスペース監査ブックに関するページを参照してください。

データ コレクションを構成してコレクションを検証する

データ コレクションを構成する場合は、次の手順を検討してください。

• このプロセスに使用できるサーバーのパイロット グループを特定します。 大規模にデプロイする前に、パイロット サーバーを使用してデータを検証します。

• DCR 構成ジェネレーターを使用して、ワークスペースで構成されているデータ コレクションを変換し、それらをデータ収集ルールとして環境にデプロイします。 DCR 構成ジェネレーターの詳細については、DCR 構成ジェネレーターに関するページを参照してください。

• VM Insights または Azure Monitor for Virtual Machines を Azure Monitor エージェントに移行します。 移行前に収集されたものと比較して、サーバーのパイロット グループの移行されたデータ コレクションを検証します。 二重のインジェストを回避するために、レガシ エージェントのワークスペース構成を削除して、エージェントをアンインストールせずに、テスト フェーズ中にレガシ エージェントからのデータ収集を無効にすることができます。 詳細については、Azure Monitor の Log Analytics エージェント データ ソースに関するページを参照してください

• 新しいデータを検証して、ギャップがないことを確認します。 レガシ エージェントによって取り込まれたデータと Azure Monitor エージェントのデータを比較します。 KQL を使用して、エージェントの種類に基づいて各エージェントの同等のデータを比較します。

• Azure Policy を使用した大規模なデプロイを計画します。 組み込みポリシーを使用して、拡張機能と DCR の関連付けを大規模にデプロイします。 また、ポリシーを使用すると、新しいマシンに拡張機能と DCR の関連付けを自動的にデプロイできます。 大規模なデプロイの詳細については、「Azure Monitor エージェントの管理 - Azure Policy を使用する」を参照してください。

その他の依存関係とサービスについて理解する

移行の前に、他のサービスがどのように影響を受けるかを理解しておくことが重要です。

サービス	影響
更新管理	Azure Automation で Update Management を使用している場合は、Azure Update Manager に移行する必要があります。 Azure Update Manager には独自のエージェントがあり、Azure Monitor エージェントから切り離されています。 Update Management は、2024 年 8 月末に非推奨となる予定です。 Azure Update Manager に移行することをお勧めします。 詳細については、「Automation Update Management から Azure Update Manager へ移行する」を参照してください。 AMA 移行ヘルパー ブックには、Update Management ソリューションを使用しているマシンとその移行方法が示されています。 詳細については、Azure Monitor エージェントの移行ヘルパー ブックの Update Management に関するページを参照してください。
変更履歴とインベントリ	変更履歴とインベントリを使用している場合は、Azure Automation に移行する必要があります。 変更履歴とインベントリは、Azure Automation の一部でもあります。 Azure Monitor エージェントには変更追跡とインベントリ ソリューションが含まれますが、データ収集ルールを作成する必要があります。 詳細については、「Azure Monitoring Agent を使用して変更履歴とインベントリを管理する」を参照してください。
Defender for Cloud	サービスまたは Defender for Servers に Defender for Cloud を使用していて、サーバーに対して P2 を有効にしているか、P2 を有効にする予定がある場合は、Defender for Cloud でのエージェントのデプロイをレガシ エージェントのデプロイからエージェントレス スキャンに変更します。 Defender for Cloud を使用してセキュリティ イベントを収集する場合は、それらのイベントを収集するカスタム データ収集ルールを作成します。
Microsoft Sentinel	Microsoft Sentinel を使用している場合、レガシ エージェントを使用していたソリューションは Azure Monitor エージェント ベースのソリューションに変換され、更新できます。

レガシ エージェントを削除する

移行計画の一環として、データ収集の重複を避けるために、移行が完了したらレガシ エージェントを削除することを計画します。

どのマシンでも MMA を保持する必要がない場合は、MMA 検出および削除ツールを使用してまとめて大規模にエージェントを削除します。 MMA 検出および削除ツールの詳細については、MMA 検出および削除ツールに関するページを参照してください。

ただし、System Center Operations Manager (SCOM) を使用している場合は、System Center Operations Manager で引き続き管理するマシンに MMA エージェントをデプロイしたままにします。

SCOM 管理者用の管理パックが存在します。これは、SCOM 管理グループの構成を保持しながら、まとめて大規模にワークスペース構成を削除するのに役立ちます。 SCOM 管理者用の管理パックの詳細については、SCOM 管理者用の管理パックに関するページを参照してください。

移行に影響する可能性がある既知のパリティ ギャップ

• IIS ログ: IIS ログ収集が有効になっている場合、AMA によって W3CIISLog テーブルの sSiteName 列が設定されない可能性があります。 このフィールドは、レガシ エージェントに対して IIS ログ収集が有効になっている場合に、既定で収集されます。 AMA を使用して sSiteName フィールドを収集する必要がある場合は、IIS の W3C ログで Service Name (s-sitename) フィールドを有効にします。 このフィールドを有効にする手順については、ログに記録する W3C フィールドの選択に関する記事を参照してください。

• Sentinel: Windows ファイアウォール ログはまだ一般公開 (GA) されていません。

• SQL Assessment ソリューション: これは、SQL ベスト プラクティス アセスメントに含まれるようになりました。 デプロイ ポリシーには、サブスクリプションごとに 1 つの Log Analytics ワークスペースが必要です。これは、AMA チームによって推奨されているベスト プラクティスではありません。

• Microsoft Defender for Cloud: 新しいエージェントレス ソリューションの一部の機能は開発中です。 File Integrity Monitoring (FIM)、エンドポイント保護検出の推奨事項、OS の構成ミス (Azure Security Benchmark (ASB) の推奨事項)、適応型アプリケーション制御を使用している場合、移行に影響する場合があります。

• Container Insights: Windows バージョンはパブリック プレビュー段階です。

次のステップ

• Azure Monitor エージェント移行ヘルパー ブック
• DCR 構成ジェネレーター
• MMA 検出および削除ツール