System Center Operations Manager での灰色のエージェントの状態のトラブルシューティング

この記事では、System Center Operations Manager (OpsMgr) でエージェント、管理サーバー、またはゲートウェイが使用できない、または 淡色表示される 問題のトラブルシューティング方法について説明します。

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

エージェント、管理サーバー、またはゲートウェイは、[ 監視 ] ウィンドウのエージェント名とアイコンの色で示されているように、次のいずれかの状態を持つことができます。

灰色の状態の原因

エージェント、管理サーバー、またはゲートウェイは、次のいずれかの理由で使用できなくなる可能性があります。

• ハートビート エラー
• 無効な構成
• システム ワークフローエラー
• Operations Manager データベースまたはデータ ウェアハウスのパフォーマンスの問題
• 管理サーバーまたはゲートウェイ サーバーのパフォーマンスの問題
• ネットワークまたは認証の問題
• 正常性サービスが実行されていません

問題のスコープ

エージェントが淡色表示された問題のトラブルシューティングを開始する前に、まず Operations Manager トポロジを理解してから、問題のスコープを定義する必要があります。 次の質問は、問題の範囲を定義するのに役立つ場合があります。

• 影響を受けるエージェントの数
• エージェントで同じネットワーク セグメントで問題が発生していますか?
• エージェントは同じ管理サーバーに報告しますか?
• エージェントはどのくらいの頻度で入り、灰色の状態のままですか?
• 通常、この状況からどのように復旧しますか (たとえば、エージェントの正常性サービスを再起動し、キャッシュをクリアし、自動回復に依存します)。
• これらのエージェントに対してハートビート エラー アラートは生成されますか?
• この問題は、1 日の特定の時間に発生しますか?
• これらのエージェントを別の管理サーバーまたはゲートウェイにフェールオーバーした場合、この問題は解決しませんか?
• この問題はいつ開始されましたか?
• エージェント、管理サーバー、またはゲートウェイまたは管理グループに変更が加えられましたか?
• 影響を受けるエージェントは Windows クラスター化されたシステムですか?
• Health Service State フォルダーはウイルス対策スキャンから除外されていますか?

トラブルシューティング戦略

トラブルシューティング戦略は、どのコンポーネントが非アクティブであるか、そのコンポーネントがトポロジ内にあり、問題がどの程度広がっているかによって決まります。 次の条件を検討してください。

• 特定の管理サーバーまたはゲートウェイに報告するエージェントが使用できない場合は、管理サーバーまたはゲートウェイ レベルでトラブルシューティングを開始する必要があります。
• 特定の管理サーバーにレポートするゲートウェイが使用できない場合は、管理サーバー レベルでトラブルシューティングを開始する必要があります。
• エージェントレス システム、ネットワーク デバイス、Unix および Linux サーバーの場合は、これらのオブジェクトを監視しているエージェント、管理サーバー、またはゲートウェイからトラブルシューティングを開始する必要があります。
• トラブルシューティングは通常、使用できないコンポーネントのすぐ上のレベルから開始されます。

シナリオ 1

この問題の影響を受けるエージェントはごくわずかです。 これらのエージェントは、別の管理サーバーにレポートします。 エージェントは定期的に使用できなくなります。 問題を一時的に解決するためにエージェント キャッシュをクリアすることはできますが、問題は数日後に再発します。

シナリオ 1 の解決策

このシナリオの問題を解決するには、次の手順に従います。

1. 影響を受けるオペレーティング システムに適切な修正プログラムを適用します。
2. ウイルス対策スキャンからエージェント キャッシュを除外します。 詳細については、「 Operations Manager に関連するウイルス対策の除外に関する推奨事項」を参照してください。
3. 正常性サービスを停止します。
4. エージェント キャッシュをクリアします。
5. 正常性サービスを開始します。

シナリオ 2

この問題の影響を受けるエージェントはごくわずかです。 これらのエージェントは、別の管理サーバーにレポートします。 エージェントは常に非アクティブなままです。 エージェント キャッシュをクリアすることはできますが、この問題は解決されません。

シナリオ 2 の解決策

このシナリオの問題を解決するには、次の手順に従います。

1. 正常性サービスが有効になっていて、現在管理サーバーまたはゲートウェイで実行されているかどうかを確認します。 正常性サービスが応答を停止した場合は、問題の原因を特定するために、サービスハング モードで ADPlus ダンプを生成します。 詳細については、「ADPlus.vbs を使用して "ハング" と "クラッシュ" のトラブルシューティングを行う方法」を参照してください。

2. エージェントの Operations Manager イベント ログを調べて、次のいずれかのイベントを見つけます。

   イベント ID: 1102
   イベント ソース: HealthService
   イベントの説明:
   id:"%2" のインスタンス "%3" に対して実行されている Rule/Monitor "%4" は初期化できず、読み込まれません。 管理グループ "%1"

   イベント ID: 1103
   イベント ソース: HealthService
   イベントの説明:
   概要: %2 ルール/モニターが失敗してアンロードされ、そのうちの %3 が自動再読み込みを妨げるエラー制限に達しました。 管理グループ "%1" これは概要のみのイベントです。アンロードされたルール/モニターの説明を含む他のイベントを参照してください。

   イベント ID: 1104
   イベント ソース: HealthService
   イベントの説明:
   ワークフロー "%4" の RunAs プロファイル。id:"%2" のインスタンス "%3" で実行されている場合は解決できません。 ワークフローは読み込まれません。 管理グループ "%1"

   イベント ID: 1105
   イベント ソース: HealthService
   イベントの説明:
   id:"%2" のインスタンス "%3" で実行されている、ワークフロー "%4" の RunAs プロファイルの型の不一致。 ワークフローは読み込まれません。 管理グループ "%1"

   イベント ID: 1106
   イベント ソース: HealthService
   イベントの説明:
   id:"%2" のインスタンス "%3" で実行されている、ワークフロー "%4" のプレーン テキストの RunAs プロファイルにアクセスできません。 ワークフローは読み込まれません。 管理グループ "%1"

   イベント ID: 1107
   イベント ソース: HealthService
   イベントの説明:
   ワークフロー "%4" の RunAs プロファイルのアカウント。id:"%2" のインスタンス "%3" に対して実行が定義されていません。 ワークフローは読み込まれません。 アカウントをプロファイルに関連付けてください。 管理グループ "%1"

   イベント ID: 1108
   イベント ソース: HealthService
   イベントの説明:
   実行プロファイル "%7" で指定されたアカウントを解決できません。 具体的には、アカウントはセキュリティで保護された参照オーバーライド "%6" で使用されます。 %n%n この条件は、アカウントがこのコンピューターに配布されるように構成されていないために発生した可能性があります。 この問題を解決するには、以下で指定した実行プロファイルを開き、SSID で指定されたアカウント エントリを見つけて、必要に応じてこのコンピューターにアカウントを配布するか、プロファイルの設定を変更して、ターゲット オブジェクトが指定したアカウントを使用しないようにする必要があります。 %n%nManagement Group: %1 %nRun As Profile: %7 %nSecureReferenceOverride name: %6 %nSecureReferenceOverride ID: %4 %nObject name: %3 %nObject ID: %2 %nAccount SSID: %5

   イベント ID: 4000
   イベント ソース: HealthService
   イベントの説明:
   監視ホストが応答しないか、クラッシュしました。 ホストエラーの状態コードは %1 でした。

   イベント ID: 21016
   イベント ソース: OpsMgr コネクタ
   イベントの説明:
   OpsMgr で通信チャネルを %1 に設定できず、フェールオーバー ホストがありません。 %1 が使用可能で、このコンピューターからの通信が許可されると、通信が再開されます。

   イベント ID: 21006
   イベント ソース: OpsMgr コネクタ
   イベントの説明:
   OpsMgr コネクタを %1:%2 に接続できませんでした。 エラー コードは %3(%4) です。 ネットワーク接続があり、サーバーが実行されており、リッスンポートが登録されており、宛先へのトラフィックをブロックするファイアウォールがないことを確認してください。

   イベント ID: 20070
   イベント ソース: OpsMgr コネクタ
   イベントの説明:
   %1 に接続されている OpsMgr コネクタが、認証が発生した直後に接続が閉じられました。 このエラーの最も可能性の高い原因は、エージェントがサーバーとの通信を許可されていないか、サーバーが構成を受け取っていないということです。 サーバー上のイベント ログに 20000 個のイベントがあるかどうかを確認します。承認されていないエージェントが接続を試みていることを示します。

   イベント ID: 20051
   イベント ソース: OpsMgr コネクタ
   イベントの説明:
   証明書が現在有効ではないため、指定した証明書を読み込めませんでした。 システム時刻が正しいことを確認し、必要に応じて証明書を再発行します%n 証明書の有効な開始時刻: %1%n 証明書の有効な終了時刻: %2

   イベント ソース: ESE
   イベント カテゴリ: トランザクション マネージャー
   イベント ID: 623
   説明: HealthService (<PID>) インスタンス <インスタンス> ("<name>") のバージョン ストアが、値> Mb の<最大サイズに達しました。 実行時間の長いトランザクションによって、バージョン ストアのクリーンアップが妨げられ、サイズが増える可能性があります。 実行時間の長いトランザクションが完全にコミットまたはロールバックされるまで、更新は拒否されます。 実行時間の長いトランザクションの可能性:
   SessionId: <値>
   セッション コンテキスト: <値>
   セッション コンテキスト ThreadId: <値>。
   クリーンアップ: <値>

3. 次の特定のイベントが見つからない場合は、次のガイドラインに従ってください。

   • イベント 1102 および 1103: これらのイベントは、ワークフローの一部が読み込みに失敗したことを示します。 これがコア システム ワークフローの場合、これらのイベントによって問題が発生する可能性があります。 この場合は、これらのイベントの解決に焦点を当てます。

   • イベント 1104、1105、1106、1107、および 1108: これらのイベントにより、イベント 1102 と 1103 が発生する可能性があります。 通常、これは、正しく構成されていない実行アカウントが原因で発生します。 たとえば、実行アカウントは、間違ったクラスで使用するように構成されているか、エージェントに配布されるように構成されていません。

   • イベント 4000: このイベントは、Monitoringhost.exe プロセスがクラッシュしたことを示します。 この問題が DLL の不一致またはレジストリ キーの欠落によって引き起こされる場合は、エージェントを再インストールすることで問題を解決できる可能性があります。 問題が解決しない場合は、次の方法を使用して解決してください。

     • プロセスがクラッシュするまでプロセス モニター キャプチャを実行します。 詳細については、「 プロセス モニター v3.53」を参照してください。
     • クラッシュ モードで ADPlus ダンプを生成します。 詳細については、「ADPlus.vbs を使用して "ハング" と "クラッシュ" のトラブルシューティングを行う方法」を参照してください。

   • イベント ID 21006: このイベントは、エージェントと管理サーバーの間に通信の問題が存在することを示します。 エージェントが相互認証に証明書を使用する場合は、証明書の有効期限が切れていないか、エージェントが正しい証明書を使用していることを確認します。 Kerberos が使用されている場合は、エージェントが Active Directory と通信できることを確認します。 認証が正しく機能している場合は、エージェントからのパケットが管理サーバーまたはゲートウェイに到達していない可能性があります。 エージェントから管理サーバーへのポート 5723 への telnet の確立を試みます。 さらに、通信エラーを再現しながら、エージェントと管理サーバーの間で同時にネットワーク トレースを実行します。 これは、パケットが管理サーバーに到達しているかどうか、および 2 つのコンポーネント間のデバイスがトラフィックを最適化しようとしているか、パケットをドロップしているかを判断するのに役立ちます。 詳細については、「 ネットワーク モニターを使用してデータを収集する」を参照してください。

   • イベント ID 623: このイベントは通常、管理サーバーまたはエージェント コンピューターが多数のワークフローを管理する大規模な Operations Manager 環境で発生します。 詳細については、「 Operations Manager コンソールで 1 つ以上の管理サーバーとその管理対象デバイスが淡色表示される」を参照してください。

シナリオ 3

特定の管理サーバーまたはゲートウェイに報告するすべてのエージェントは使用できません。

シナリオ 3 の解決策

このシナリオの問題を解決するには、次の手順に従います。

1. 管理サーバーまたはゲートウェイが監視しているワークロードの種類を調べてみます。 このようなワークロードには、ネットワーク デバイス、クロスプラットフォーム エージェント、代理トランザクション、Windows エージェント、エージェントレス コンピューターなどがあります。

2. 正常性サービスが管理サーバーまたはゲートウェイで実行されているかどうかを判断します。

3. 管理サーバーがメンテナンス モードで実行されているかどうかを確認します。 必要に応じて、メンテナンス モードからサーバーを削除します。

4. シナリオ 2 に記載されているすべてのイベントについて、エージェントの Operations Manager イベント ログを調べます。 イベント ID 21006 がある場合は、「 シナリオ 2 の解決」で説明されているのと同じガイドラインに従ってください。 また、この場合、このイベントは、管理サーバーまたはゲートウェイが親サーバーと通信できないことを示します。 ゲートウェイの場合、親サーバーは任意の管理サーバーである可能性があります。 ( シナリオ 2 の解決策の手順 3 を参照してください)。

5. Operations Manager イベント ログで、次のイベントを確認します。 通常、これらのイベントは、 または データベースをホストしている管理サーバーまたは Microsoft SQL ServerにパフォーマンスのOperationsManagerOperationsManagerDW問題が存在することを示します。

   イベント ID: 2115
   イベント ソース: HealthService
   イベントの説明:
   管理グループ %1 のバインド データ ソースは、ワークフローにアイテムを投稿しましたが、%5 秒で応答を受信していません。 これは、ワークフローのパフォーマンスまたは機能的な問題を示します。%n ワークフロー ID : %2%n インスタンス: %3%n インスタンス ID : %4%n

   イベント ID: 5300
   イベント ソース: HealthService
   イベントの説明:
   ローカル正常性サービスは正常ではありません。 エンティティ状態の変更フローは、受信確認が保留中でストールしています。 %n%n管理グループ: %2 %n管理グループ ID: %1

   イベント ID: 4506
   イベント ソース: HealthService
   イベントの説明: Operations Manager
   管理グループ "%1" で id:"%4" のインスタンス "%3" に対して実行されているルール "%2" の未処理のデータが多すぎるため、データが削除されました。

   イベント ID: 31551
   イベント ソース: Health Service モジュール
   イベントの説明:
   Data Warehouseにデータを格納できませんでした。 操作は再試行されます。%rException '%5': %6 %n%nOne 以上のワークフローがこの影響を受けています。 %n%nWorkflow name: %2 %nInstance name: %3 %nInstance ID: %4 %nManagement group: %1

   イベント ID: 31552
   イベント ソース: Health Service モジュール
   イベントの説明:
   Data Warehouse.%rException '%5': %6 %n%nOne 以上のワークフローにデータを格納できませんでした。 %n%nWorkflow name: %2 %nInstance name: %3 %nInstance ID: %4 %nManagement group: %1

   イベント ID: 31553
   イベント ソース: Health Service モジュール
   イベントの説明:
   データはData Warehouseステージング領域に書き込まれますが、後続の操作のいずれかで処理が失敗しました。%rException '%5': %6 %n%nOne 以上のワークフローがこの影響を受けています。 %n%nWorkflow name: %2 %nInstance name: %3 %nInstance ID: %4 %nManagement group: %1

   イベント ID: 31557
   イベント ソース: Health Service モジュール
   イベントの説明:
   データベースから同期プロセスの状態情報Data Warehouse取得できませんでした。 操作は再試行されます。%rException '%5': %6 %n%nOne 以上のワークフローがこの影響を受けています。 %n%nWorkflow name: %2 %nInstance name: %3 %nInstance ID: %4 %nManagement group: %1

6. また、実行アカウントの構成が正しくないか、実行アカウントのアクセス許可がないため、イベント ID 3155X がログに記録されることがあります。

シナリオ 4

特定の管理サーバーに報告するすべてのエージェントは、正常な状態と灰色の状態を断続的に交互に行います。 または、環境内のすべてのエージェントが、正常な状態と灰色の状態の間で断続的に交互になります。

シナリオ 4 の解決策

問題を解決するには、まず問題の原因を特定します。 一時的なサーバーが使用できない一般的な原因は次のとおりです。

• エージェントの親サーバーは一時的にオフラインです。
• エージェントは、アラート、状態、検出などの運用データで管理サーバーにフラッディングしています。 これにより、Operations Manager データベースと Operations Manager サーバーでのシステム リソースの使用が増える可能性があります。
• ネットワークの停止により、親サーバーとエージェントの間で一時的な通信エラーが発生しました。
• 管理パック (MP) の変更が発生しました。 Operations Manager コンソールでは、これらの変更には Operations Manager の構成とエージェントへの MP 再配布が必要です。 変更が大きなエージェント ベースに影響を与える場合、Operations Manager データベースと Operations Manager サーバーでのシステム リソースの使用が増加する可能性があります。

これらのシナリオのトラブルシューティングの鍵は、サーバーが使用できない期間と、サーバーが発生した時刻を理解することです。 これにより、問題の範囲をすばやく絞り込むのに役立ちます。

管理サーバーとゲートウェイのパフォーマンスのトラブルシューティング

管理サーバー

構成更新バースト (MP のインポートと検出によって引き起こされる) の間、一般的なボトルネックは、最初に CPU、2 つ目の Operations Manager インストール ディスク I/O です。 管理サーバーは、構成ファイルをターゲット エージェントに転送する役割を担います。

運用データ収集の場合、ボトルネックは通常 CPU によって発生します。 ディスク I/O も最大容量である可能性がありますが、そうは限りません。 管理サーバーは、受信した運用データの圧縮解除と復号化を行い、それを Operational データベースに挿入する役割を担います。 また、運用データを受信した後、受信確認 (ACK) をエージェントまたはゲートウェイに送信し、ディスク キューを使用してこれらの送信 ACL を一時的に格納します。

ゲートウェイ

ゲートウェイは、CPU バインドと I/O バインドの両方です。 ゲートウェイが大量のデータを中継している場合、CPU 操作と I/O 操作の両方で使用率が高くなる可能性があります。 ほとんどの CPU 使用率は、受信データの圧縮解除、圧縮、暗号化、復号化、およびそのデータの転送によって発生します。 ゲートウェイとエージェントから受信されたすべてのデータは、ゲートウェイ正常性サービスによって管理サーバーに読み取られ、転送されるディスク上の永続的なキューに格納されます。 これにより、ディスクの使用量が多くなることがあります。 この使用は、ゲートウェイが一時的にオフラインになったときに重要になる可能性があり、ゲートウェイがまだオフラインのときにエージェントが生成して送信しようとした蓄積されたエージェント データを処理する必要があります。

この状況で問題をトラブルシューティングするには、影響を受ける管理サーバーまたはゲートウェイごとに次の情報を収集します。

• Windows の正確なバージョン、エディション、ビルド番号

• プロセッサ数

• RAM の量

• Health Service State フォルダーを含むドライブ

• ウイルス対策ソフトウェアが Health Service ストアを除外するように構成されているかどうか

  注:

  詳細については、「 Operations Manager に関連するウイルス対策の除外に関する推奨事項」を参照してください。

• 正常性サービス状態で使用されるドライブの RAID レベル (0、51、、0+1または1+0)

• RAID に使用されるディスクの数

• バッテリバックアップ書き込みキャッシュが配列コントローラーで有効になっているかどうか

SQL Serverパフォーマンスのトラブルシューティング

オペレーショナル データベース (OperationsManager)

データベースの OperationsManager 場合、最もボトルネックとなるのはディスク アレイです。 ディスク アレイが最大 I/O 容量にない場合、次にボトルネックとなる可能性が高いのは CPU です。 データベースでは、時には速度低下や運用データ の嵐が発生します (比較的長い時間持続するイベント、アラート、パフォーマンス データまたは状態の変化の発生率が高くなります)。 通常、短いバーストでは、長時間にわたって大幅な遅延は発生しません。

運用データの挿入中、データベース ディスクは主に書き込みに使用されます。 CPU 使用率は、チャーンSQL Server原因です。 これは、大規模で複雑なクエリ、大量のデータ挿入、大きなテーブルのクリーンアップ (既定では午前 0 時に発生) がある場合に発生する可能性があります。 通常、大規模なイベントやパフォーマンス データ テーブルのクリーンアップでは、CPU またはディスク リソースが過剰に消費されることはありません。 ただし、アラートテーブルと状態変更テーブルのグルーミングは、大きなテーブルでは CPU を集中的に消費する可能性があります。

データベースは、MP のインポートまたは大規模なインスタンス領域の変更によって発生する構成再配布バーストを処理するときにも CPU バインドされます。 このような場合、Config サービスはデータベースに対して新しいエージェント構成を照会します。 通常、これにより、サービスが構成更新プログラムをエージェントに送信する前に、データベースで CPU スパイクが発生します。

データ ウェアハウス (OperationsManagerDW)

データベースの OperationsManagerDW 場合、最もボトルネックとなるのはディスク アレイです。 これは通常、操作データの挿入が大きいために発生します。 このような場合、ディスクはほとんどの場合、書き込みの実行にビジー状態になります。 通常、ディスクは、データ ウェアハウスに対してクエリを実行するため、手動で生成されたレポート ビューを処理する以外は、ほとんど読み取りを実行できません。

CPU 使用率は、チャーンSQL Serverが原因で発生します。 CPU スパイクは、大量のパーティション分割アクティビティ (テーブルが大きくなり、パーティション分割されたとき)、複雑なレポートの生成、データベース内の大量のアラート (データ ウェアハウスが常に同期する必要がある場合) に発生する可能性があります。

一般的なトラブルシューティング

この状況で問題をトラブルシューティングするには、影響を受ける管理サーバーまたはゲートウェイごとに次の情報を収集します。

• Windows の正確なバージョン、エディション、ビルド番号

• プロセッサ数

• RAM の量

• SQL Serverに割り当てられるメモリの量

• SQL Serverが 32 ビットで AWE が有効かどうか

  この情報の大部分は、SQL Server Management Studio または SQL Server Enterprise Manager にあります。 これを行うには、サーバーの [プロパティ ] ウィンドウを開き、[ 全般 ] タブと [ メモリ ] タブを選択します。 [全般] タブには、SQL Server バージョン、Windows バージョン、プラットフォーム、RAM の量、プロセッサの数が含まれます。 [メモリ] タブには、SQL Serverに割り当てられるメモリが含まれます。 Microsoft SQL Server 2008 では、[メモリ] タブには AWE オプションも含まれています。

  OS が 32 ビットで RAM が 4 GB 以上の場合は、Boot.ini に スイッチまたは /3gb スイッチが存在するかどうかを/paeチェックします。 ファイル。 これらのオプションは、サーバーが最初に 4 GB 以下の RAM を使用してインストールされていた場合や、RAM が後でアップグレードされた場合に、正しく構成されていない可能性があります。

  RAM が 4 GB の 32 ビット サーバーの場合、Boot.ini のスイッチによって、/3gbSQL Serverがアドレス指定できるメモリの量が増えます (2 GB から 3 GB)。 RAM が 4 GB を超える 32 ビット サーバーの場合、/3gbBoot.ini のスイッチによって、実際にSQL Serverがアドレス指定できるメモリの量が制限される可能性があります。 これらのシステムでは、スイッチを /pae Boot.ini に追加し、SQL Serverで AWE を有効にします。

  マルチプロセッサ システムで、[最大並列処理度 (MAXDOP)] 設定をチェックします。 SQL Server 2008 では、このオプションはサーバーの [プロパティ] ダイアログ ボックスの [詳細設定] タブにあります。

  既定値は 0 です。これは、使用可能なすべてのプロセッサが使用されることを意味します。 プロセッサが 8 個以下のサーバーでは、0 を設定しても問題ありません。 プロセッサが 8 つを超えるサーバーの場合、すべてのプロセッサの使用を調整するのにSQL Serverかかる時間は逆効果になる可能性があります。 そのため、プロセッサが 8 つを超えるサーバーの場合は、通常、 並列処理の最大次数 を 8 に設定する必要があります。 これを行うには、SQL Query Analyzer で次のコマンドを実行します。

  sp_configure 'show advanced options', 1
  GO
  RECONFIGURE WITH OVERRIDE
  GO
  sp_configure 'max degree of parallelism', 8
  GO
  RECONFIGURE WITH OVERRIDE
  GO
  

• データ ウェアハウス、Operations Manager DB、Tempdb ファイルを含むドライブ文字

• SQL データファイルとログ ファイルを除外するようにウイルス対策ソフトウェアが構成されているかどうか (ウイルス対策ソフトウェアを使用してデータベース ファイルSQL Serverスキャンすると、パフォーマンスが低下する可能性があります)。

• データ ウェアハウス、Operations Manager DB、および Tempdb ファイルを含むドライブの空き領域の量

• ストレージの種類 (SAN またはローカル)

• SQL Serverで使用されるドライブの RAID レベル (0、1、5、0+1、または 1+0)

• SAN ストレージが使用されている場合: SQL Serverによって使用される各 LUN 上のスピンドルの数

• 変換された Exchange 2007 管理パックが使用されている場合、または使用されている場合: Operations Manager データベース内のテーブルとデータ ウェアハウス データベース内EventPublisherのテーブル内の行LocalizedText数

  行の量を確認するには、次のコマンドを実行します。

  USE OperationsManager SELECT COUNT(*) FROM LocalizedText
  USE OperationsManagerDW SELECT COUNT(*) FROM EventPublisher
  

メモリ負荷を識別するためのカウンター

ディスクの負荷を識別するためのカウンター

SQL データまたはログ ファイルを含むすべてのドライブに対して、次の物理ディスク カウンターをキャプチャします。

• アイドル時間の割合: 報告されているディスクのアイドル時間の量。 50% を下回るものは、ディスクのボトルネックを示している可能性があります。

• 平均ディスク キューの長さ: この値は、LUN 上のスピンドルの数の 2 倍を超えないようにしてください。 たとえば、LUN に 25 個のスピンドルがある場合は、値 50 を使用できます。 ただし、LUN に 10 個のスピンドルがある場合、値 25 が高すぎます。 RAID 構成の RAID レベルとディスク数に基づいて、次の数式を使用できます。

  • RAID 0: すべてのディスクが RAID 0 セットで動作しています

  • 平均ディスク キュー長<= # (配列内のディスク) *2

  • RAID 1: ディスクの半分が動作しています。そのため、半分しかディスク キューにカウントできません

  • 平均ディスク キュー長<= # (配列内のディスク/2) *2

  • RAID 10: ディスクの半分が "作業中" です。そのため、半分しかディスク キューにカウントできません

  • 平均ディスク キュー長<= # (配列内のディスク/2) *2

  • RAID 5: すべてのディスクが RAID 5 セットで動作しています

  • 平均ディスク キュー長<= # 配列内のディスク *2

  • 平均ディスク秒/転送: 1 つのディスク I/O を完了するまでにかかる秒数

  • 平均ディスク秒/読み取り: ディスクからデータを読み取る平均時間 (秒単位)

  • 平均ディスク秒/書き込み: ディスクにデータを書き込む平均時間 (秒単位)

    この一覧の最後の 3 つのカウンターは、一貫して約 .020 (20 ミリ秒) 以下の値を持ち、 .050 (50 ミリ秒) を超えないようにする必要があります。 SQL Server パフォーマンストラブルシューティング ガイドに記載されているしきい値を次に示します。

    • 10ミリ秒未満:非常に良い
    • 10 ~ 20 ミリ秒の間: 問題ありません
    • 20 ~ 50 ミリ秒の間: 低速、注意が必要
    • 50 ミリ秒を超える: 重大な I/O ボトルネック

  • ディスク バイト数/秒: 1 秒あたりのディスク間の転送バイト数

  • ディスク転送/秒: 1 秒あたりの入力操作と出力操作の数 (IOPS)

  アイドル時間の割合が低い (10% 以下) 場合、これはディスクが完全に使用されていることを意味します。 この場合、この一覧の最後の 2 つのカウンター (ディスク バイト/秒 と ディスク転送/秒) は、ドライブの最大スループットをバイト単位と IOPS 単位で示します。 SAN ドライブのスループットは、スピンドルの数、ドライブの速度、チャネルの速度に応じて、非常に変動します。 最適な方法は、SAN ベンダーにチェックして、ドライブがサポートする必要があるバイト数と IOPS を確認することです。 アイドル時間の割合が低く、これら 2 つのカウンターの値がドライブの予想スループットを満たしていない場合は、SAN ベンダーに問い合わせてトラブルシューティングを行います。

パフォーマンスのトラブルシューティング ガイドSQL Server、トラブルシューティングSQL Serverパフォーマンスに関するより深い分析情報を提供します。

Operations Manager のパフォーマンス カウンター

次のセクションでは、Operations Manager のパフォーマンスを監視およびトラブルシューティングするために使用できるパフォーマンス カウンターについて説明します。

ゲートウェイ サーバーロール

全体的なパフォーマンス カウンター

これらのカウンターは、ゲートウェイの全体的なパフォーマンスを示します。

Operations Manager プロセスの汎用パフォーマンス カウンター

これらのカウンターは、ゲートウェイでの Operations Manager プロセスの全体的なパフォーマンスを示します。

Operations Manager 固有のパフォーマンス カウンター

これらのカウンターは、ゲートウェイ上の Operations Manager の特定の側面のパフォーマンスを示す Operations Manager 固有のカウンターです。

管理サーバーの役割

全体的なパフォーマンス カウンター

これらのカウンターは、管理サーバーの全体的なパフォーマンスを示します。

Operations Manager プロセスの汎用パフォーマンス カウンター

これらのカウンターは、管理サーバー上の Operations Manager プロセスの全体的なパフォーマンスを示します。

Operations Manager 固有のパフォーマンス カウンター

これらのカウンターは、管理サーバー上の Operations Manager の特定の側面のパフォーマンスを示す Operations Manager 固有のカウンターです。