みなさん、こんにちは。
System Center Support チームです。
今日は System Center Operations Manager（以下、SCOM） が監視のために利用するプロセスである MonitoringHost.exe が消費する仮想メモリ量が増大する話についてお伝えしようと思います。
ここ数ヶ月のうちに何度かお問い合わせをいただきましたため、改めて Blog でも案内し少しでも多くのお客様に知っていただければと思っています。
事象
突然、SCOM の管理サーバーやエージェントが導入されているマシンにてプロセスが異常にメモリを消費し、マシンがダウンするといった事象が発生することがあります。
その場合、イベント ログ [System] に以下が記録されることを確認しています。
- イベントの例
ログの名前：System
日時：2018/1/28 22:49
ソース：Resource-Exhaustion-Detector
レベル：警告
タスクのカテゴリ：リソース消費診断イベント
イベント ID：2004
ユーザー：NT AUTHORITYSYSTEM
コンピュータ：hyperv01.contoso.com
説明：Windows は仮想メモリの不足状態を診断しました。仮想メモリを多く消費したのは次のプログラムです:
MonitoringHost.exe (2996) は 284310507520 バイトを消費し、WmiPrvSE.exe (2784) は 369664000 バイトを消費し、svchost.exe (1744) は 212021248 バイトを消費しました。
上記のイベントではプロセス MonitoringHost.exe が 約264GB の仮想メモリを使用していることを示しています。
このイベントが記録されるタイミングでまた、SCOM に関するイベント ログ [Operations Manager] には同時にイベント ID：26008 がかなりの頻度で記録されていることも確認しています。
過去お問い合わせを頂いたお客様では、具体的な頻度の度合いは数秒で2000～3000件というかなりの頻度です。
- イベントの例
ソース：Health Service Modules
日時：2018/1/29 7:52:25
イベントID：26008
Level：エラー
コンピュータ名：hyperv01.contoso.com
説明：コンピューター 'hyperv01.contoso.com' の Operations Manager イベント ログは壊れた状態のままです。イベント ログ プロバイダーが、問題があると思われるレコードをスキップすることによって回復を試みます。
最大 2 つのレコードがスキップされる可能性があります。
1 つ以上のワークフローがこの影響を受けました。
ワークフロー名: Microsoft.SystemCenter.Apm.Infrastructure.Monitoring.ApmAgent.APMConfigurationConflict.Monitor
インスタンス名: hyperv01.contoso.com
インスタンス ID: {8E315A0A-DFFD-8341-6461-A4A561E0F2D}
管理グループ: SCOM
上記のイベントが記録されている状態はプロセス MonitoringHost.exe が仮想メモリを異常に消費していまう状況が発生しており、OS 上の仮想メモリを枯渇させてしまい再起動するしか方法が対処方法がありません。
この事象の問題や要因を説明します。
要因
こちらの問題は SCOM の管理サーバーやエージェントが利用するアクション アカウントが関連します。
SCOM は管理サーバーやエージェント上で監視を行う際に実行される処理はこのアクション アカウントによって実行される仕組みを取っているのですが、このアクション アカウントと同じアカウントを利用して OS 上で操作を行いログオフを実施すると今回の事象が発生することを確認しています。
これは OS 上でアクション アカウントと同じアカウントの操作によってログオフが実施されると User Profile がアンロードされるために発生します。
アクション アカウントでの監視はユーザーによるログオフ操作が実施されたあとも継続するため、User Profile をロードしようとします。
しかし、すでにログオフ操作のためアンロードされてしまっているためアクション アカウントは User Profile のロードを正常に行うことができず、エラーとなります。
このエラーが繰り返し発生し、エラー時に増加するヒープ領域が仮想メモリの領域を圧迫します。
仮想メモリの領域が圧迫されますと、上記のイベント ID：2004 が記録されます。
発生までの流れは以下です。
～～発生のプロセス～～
1. SCOM 管理サーバーやエージェントで利用するアカウントがアンロードされた User Profile に含まれていたレジストリ キーにアクセスしようとする。
2. アクセスが失敗し、エラーに関連する情報がヒープ領域に格納される。
3. SCOM 管理サーバーやエージェントで利用するアカウントが繰り返しレジストリ キーへのアクセスを実行し、エラーの情報がヒープに格納され続ける。
4. ヒープ領域が肥大化する。
5. 仮想メモリが枯渇する。
この挙動は SCOM 含めた COM+ アプリケーションの実装では想定されている動作でもありますため、お客様環境にてこういった状況とならないよう事前にご利用いただくアカウントについてご確認いただく必要がございます。
対処策
この事象を回避いただくための対処方法は至って単純です。
それは SCOM の管理サーバーやアクション アカウントに使用しているアカウントと OS 上へとログオン/ログオフするアカウントを異なるものに変更するだけです。
SCOM の場合ですとアクション アカウントに ローカル システム アカウントを利用することが可能ですので、アカウントを基本的にローカル システム アカウントへと変更していただく、という運用が一番シンプルです。
しかし、ローカル システム アカウントの場合ですと権限が Administrator と同等ですので、SCOM のプロセスが悪用されるリスクがあります。
それを考慮した場合、ドメインのアカウントを指定するほうがリスクは小さくなります。
しかし、どのアカウントを利用するかはお客様の運用ポリシーに依存する部分でもありますので検討の上、アカウントを決定してください。
SCOM のアクション アカウントにご利用いただくための権限については以下に公開情報があるのでご覧ください。
- 公開情報
サービス、ユーザー、およびセキュリティ アカウント
https://docs.microsoft.com/ja-jp/system-center/scom/plan-security-accounts?view=sc-om-2016
※SCOM 2016 の情報ですが、SCOM 2012/2012 SP1/2012 R2、SCOM 2007/2007 R2 でも同様です。
今の環境でこの Blog で案内している事象が発生する可能性があるか、というのは以下の手順で SCOM のアクション アカウントを確認してください。
以下の手順ではアクション アカウントに指定されているアカウントを確認していただき、そのアカウントがログオン/ログオフを実施するアカウントであるか確認できます。
<<確認手順>>
以下の手順にてエージェントのアクション アカウントをご確認が可能です。
1. SCOM 管理コンソールを起動し、[管理] ペインを開きます。
2. 左ペインの [プロファイル] をクリックします。
3. 一覧から [既定のアクション アカウント] をダブルクリックします。
4. ウィザード画面上で、[次へ] をクリックします。
5. 全般プロパティ画面にて [次へ] をクリックします。
6. 実行アカウント画面に一覧から、問題が発生している SCOM 管理サーバー や SCOM エージェントに設定されているアカウント名を確認します。
手順は以上です。
アクション アカウントとログオン/ログオフに使用しているアカウントが同じ場合はどちらかのアカウントを変更してください。
<<注意>>
もし、問題が発生しているサーバー上のアプリケーションの監視 (Exchange サーバーや SharePoint サーバー等の監視等) において、別途アプリケーション監視用の実行プロファイルに実行アカウントを設定している場合には、そちらも併せてご確認下さい。