Operations Manager 2007 で頻繁に発生する構成変更を検出してトラブルシューティングする方法

詳細

構成の概要

System Center Management Configuration サービスには、Operations Manager 2007 管理グループのあらゆるヘルス サービスの構成を計算する役割があります。ヘルス サービスの構成は、ヘルス サービスと、ヘルス サービスが監視するすべてのインスタンスに関する、ルール、モニター、検出、およびタスクから成り立っています。

各ヘルス サービスに必要なすべての構成を計算するために、Management Configuration サービスには以下の項目の一覧が必要です。
  • 監視されるすべてのクラスのすべてのインスタンス
  • インスタンス間のホスティングの関係
  • 監視されるクラスに割り当てられるルール、モニター、検出、およびその他のワークフロー
  • インスタンスを監視する役割があるヘルス サービス
さらに、Management Configuration サービスには、管理グループのすべてのインスタンス グループのメンバーシップを読み取る機能が必要です。また、Management Configuration サービスには、これらのグループ、クラス、また個別のインスタンスを対象とするルールとモニターに関する上書きを適用する必要もあります。

管理グループのオブジェクトは、検出ワークフローにより送信される検出データに基づいて、監視されるクラスのインスタンスとして定義されます。オブジェクトのキー プロパティが変更されると、そのオブジェクトは監視されるクラスの新しいインスタンスとして追加される場合があります。追加されない場合、そのオブジェクトはそのクラスのインスタンスとは見なされなくなります。

オブジェクトがメンバーであるクラスで一覧が変更されると、そのオブジェクトを監視するヘルス サービスの構成も変更されます。ルール、モニター、検出、タスク、および上書きが以前の構成に追加されるか、以前の構成から削除されると、このような変更が発生します。

構成チャーン

以下の状況では、エージェントは安定した構成を受信できない場合があります。
  • Management Configuration サービスに大量の検出データが送信される。
  • 追加の検出データが送信される前に、Management Configuration サービスが処理する検出データの送信が速すぎる。このような状況は、データが常に計算処理中であるために発生します。
検出データの頻繁な送信は、"構成チャーン" とも呼ばれ、一部のヘルス サービスが古い構成の下で実行されたり、管理サーバーの構成が古くなったりする原因になる可能性があります。その後、この動作は、一部のヘルス サービスがオペレーション コンソールで淡色表示される (使用不可になる) 原因になります。

検出ワークフローが実行されると、ヘルス サービスにより検出データが送信されます。管理グループに新しい管理パックを導入すると、各エージェントで複数の検出ワークフローが実行される原因になる可能性があります。また、新しいインスタンスが検出されると、一部のエージェントで追加の検出が実行される場合があります。グループ、上書き、およびその他のワークフローに対する変更により、エージェント上で検出ワークフローが実行される可能性があります。さらに、新しいエージェントを導入すると、Management Configuration サービスが新しいエージェントの構成を使用してインスタンス空間を更新する原因になることもあります。

以下の状況では、Configuration Management サービスは、ヘルス サービスの構成を頻繁に再計算することを強制されます。
  • 検出ワークフローの構成の実行頻度が高すぎる。
  • 検出ワークフローが実行されるたびに、ワークフローにより検出されるプロパティが変更される。
上記の状況が多くのエージェントで発生しているか、既にルート管理サーバー (RMS) の負荷が高い場合、Configuration Management サービスは変更の速度に対応できず、構成チャーンが発生することがあります。

RMS イベント ログを使用した構成チャーンの特定

RMS 上の Operations Manager イベント ログ内の以下のようなイベントは、新しい検出データが原因で管理グループの構成が変更されたことを示しています。

以下のようなイベントは、新しいデータに基づいて、Management Configuration サービスで新しい検出データの処理が完了し、管理グループの構成に必要なすべての変更が計算されたことを示しています。

一般的な環境では、すべての 21024 の後に 21025 が続く必要があります。検出データにより構成データが変更されていない場合、代わりにイベント ID は 21026 になります。大規模な管理グループでは、1 時間に数回 21024 イベントと 21025 イベントまたは 21026 イベントのペアが発生すると想定されます。対応する 21025 イベントまたは 21026 イベントのない 21024 イベントから成る長い文字列は、構成チャーンの兆候です。また、イベント ログに、チャーンが検出されたことを示す次のイベントが表示される場合があります。

データ アクセス層は、データ アクセス層が変更を照会したときに複数のテーブルを読み取る必要があります。いずれかのテーブルが、そのテーブルが読み取られた後、ただしすべてのテーブルが読み取られる前に変更された場合、データ アクセス層は前のイベント ID 29202 を記録して再試行します。この時間にエンティティまたは関係のインスタンスが読み取られた場合は、これらのインスタンスに関する情報がイベントのフィールドに含まれています。読み取られていない場合、これらのフィールドは空のままになります。

Operations Manager Datawarehouse を使用した構成チャーンの考えられる原因の特定

Operations Manager レポート コンポーネントがインストールされた管理グループでは、複数の SQL クエリを使用して、頻繁に変更を送信しているワークフローを特定できます。これらのクエリは、SQL Management Studio で Datawarehouse インスタンスに対して実行する必要があります。

過去 24 時間で検出ワークフローにより送信された合計の変更:
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
このクエリにより、3 つの列が作成されます。第 1 の列はワークフローのターゲットであるオブジェクトのクラスです。第 2 の列は、検出ワークフローの内部名を示します。第 3 の列は、過去 24 時間にワークフローにより送信された、このクラスのすべてのインスタンスに対するプロパティの変更の合計数を示します。すべてのクラスに関する変更の合計数は、エージェント ヘルス サービスに関して Configuration Management サービスが構成を再計算する必要がある回数を表します。

オブジェクトの一部のクラスに関する変更の数は、安定した環境であっても、ゼロになることはありません。プロパティの追加や削除などのすべての変更、追加または使用が中止されたエージェント、追加または変更されたサーバーの役割などは、返される数値に反映されています。構成チャーンが発生した環境では、1 つまたは複数のワークフローで、他のワークフローよりも大幅に大きな値が示される可能性が高くなります。

過去 24 時間で変更されたプロパティ:
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 
このクエリを使用すると、過去 24 時間で変更されたプロパティを特定することができます。上記のクエリと組み合わせると、このクエリは、プロパティに関する古い値と新しい値の内容、変更を送信したエージェント、検出を実施したワークフロー、およびワークフローが含まれていた管理パックを示すことができます。

構成チャーンを削減する方法

古い管理パックでは、プロパティ変更の送信頻度が高すぎる検出ワークフローが導入されていました。多くの管理パックの最新版ではデータの送信頻度を下げるようにこれらの検出ワークフローが変更されているか、管理パックは頻繁に変更される変化しやすいプロパティを照会しません。上記のクエリで頻繁に発生するワークフローが含まれる管理パックをアップグレードすることをお勧めします。新しいバージョンの管理パックは、次の管理パックのカタログからダウンロードすることができます。
新しいバージョンの管理パックが提供されていない場合、または現時点で新しいバージョンを展開できない場合、上書きを使用して検出間隔を調整すると、実行頻度を下げることができます。場合によっては、構成チャーンの原因である検出を、上書きにより完全に無効にできます。検出を数週間無効にすると、ワークフローにより検出されるオブジェクトがデータベースからクリーンアップされる場合があります。ただし、オブジェクトがデータベースからクリーンアップされる前に完全な解決策を実施できる場合に限り、検出を無効にすると、構成チャーンを解消するための短期間の回避策を実現できます。また、ワークフローを短期間有効にすると、オブジェクトがクリーンアップされる前にオブジェクトを再検出することもできます。

これらの古い管理パックにあるワークフローの一部は、次のブログで解説されています。
ワークフローが、空きディスク領域などの変化しやすいプロパティを対象とするカスタム検出からのワークフローである場合、検出が頻繁に変化するプロパティを対象としないように、検出を再度書き込む必要があります。検出ワークフローの対象は、期間が短い (数週間以下) インスタンスにはしないでください。また、検出ワークフローでは、頻繁に (月に 1 回以上) 変更されるインスタンスのプロパティを収集しないでください。変化しやすいデータは、構成の計算では考慮されません。そのため、変化しやすいデータは検出ワークフローではなくパフォーマンス ルールによって収集する必要があります。

さらなるパフォーマンスの調整

大規模な管理グループ (1,000 を超えるエージェント) では、RMS は、比較的小規模な管理グループでは通常は問題にならない処理の負荷が非常に高くなる場合があります。この場合、変更を処理するために必要な時間の長さのため、プロパティ変更のペースが遅くても、頻繁にチャーンが発生する原因になる可能性があります。RMS の処理オーバーヘッドを低減し、構成チャーンを回避するのに十分な速度で一般的なペースのプロパティの変更を RMS で処理できるようにする、複数の構成変更を使用できます。これらの構成変更については、次のブログで解説されています。
管理グループに対する構成変更の強制適用

管理グループで構成チャーンが定期的に発生する場合は、問題のワークフローの頻度を下げる、または問題のワークフローを無効にするための変更がエージェントに伝播することはありません。この場合、着信する検出データの流れをブロックして、System Center Configuration Management サービスが、このデータを生成するワークフローが無効になるか実行頻度が低くなる現在の構成を計算できるようにする必要があります。

検出データは、System Center Data Access Service (DAS) を介して OperationsManager データベースに送信されます。データは、まず RMS 上の System Center Management サービスにより DAS に送信されます。RMS は、エージェントまたは他の管理サーバーからこのデータを取得します。Windows ファイアウォールや他のネットワークの手段を使用すると、ポート 5723 上で RMS への着信接続をブロックできます。 このブロックの手法により、Configuration Management サービスが、データを送信しているエージェントの現在の構成を計算するのに十分な期間、OperationsManager データベースにデータが送信されることが防止されます。


Configuration Management サービスが現在の構成を計算している間は、RMS 上の System Center Management サービスと System Center Data Access Service は停止しないでください。System Center Configuration Management サービスが管理グループの構成の計算を完了するには、以下の条件が必要です。
  • RMS 上の System Center Management サービスが実行されていて、正常である。
  • System Center Data Access Service がデータベースと通信できる。
また、Configuration Management サービスが現在の構成を計算している間、エージェントおよび他の管理サーバー上で一部のデータがバックログされる場合があります。そのため、ユーザーが RMS 上の Operations Manager イベント ログでイベント ID 21025 を確認したらすぐに、ファイアウォールまたはポート除外を解除する必要があります。このイベントは、Configuration Management サービスが、ワークフローが現在無効であるか変更されている管理グループの新しい構成を計算したことを示しています。

Operations Manager レポートを使用した構成チャーンの考えられる原因の特定

Operations Manager 2007 R2 管理パックのバージョン 6.1.7599.0 では、新しいレポートが導入されています。これらのレポートにより、管理グループが処理するデータのボリューム全体を把握できます。また、これらのレポートを使用すると、標準のベースラインを確立し、オブジェクト検出ワークフローを調整するための機会を特定することができます。構成チャーンを特定し、それに対処したらすぐに、チャーンの再発を防止するための長期計画の策定にこれらのレポートを使用することができます。

管理パックをダウンロードするには、次のマイクロソフト Web サイトにアクセスしてください。
  • Data Volume by Management Pack レポート

    Data Volume by Management Pack レポートは、管理パックにより生成されるデータのボリュームに関する情報を収集します。このレポートは、以下のデータ型に関して、管理パックごとに発生数を表示します。
    • 検出
    • 通知
    • パフォーマンス (パフォーマンス カウンターに送信され、管理パックにより収集されるインスタンスの数)
    • イベント
    • 状態変更
  • Data Volume by Workflow and Instance レポート

    Data Volume by Workflow and Instance レポートは、ワークフロー (検出、ルール、モニターなど) およびインスタンスにより生成、編成されるデータのボリュームに関する情報を収集します。

    このレポートにアクセスするには、次の 2 つの方法があります。
    • Data Volume by Management Pack レポートで、レポートの最上部にあるテーブルのいずれかのカウント セルをクリックし、管理パックの Data Volume by Workflow and Instance レポートを開きます。
    • オペレーション コンソールのレポート セクションからレポートを直接実行します。Data Volume by Workflow and Instance レポートを直接実行する場合は、レポートのパラメーターを設定して結果をカスタマイズする必要があります。このレポートは、Data Volume by Management Pack レポート内の情報に関する詳細を提供します。そのため、既定のパラメーターの設定では、必要な情報が提供されない場合があります。
プロパティ

文書番号:2603913 - 最終更新日: 2012/03/15 - リビジョン: 1

フィードバック