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

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

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

エージェント、管理サーバー、またはゲートウェイは、 Monitoring ペインのエージェント名とアイコンの色で示されているように、次のいずれかの状態にすることができます。

灰色の状態の原因

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

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

問題のスコープ

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

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

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

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

• 特定の管理サーバーまたはゲートウェイに報告するエージェントが使用できない場合は、管理サーバーまたはゲートウェイ レベルでトラブルシューティングを開始する必要があります。
• 特定の管理サーバーに報告するゲートウェイが使用できない場合は、管理サーバー レベルでトラブルシューティングを開始する必要があります。
• エージェントレス システム、ネットワーク デバイス、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" に対して実行されているルール/モニター "%4" は初期化できず、読み込まれません。 管理グループ "%1"

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

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

   イベント ID: 1105
   イベント ソース: HealthService
   イベントの説明:
   ワークフロー "%4" の RunAs プロファイルの種類が一致しません。id:"%2" のインスタンス "%3" に対して実行されています。 ワークフローは読み込まれません。 管理グループ "%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%n管理グループ: %1 %n 実行プロファイル: %7 %nSecureReferenceOverride 名: %6 %nSecureReferenceOverride ID: %4 %nオブジェクト名: %3 %nオブジェクト ID: %2 %n アカウント 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>) インスタンス <instance>("<name>") のバージョン ストアが、最大サイズの <value> Mb に達しました。 実行時間の長いトランザクションによって、バージョン ストアのクリーンアップが妨げられ、サイズが増える可能性があります。 実行時間の長いトランザクションが完全にコミットまたはロールバックされるまで、更新は拒否されます。 実行時間の長いトランザクションの可能性:
   SessionId: <value>
   セッション コンテキスト: <value>
   セッション コンテキスト ThreadId: <value>。
   クリーンアップ: <value>

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

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

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

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

     • プロセスがクラッシュするまでプロセス モニター キャプチャを実行します。 詳細については、「 Process Monitor 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. エージェントの Operations Manager イベント ログで、 Scenario 2 に一覧表示されているイベントを調べます。 イベント ID 21006 がある場合は、シナリオ 2 の Resolution で説明されているのと同じガイドラインに従。 さらに、このイベントは、管理サーバーまたはゲートウェイが親サーバーと通信できないことを示します。 ゲートウェイの場合、親サーバーは任意の管理サーバーにすることができます。 ( の手順 3 を参照してください。シナリオ 2 の解決策。

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

   イベント 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
   イベント ソース: ヘルス サービス モジュール
   イベントの説明:
   データ ウェアハウスにデータを格納できませんでした。 操作は再試行されます。%rException '%5': %6 %n%nOne 以上のワークフローがこの影響を受けます。 %n%nワークフロー名: %2 %nInstance name: %3 %nInstance ID: %4 %n管理グループ: %1

   イベント ID: 31552
   イベント ソース: ヘルス サービス モジュール
   イベントの説明:
   データ ウェアハウスにデータを格納できませんでした。%rException '%5': %6 %n%n1 以上のワークフローがこの影響を受けます。 %n%nワークフロー名: %2 %nInstance name: %3 %nInstance ID: %4 %n管理グループ: %1

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

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

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

シナリオ 4

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

シナリオ 4 の解決策

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

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

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

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

管理サーバー

構成更新プログラムのバースト中 (MP のインポートと検出によって発生します)、一般的なボトルネックは、最初に CPU、2 番目に Operations Manager インストール ディスク I/O です。 管理サーバーでは、構成ファイルをターゲット エージェントに転送します。

オペレーショナル データの収集の場合、通常、ボトルネックは CPU によって引き起こされます。 ディスク I/O が最大容量になっていることも考えられますが、あまり可能性はありません。 管理サーバーでは、受信したオペレーショナル データの圧縮解除と暗号化解除を行い、それをオペレーション データベースに挿入します。 また、オペレーショナル データを受信した後に、確認応答 (ACK) をエージェントまたはゲートウェイに返信し、ディスク キューを使用してこれらの送信 ACK を一時的に格納します。

ゲートウェイ

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

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

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

• プロセッサの数

• RAM の容量

• ヘルス サービス State フォルダーを含むドライブ

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

  Note

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

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

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

• バッテリベースの書き込みキャッシュがアレイ コントローラーで有効になっているかどうか

SQL Server パフォーマンスに関する問題のトラブルシューティング

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

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

オペレーショナル データの挿入中、データベース ディスクは主に書き込みに使用されます。 CPU が使用される原因は、SQL Server のチャーンです。 これは、大規模で複雑なクエリ、大量のデータ挿入、大規模なテーブルのクリーンアップ (既定では、午前 0 時に実施) が行われているときに発生する可能性があります。 通常は、より大規模なイベントやパフォーマンス データ テーブルのクリーンアップでも、CPU やディスク リソースが過剰に消費されることはありません。 しかし、アラートと状態変更のテーブルのクリーンアップの場合、大規模なテーブルでは CPU 負荷が高くなるおそれがあります。

データベースも、構成の再配布バースト (MP インポートや大規模なインスタンス スペースの変更によって引き起こされます) の処理時に CPU バウンドになります。 このような場合、構成サービスでは、データベースに対して新しいエージェント構成に関するクエリを実行します。 通常はこれによって、サービスからエージェントに構成の更新プログラムが送信される前にデータベースで 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 に /pae または /3gb スイッチが存在するかどうかを確認します。 ファイルの SSDL セクションに次の 要素を追加します。 これらのオプションは、サーバーが当初 4 GB 以下の RAM を使用してインストールされた場合、および RAM が後でアップグレードされた場合は正しく構成されない可能性があります。

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

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

  既定値は 0 (使用可能なすべてのプロセッサが使用されます) です。 プロセッサが 8 つ以下のサーバーでは 0 を設定しても問題ありません。 プロセッサが 8 つを超えるサーバーの場合、SQL Server ですべてのプロセッサの使用の調整にかかる時間が非生産的な長さになるおそれがあります。 そのため、プロセッサが 8 つを超えるサーバーの場合、通常は並列処理の最大限度の値を 8 に設定してください。 これを行うには、SQL クエリ アナライザーで次のコマンドを実行します。

  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 データベースの LocalizedText テーブルとデータ ウェアハウス データベースの EventPublisher テーブル内の行数

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

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

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

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

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

• % Idle Time: 報告されているディスク アイドル時間。 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 ドライブのスループットは、スピンドルの数、ドライブの速度、チャネルの速度によって大きく異なります。 最善の方法として、ドライブが対応する必要があるバイト数と IOPS 数を SAN ベンダーに確認してください。 アイドル時間 (%) が低く、これら 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 の特定の側面のパフォーマンスを示します。