SCOM -構成情報が高頻度で更新される現象について技術情報が公開されました。
日本マイクロソフト System Center Support Team の宮崎です。今回は System Center Operations Manager 2007 (以下、SCOM) の構成情報が高頻度で更新される現象について技術情報を紹介します。
この現象は、Configuration Churn と呼ばれています。 SCOM の構成情報が高頻度で更新されることにより、SCOM エージェントが最新の構成情報を安定して受信できなくなる状態のことを指します。この状態に陥ると、実施した監視定義の変更が反映されないことで、エージェントが以前の設定のまま動き続けることになります。またこの状態が長く続くと、コンソール上でエージェントが無効な状態 (グレー表示) になります。
このように SCOM の正常な動作を妨げる可能性のある Configuration Churn について、以下の技術情報が公開されました。
"How to detect and troubleshoot frequent configuration changes in Operations Manager "
https://support.microsoft.com/kb/2603913/
詳細については上記のサイトをご参照頂ければと思いますが、ここでは簡単に概要をまとめておきます。
- Configuration Churn の発生原因
構成情報の頻繁な更新は、以下のような状況において発生します。
a. オブジェクト検出ルールが高頻度で実行されている。
b. オブジェクト検出ルールによって検出されるオブジェクトのプロパティが、検出ルールの実行頻度と同程度もしくはそれよりも高頻度で更新されている。
オブジェクト検出ルールの定義は、[作成] タブの [管理パック オブジェクト] - [オブジェクト検出] ノードで確認することが出来ます。また通常の場合には、そこからルールのプロパティを開いて [構成] タブを見れば、ルールの実行頻度を確認することが出来ます。一般的にオブジェクト検出ルールの実行頻度を 1 時間よりも低く設定することはあまりありませんが、これを 5 分や 10 分間隔に設定した場合が、a. の状況になります。
またオブジェクト検出ルールは、名前の通り SQL Server や IIS Server 、論理ディスクといった、監視対象となるオブジェクトを検出します。この際には、併せてインスタンス名や ID 、作成者などのプロパティも検出します。最初にオブジェクトを検出したタイミングではこれらすべての情報が管理サーバーに報告されますが、その後のルール実行時にいずれかのプロパティが更新されていると、再度すべての情報が管理サーバーに報告されます。
例えば論理ディスクの空き容量をプロパティに設定していた場合、頻繁に書き込みや削除が発生するディスクではルールが実行されるたびにプロパティの値が変わるため、b. の状況に陥ることになります。
多数のエージェントでこれら a. 、b. いずれかの状況もしくは両方の状況に陥っており、管理サーバーが高負荷な状態になっている時に、Configuration Churn が発生します。
- Configuration Churn が発生していることの確認方法
構成情報が正常に処理されている場合、管理サーバー上の Operations Manager イベント ログには ID 21024 のイベントと、それに続く ID 21025 もしくは ID 21026 のイベントが 1 時間に数回記録されます。これに対し Configuration Churn が発生している場合には、ID 21024 のイベントのみが連続して記録されます。この点を確認することにより、Configuration Churn が発生しているか否かを判断することができます。詳細については、技術情報の "Identifying configuration churn by using the MS event log" を参照してください。
- 原因の特定方法について
以下の方法で Configuration Churn の原因となっているオブジェクト検出ルールを特定できる可能性があります。なおこの方法を実行するためには、Operations Manager Reporting をインストールしてある必要があります。
A. クエリを用いる方法
==========================
以下のクエリを実行することで、過去 24 時間にオブジェクトを検出したルールの一覧とルールの内部 ID 、ルールによって検出されたオブジェクトの数が列挙されます。
-------------------------
Use OperationsManagerDW
select ManagedEntityTypeSystemName, DiscoverySystemName, count(*) As 'Changes'
from (select distinct MP.ManagementPackSystemName, MET.ManagedEntityTypeSystemName, PropertySystemName, D.DiscoverySystemName, D.DiscoveryDefaultName, MET1.ManagedEntityTypeSystemName As 'TargetTypeSystemName', MET1.ManagedEntityTypeDefaultName 'TargetTypeDefaultName', ME.Path, ME.Name, C.OldValue, C.NewValue, C.ChangeDateTime
from dbo.vManagedEntityPropertyChange C
inner join dbo.vManagedEntity ME on ME.ManagedEntityRowId=C.ManagedEntityRowId
inner join dbo.vManagedEntityTypeProperty METP on METP.PropertyGuid=C.PropertyGuid
inner join dbo.vManagedEntityType MET on MET.ManagedEntityTypeRowId=ME.ManagedEntityTypeRowId
inner join dbo.vManagementPack MP on MP.ManagementPackRowId=MET.ManagementPackRowId
inner join dbo.vManagementPackVersion MPV on MPV.ManagementPackRowId=MP.ManagementPackRowId
left join dbo.vDiscoveryManagementPackVersion DMP
on DMP.ManagementPackVersionRowId=MPV.ManagementPackVersionRowId AND CAST(DefinitionXml.query('data(/Discovery/DiscoveryTypes/DiscoveryClass/@TypeID)') AS nvarchar(max)) like '%'+MET.ManagedEntityTypeSystemName+'%'
left join dbo.vManagedEntityType MET1 on MET1.ManagedEntityTypeRowId=DMP.TargetManagedEntityTypeRowId
left join dbo.vDiscovery D on D.DiscoveryRowId=DMP.DiscoveryRowId
where ChangeDateTime > dateadd(hh,-24,getutcdate()) ) As #T group by ManagedEntityTypeSystemName, DiscoverySystemName order by count(*) DESC
-------------------------
また以下のクエリを実行することで、過去 24 時間に更新されたオブジェクトのプロパティが列挙されます。
-------------------------
Use OperationsManagerDW
select distinct MP.ManagementPackSystemName, MET.ManagedEntityTypeSystemName, PropertySystemName, D.DiscoverySystemName, D.DiscoveryDefaultName, MET1.ManagedEntityTypeSystemName As 'TargetTypeSystemName', MET1.ManagedEntityTypeDefaultName 'TargetTypeDefaultName', ME.Path, ME.Name, C.OldValue, C.NewValue, C.ChangeDateTime
from dbo.vManagedEntityPropertyChange C
inner join dbo.vManagedEntity ME on ME.ManagedEntityRowId=C.ManagedEntityRowId
inner join dbo.vManagedEntityTypeProperty METP on METP.PropertyGuid=C.PropertyGuid
inner join dbo.vManagedEntityType MET on MET.ManagedEntityTypeRowId=ME.ManagedEntityTypeRowId
inner join dbo.vManagementPack MP on MP.ManagementPackRowId=MET.ManagementPackRowId
inner join dbo.vManagementPackVersion MPV on MPV.ManagementPackRowId=MP.ManagementPackRowId
left join dbo.vDiscoveryManagementPackVersion DMP on DMP.ManagementPackVersionRowId=MPV.ManagementPackVersionRowId AND CAST(DefinitionXml.query('data(/Discovery/DiscoveryTypes/DiscoveryClass/@TypeID)') AS nvarchar(max)) like '%'+MET.ManagedEntityTypeSystemName+'%'
left join dbo.vManagedEntityType MET1 on MET1.ManagedEntityTypeRowId=DMP.TargetManagedEntityTypeRowId
left join dbo.vDiscovery D on D.DiscoveryRowId=DMP.DiscoveryRowId
where ChangeDateTime > dateadd(hh,-24,getutcdate()) ORDER BY MP.ManagementPackSystemName, MET.ManagedEntityTypeSystemName
-------------------------
B. レポートを用いる方法
==========================
System Center Core Monitoring Reports に含まれる "Data Volume by Management Pack report" と "Data Volume by Workflow and Instance report" を用いることにより、Configuration Churn の原因となっているルールやエージェントを特定することが出来ます。
- Configuration Churn を抑止する方法
以下の方法で、Configuration Churn の発生を抑止できる可能性があります。
a. 最新の管理パックを利用する。
b. オブジェクト検出ルールの実行周期を上書きで変更する。
c. 頻繁に更新されるプロパティを検出しないように、オブジェクト検出ルールの定義を変更する。
d. こちらのブログに記載している方法で、管理サーバーのパフォーマンスを改善する。
これらのうち a. や b. は、公開されている管理パックに含まれているルールに適用することが出来ます。また c. の方法については、ユーザーが独自に定義したルールに適用することが出来ます。
最初にも書いたとおり、Configuration Churn が発生すると SCOM の監視が正常に動作しなくなります。もし起きた場合には、今回紹介した方法に基づいて切り分けや対処を実施してもらえればと思います。
コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。