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

  • [アーティクル]

この記事では、System Center Operations Manager で頻繁に構成変更を検出してトラブルシューティングする方法について説明します。

元の製品バージョン: Microsoft System Center 2012 Operations Manager
元の KB 番号: 2603913

構成の概要

System Center Management Configuration サービスは、Operations Manager 管理グループ内のすべての正常性サービスの構成を計算する役割を担います。 正常性サービスの構成は、正常性サービスと、正常性サービスが監視するすべてのインスタンスのルール、監視、検出、およびタスクで構成されます。

各正常性サービスに必要なすべての構成を計算するには、管理構成サービスに次の項目の一覧が必要です。

  • すべての監視対象クラスのすべてのインスタンス
  • インスタンス間のホスティング関係
  • 監視対象クラスに割り当てられているルール、監視、検出、およびその他のワークフロー
  • インスタンスの監視を担当する正常性サービス

さらに、管理構成サービスは、管理グループ内のすべてのインスタンス グループのメンバーシップを読み取ることができる必要があります。 管理構成サービスでは、これらのグループ、クラス、または個々のインスタンスを対象とするルールとモニターのオーバーライドも適用する必要があります。

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

オブジェクトがメンバーであるクラスのリストが変更されると、そのオブジェクトを監視する正常性サービスの構成も変更されます。 これらの変更は、ルール、モニター、検出、タスク、オーバーライドが以前の構成に追加または削除されると発生します。

構成チャーン

エージェントは、次のシナリオで安定した構成を受け取ることができない場合があります。

  • 大量の検出データが管理構成サービスに送信されます。
  • 検出データが送信される前に、管理構成サービスが処理するには、検出データが送信されすぎます。 このシナリオは、データが常に計算中であるために発生します。

検出データ (構成チャーンとも呼ばれます) が頻繁に送信されると、一部の正常性サービスが古い構成で実行されたり、管理サーバーの構成が古くなったりする可能性があります。 この動作により、オペレーション コンソールで一部の正常性サービスが淡色表示 (使用不可) になります。

検出データは、検出ワークフローの実行時に正常性サービスによって送信されます。 管理グループに新しい管理パックを導入すると、各エージェントで複数の検出ワークフローが実行される可能性があります。 また、新しいインスタンスが検出されると、一部のエージェントで追加の検出が実行される場合があります。 グループ、オーバーライド、およびその他のワークフローを変更すると、検出ワークフローがエージェントで実行される可能性があります。 また、新しいエージェントを導入すると、新しいエージェントの構成を使用して、Management Configuration サービスによってインスタンス領域が更新される可能性もあります。

Configuration Management サービスは、次のシナリオで正常性サービスの構成を頻繁に再計算することを強制されます。

  • 検出ワークフローは、実行頻度が高すぎるよう構成されています。
  • ワークフローによって検出されるプロパティは、検出ワークフローが実行されるたびに変更されます。

これらのシナリオが多くのエージェントで発生した場合、または管理サーバーが既に負荷の高いワークロードの下にある場合、Configuration Management サービスが変更率に追いつくことができない可能性があり、構成チャーンが発生する可能性があります。

管理サーバー イベント ログを使用して構成チャーンを特定する

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

ログ名: Operations Manager
ソース: OpsMgr コネクタ
イベント ID: 21024
レベル: 情報
コンピューター: <名前>
説明:
OpsMgr の構成は、管理グループ <ManagementGroupName> では古くなっている可能性があり、構成サービスに対して更新された構成を要求しています。 current(out-of-date) state cookie is "3A B0 1E 5C 81 F3 12 F5 56 B7 8A EF F8 01 BA 09 86 55 06 48"

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

ログ名: Operations Manager
ソース: OpsMgr コネクタ
イベント ID: 21025
レベル: 情報
コンピューター: <名前>
説明:
OpsMgr は、Configuration Service から管理グループ <ManagementGroupName> の新しい構成を受け取っています。 新しい状態 Cookie は "34 FA 11 61 4D B8 03 59 3D 1D 66 B7 83 F3 C0 AA 7A 6F 1A 3B" です

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

ログ名: Operations Manager
ソース: OpsMgr Config Service
イベント ID: 29202
レベル: 警告
コンピューター: <名前>
説明:
OpsMgr Config Service では、データベースの変更が頻繁すぎるため、OpsMgr データベースから一貫性のある状態を取得できませんでした。
これは、検出データの通常の増加と一時的な増加が原因である可能性があります。ただし、最新の変更をチェックして、この増加が予期しないかどうかを判断します。
最新の監視オブジェクトの変更:
インスタンス = %1
クラス = %2
変更時刻 = %3
最新の監視関係の変更:
リレーションシップ インスタンス = %4
ソース インスタンス = %5
ターゲット インスタンス = %6
RelationshipClass = %7
変更時刻 = %8

データ アクセス層が変更を照会する場合、データ アクセス層は複数のテーブルを読み取る必要があります。 いずれかのテーブルが読み取られた後、すべてのテーブルが読み取られた前に変更された場合、データ アクセス層は前のイベント ID 29202 をログに記録して再試行します。 この期間中にエンティティまたはリレーションシップ インスタンスが読み取られた場合、これらのインスタンスに関する情報がイベント フィールドに含まれます。 それ以外の場合、これらのフィールドは空のままです。

Operations Manager Data Warehouseを使用して、構成チャーンの潜在的な原因を特定する

Operations Manager Reporting コンポーネントがインストールされた管理グループでは、いくつかの SQL クエリを使用して、頻繁な変更を送信するワークフローを識別できます。 これらのクエリは、Data Warehouse インスタンスに対してSQL Server Management Studioで実行する必要があります。

過去 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 As '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 つの列が作成されます。 最初の列は、ワークフローの対象となるオブジェクトのクラスです。 2 番目の列は、検出ワークフローの内部名を示します。 3 番目の列は、過去 24 時間以内にワークフローによって送信された、このクラスのすべてのインスタンスのプロパティ変更の合計数を示します。 すべてのクラスに対する変更の合計数は、Configuration Management サービスがエージェント正常性サービスの構成を再計算する必要がある回数を表します。

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

過去 24 時間に変更されたプロパティ:

select distinct
   MP.ManagementPackSystemName,
   MET.ManagedEntityTypeSystemName,
   PropertySystemName,
   D.DiscoverySystemName,
   D.DiscoveryDefaultName,
   MET1.ManagedEntityTypeSystemName As 'TargetTypeSystemName',
   MET1.ManagedEntityTypeDefaultName As '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 の運用オーバーヘッドを削減し、構成のチャーンを回避するのに十分な速さで一般的なプロパティ変更率を処理できます。 これらの構成の変更については、「 Operations Manager 2007 R2 および 2012 のパフォーマンスの最適化」を参照してください。

管理グループの構成の変更を強制する

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

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

構成管理サービスが現在の構成を計算している間、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 が表示されたらすぐに、ファイアウォールまたはポートの除外を解除する必要があります。 このイベントは、構成管理サービスが、ワークフローが無効または変更された管理グループの新しい構成を計算したことを示します

Operations Manager レポートを使用して構成チャーンの潜在的な原因を特定する

新しいレポートが導入されました。 これらのレポートは、管理グループが処理するデータの全体的な量に関する分析情報を提供します。 これらのレポートを使用して、標準ベースラインを確立し、オブジェクト検出ワークフローをチューニングする機会を特定できます。 構成チャーンが特定され、対処されるとすぐに、これらのレポートを長期的な計画に使用してチャーンの再発を防ぐことができます。

  • 管理パック別のデータ 量レポート

    管理パック別のデータ ボリューム レポートでは、管理パックによって生成されるデータ量に関する情報がコンパイルされます。 レポートには、次のデータ型の管理パックあたりの出現回数が一覧表示されます。

    • 発見
    • アラート
    • パフォーマンス (パフォーマンス カウンターに送信され、管理パックによって収集されるインスタンスの数)
    • イベント
    • 状態の変更

  • ワークフローおよびインスタンス別のデータ 量レポート

    ワークフローおよびインスタンス別のデータ ボリューム レポートは、ワークフロー (検出、ルール、モニターなど) とインスタンスによって編成された、生成されたデータの量に関する情報をコンパイルします。

    このレポートにアクセスするには、次の 2 つの方法があります。

    • [ 管理パック別データ ボリューム] レポートで、レポートの上部にあるテーブル内の counts セルの 1 つを選択して、管理パックの [ワークフロー別データ ボリューム] レポートと [インスタンス別データ ボリューム] レポートを開きます。
    • オペレーション コンソールの [レポート] セクションからレポート を 直接実行します。 ワークフローおよびインスタンス別のデータ ボリューム レポートを直接実行する場合は、レポートのパラメーターを設定して結果をカスタマイズする必要があります。 このレポートは、 管理パック別データ ボリューム レポートの情報の詳細を提供します。 そのため、既定のパラメーター設定では、探している情報が提供されない場合があります。