System Center Operations Manager (SCOM) から Azure Monitor に移行する

  • [アーティクル]

この記事では、System Center Operations Manager (SCOM) を現在使用しており、ビジネス アプリケーションやその他のリソースを Azure に移行する際に Azure Monitor を使用したクラウドベースの監視への移行を計画しているお客様に向けたガイダンスを提供します。

SCOM から移行するための標準的なプロセスはなく、迅速な移行を実行するのではなく、SCOM 管理パックに長期間依存する場合があります。 この記事では、お使いの特定の環境に最適な戦略を決定するために、使用できるさまざまなオプションと決定基準について説明します。

ハイブリッド クラウドの監視

ほとんどのお客様は、クラウドへの段階的な移行を可能にするハイブリッド クラウド監視の戦略を採用しています。 この手法では、新しいプラットフォームに慣れながら既存のビジネス プロセスを維持できます。 SCOM の機能から離れるのは、Azure Monitor に置き換え可能になったときです。 複数の監視ツールにより複雑さが増しますが、次世代のクラウド ワークロードを監視する Azure Monitor の機能を活用しながら、サーバー ソフトウェアとワークロードを監視する SCOM の機能を維持できます。

いずれかのコンポーネントを Azure に移行する前の環境は、オンプレミスに配置されているか、マネージド サービス プロバイダーによって配置された、仮想マシンや物理マシンに基づいています。 これは、SCOM に頼って、物理サーバーやネットワークなど、環境内のビジネス アプリケーション、サーバー ソフトウェア、およびその他のインフラストラクチャ コンポーネントを監視しています。 IIS、SQL Server、さまざまなベンダー ソフトウェアなどのサーバー ソフトウェアには、標準の管理パックを使用し、特定の要件に合わせてこれらの管理パックに調整を加えます。 既存の管理パックで監視できないビジネス アプリケーションおよびコンポーネント用のカスタム管理パックを作成し、さらにビジネス プロセスをサポートするように SCOM を構成します。

サービスをクラウドに移行すると、Azure Monitor は各リソースのプラットフォーム メトリックとアクティビティ ログの収集を開始します。 診断設定を作成してリソース ログを収集し、ログ クエリと分析情報を使用して使用可能なすべてのテレメトリを対話形式で分析できるようにします。

この移行期間中には、2 つの独立した監視ツールがあります。 Azure portal で分析情報とブックを使用してクラウド テレメトリを分析しながら、オペレーション コンソールを使用して SCOM によって収集されたデータを分析します。 各システムには独自のアラートがあるため、SCOM の通知グループと同等のアクション グループを Azure Monitor で作成する必要があります。

次の表では、SCOM と Azure Monitor を使用したハイブリッド監視環境で使用できるさまざまな機能と戦略について説明します。

メソッド 説明
デュアルホーム エージェント SCOM は、Azure Monitor で使用される Log Analytics エージェント と同じ Microsoft 管理エージェント (MMA) を使用します。 SCOM と Azure Monitor の両方に 1 台のマシンを同時に接続するように、このエージェントを構成できます。 この構成では、Azure VM がオンプレミスの管理サーバーに接続されている必要があります。

Log Analytics エージェントは Azure Monitor エージェントに置き換えられました。これにより、管理の簡素化やデータ収集の制御の向上など、大きな利点が得られます。 2 つのエージェントを同じマシン上に共存させ、Azure Monitor と SCOM の両方に接続できます。 この構成は、Azure Monitor エージェントの大きな利点を得られるため、レガシ エージェントをデュアルホームするよりも優れたオプションです。
接続された管理グループ SCOM 管理グループを Azure Monitor に接続して、SCOM エージェントから収集されたデータを Azure Monitor に転送します。 これはデュアルホーム エージェントの使用に似ていますが、各エージェントを Azure Monitor に接続するように構成する必要はありません。 この戦略にはレガシ エージェントが必要であるため、データ収集ルールを使用して監視を指定することはできません。 また、各 VM を Azure Monitor に直接接続しない限り、VM 分析情報を使用することはできません。
SCOM マネージド インスタンス (プレビュー) SCOM マネージド インスタンス (プレビュー) は、Azure で SCOM を完全に実装したものであり、オンプレミスの SCOM 環境で実行するのと同じ管理パックを引き続き実行できるようにします。 現在 SCOM と Azure Monitor からのデータとアラートの間に統合はなく、正常性とアラートを分析するために引き続き同じオペレーション コンソールを使用します。

SCOM MI は、既存の SCOM 環境とデュアル ホーム エージェントを維持することに似ていますが、Azure で監視構成を統合し、データベースや管理サーバーなどのオンプレミス コンポーネントを廃止することができます。 Azure VM のエージェントは、独自のデータ センターの管理サーバーに接続する代わりに、Azure の SCOM マネージド インスタンスに接続できます。
Azure 管理パック Azure 管理パックを使用すると、Operations Manager で、特定の監視シナリオのセットに基づいて Azure リソースを検出し、それらの正常性を監視できます。 この管理パックでは、Azure のリソースごとに追加の構成を実行する必要があります。 ただし、Azure Monitor に焦点を置くようにビジネス プロセスを進化させるまでは、オペレーション コンソールで Azure リソースの一定の可視化を実現するのに役立ちます。

ビジネス アプリケーションを監視する

一般に、各仮想マシンにインストールされるエージェントを利用して SCOM でビジネス アプリケーションを監視するには、カスタム管理パックが必要です。 Azure Monitor の Application Insights では、Web ベースのアプリケーションが Azure、他のクラウド、オンプレミスのいずれにあるかにかかわらず監視できます。 これは、アプリケーションが Azure に移行されているかどうかに関係なく、すべてのアプリケーションに対して使用できます。

ビジネス アプリケーションの監視が、SCOM の .NET アプリのパフォーマンス テンプレートによって提供される機能に限定されている場合は、機能を失うことなく Application Insights に移行できる可能性が高くなります。 実際、Application Insights には、以下のように非常に多くのその他の機能が用意されています。

  • アプリケーション コンポーネントを自動的に検出して監視します。
  • アプリケーションの使用状況とパフォーマンスに関する詳細なデータ (応答時間、失敗率、要求率など) を収集します。
  • ページ ビューや読み込みパフォーマンスなどのブラウザー データを収集します。
  • 例外を検出し、スタック トレースと関連する要求の詳細を表示します。
  • 分散トレースやスマート検出などの機能を使用して、高度な分析を実行します。
  • メトリックス エクスプローラーを使用して、パフォーマンス データを対話形式で分析します。
  • ログ クエリを使用して、収集されたテレメトリを、Azure サービスおよび VM insights 用に収集されたデータと一緒に、対話形式で分析します。

ただし特定のシナリオでは、必要な機能を実現できるまで、Application Insights に加えて SCOM の使用を続ける必要がある場合があります。 SCOM を使い続ける必要がある場合の例には、以下が含まれます。

  • アプリケーションの可用性と応答性を監視してアラートを送信できるようにする可用性テストを行うには、Web テスト エージェントの IP アドレスからの受信要求が必要です。 このようなアクセスがポリシーで許可されない場合は、SCOM で Web アプリケーションの可用性モニターを使い続けることが必要な可能性があります。
  • SCOM では、可用性テストのポーリング間隔を設定できます。多くのお客様は、60 から 120 秒ごとに検査を行っています。 Application Insights の最小ポーリング間隔は 5 分のため、一部のお客様にとっては長すぎる場合があります。
  • SCOM では、アプリケーションによって生成されたイベントを収集し、ローカル エージェントでスクリプトを実行することで、膨大な量の監視が実行されます。 Application Insights では、これらは標準オプションではないため、ビジネス要件を満たすためにカスタムの作業が必要になる場合があります。 これには、Log Analytics ワークスペースに格納されているイベント データを使用したカスタム アラート ルールと、ハイブリッド runbook worker を使用して仮想マシンのゲストで起動されるスクリプトが含まれる場合があります。
  • アプリケーションが記述されている言語によっては、Application Insights で使用できるインストルメンテーションが限られる場合があります。

このガイドの他のセクションの基本的方針に従って、ビジネス アプリケーションについては引き続き SCOM を使用しますが、Application Insights によって提供される追加の機能を活用します。 重要な機能を Azure Monitor に置き換えることができるため、インベントリからのカスタム管理パックの削除を開始できます。

仮想マシンの監視

ハイブリッド環境で仮想マシンのソフトウェアを監視するには、VM で実行されるワークロードの要件に応じて、多くの場合 Azure Monitor と SCOM の組み合わせを使用します。 Azure で仮想マシンが作成されるとすぐに、VM ホストのプラットフォーム メトリックとアクティビティ ログの収集が自動的に開始されます。 推奨されるアラートを有効にして、サーバーの停止や高い CPU 使用率など、VM ホストの一般的なエラーの通知を受け取るようにします。

VM 分析情報を有効にして Azure Monitor エージェントをインストールし、クライアント オペレーティング システムから一般的なパフォーマンス データの収集を開始します。 これは、SCOM で既に収集している一部のデータと重複する可能性がありますが、時間の経過と共に傾向を確認し、Azure VM を他のクラウド リソースと共に監視することができるようになります。 また、マップ機能を有効にすることもできます。これにより、仮想マシンで実行されているプロセスとその他のサービスへの依存関係に関する分析情報が得られます。

Azure Monitor の他の機能では提供できない機能については、引き続き管理パックを使用します。 これには、IIS、SQL Server、Exchange などの重要なサーバー ソフトウェア用の管理パックが含まれます。 Azure Monitor ではアクセスできない、オンプレミスのインフラストラクチャ用に開発されたカスタム管理パックがある可能性もあります。 また、SCOM が運用プロセスに緊密に統合されている場合は、Azure Monitor やその他の Azure サービスで拡張または置き換えが可能になるようにサービス操作を移行して最新化できるまで、引き続き SCOM を使用します。

Note

Azure Monitor エージェントではなく Log Analytics エージェントを使用して VM 分析情報を有効にした場合、VM に追加のエージェントをインストールする必要はありません。 ただし、クラウドでの VM の監視が大幅に改善されているため、Azure Monitor エージェントをお勧めします。 複数のエージェントを維持することの複雑さは、管理パックを設計するための戦略と同様に、さまざまな VM セットに対して異なるデータ収集を構成できるデータ収集ルールで監視を定義できることによって相殺されます。

VM ワークロード用の管理パック ロジックを移行する

SCOM 管理パックを Azure Monitor に変換するための移行ツールはありません。そのロジックが Azure Monitor のデータ収集とは根本的に異なるためです。 管理パックのロジックを移行する場合、通常、SCOM によって収集されたデータを分析し、Azure Monitor によって複製できる監視シナリオを特定することに重点を置きます。 Azure Monitor をカスタマイズして、さまざまなアプリケーションやコンポーネントの要件を満たしながら、SCOM のさまざまな管理パックおよびレガシ エージェントを廃止していくことができます。

SCOM の管理パックには、データの収集と結果のアラートを 1 つのエンド ツー エンド ワークフローに結合するルールとモニターが含まれています。 SCOM によって既に収集されているデータは、アラートに使用されることはほとんどありません。 Azure Monitor では、データ収集とアラートを個別のプロセスに分割します。 アラート ルールは、エージェントから既に収集されている Azure Monitor ログと Azure Monitor メトリックのデータにアクセスします。 また、ルールとモニターは、通常、特定のイベントやパフォーマンス カウンターなどの具体的なデータに焦点を当てています。 通常、Azure Monitor のデータ収集ルールは、1 つの DCR で複数のイベント セットとパフォーマンス カウンターを収集する方が広範です。

一般的な監視シナリオのデータ収集とアラートの作成に関するガイダンスについては、次のコンテンツを参照してください。

管理パックの機能全体を複製するのではなく、それぞれによって提供される重要な監視を分析してください。 代替手段を使用してそれらの監視要件を複製できるかどうかを判断します。 多くの場合、特定の管理パックを廃止することができる十分な機能をレプリケートするデータ収集とアラート ルールを Azure Monitor で構成できます。 管理パックには、多くの場合、数百から数千のルールとモニターが含まれていることがあります。

1 つの戦略は、環境内でアラートがトリガーされたモニターとルールに焦点を当てることです。 アラートや最も頻度の高いアラートなどの Operations Manager で使用できる既存のレポートを参照してください。これは、時間の経過とともにアラートを識別するために役立ちます。 Operations データベースで次のクエリを実行して、最新の最も頻度の高いアラートを評価することもできます。

select AlertName, COUNT(AlertName) as 'Total Alerts' from
Alert.vAlertResolutionState ars
inner join Alert.vAlertDetail adt on ars.AlertGuid = adt.AlertGuid
inner join Alert.vAlert alt on ars.AlertGuid = alt.AlertGuid
group by AlertName
order by 'Total Alerts' DESC

出力を評価して、移行する特定のアラートを識別します。 調整されたアラート、または問題があることがわかっているアラートは無視します。 管理パックを確認して、発生したことがない重要なアラートを識別します。

代理トランザクション

管理パックでは、多くの場合、コンピューター上で実行されているアプリケーションまたはサービスに接続する代理トランザクションを使用して、ユーザー接続または実際のユーザー トラフィックをシミュレートします。 アプリケーションが使用可能な場合は、そのマシンが正常に実行されていると見なすことができます。 Azure Monitor の Application Insights 可用性テストによって、この機能が提供されます。 これは、インターネットからアクセスできるアプリケーションに対してのみ機能します。 内部アプリケーションの場合、テストを実行する特定の Microsoft URL からのアクセスを許可するように、ファイアウォールを開く必要があります。 または、既存の管理パックを引き続き使用できます。

次の手順