System Center Operations Manager での灰色のエージェントの状態のトラブルシューティング
この記事では、System Center Operations Manager (OpsMgr) でエージェント、管理サーバー、またはゲートウェイが使用できない、または 淡色表示される 問題のトラブルシューティング方法について説明します。
元の製品バージョン: Microsoft System Center 2012 Operations Manager
元の KB 番号: 2288515
エージェント、管理サーバー、またはゲートウェイは、[ 監視 ] ウィンドウのエージェント名とアイコンの色で示されているように、次のいずれかの状態を持つことができます。
| 状態 | 外観モード | 説明 |
|---|---|---|
| Healthy | 緑のチェックマーク | エージェントまたは管理サーバーが正常に実行されています。 |
| クリティカル | 赤いチェックマーク | エージェントまたは管理サーバーに問題があります。 |
| 不明 | 灰色のエージェント名、灰色のチェックマーク | 監視対象のコンピューターで正常性サービスを監視している管理サーバー上の正常性サービス ウォッチャーは、エージェントからハートビートを受信しなくなりました。 正常性サービス ウォッチャーは以前にハートビートを受信しており、状態は正常と報告されていました。 これは、管理サーバーがエージェントから情報を受信しなくなったことも意味します。 この問題は、エージェントを実行しているコンピューターが実行されていない場合、または接続の問題がある場合に発生する可能性があります。 |
| 不明 | 緑の円、チェックマークなし | 検出された項目の状態が不明です。 この特定の検出された項目に対して使用できるモニターはありません。 |
灰色の状態の原因
エージェント、管理サーバー、またはゲートウェイは、次のいずれかの理由で使用できなくなる可能性があります。
- ハートビート エラー
- 無効な構成
- システム ワークフローエラー
- Operations Manager データベースまたはデータ ウェアハウスのパフォーマンスの問題
- 管理サーバーまたはゲートウェイ サーバーのパフォーマンスの問題
- ネットワークまたは認証の問題
- 正常性サービスが実行されていません
問題のスコープ
エージェントが淡色表示された問題のトラブルシューティングを開始する前に、まず Operations Manager トポロジを理解してから、問題のスコープを定義する必要があります。 次の質問は、問題の範囲を定義するのに役立つ場合があります。
- 影響を受けるエージェントの数
- エージェントで同じネットワーク セグメントで問題が発生していますか?
- エージェントは同じ管理サーバーに報告しますか?
- エージェントはどのくらいの頻度で入り、灰色の状態のままですか?
- 通常、この状況からどのように復旧しますか (たとえば、エージェントの正常性サービスを再起動し、キャッシュをクリアし、自動回復に依存します)。
- これらのエージェントに対してハートビート エラー アラートは生成されますか?
- この問題は、1 日の特定の時間に発生しますか?
- これらのエージェントを別の管理サーバーまたはゲートウェイにフェールオーバーした場合、この問題は解決しませんか?
- この問題はいつ開始されましたか?
- エージェント、管理サーバー、またはゲートウェイまたは管理グループに変更が加えられましたか?
- 影響を受けるエージェントは Windows クラスター化されたシステムですか?
- Health Service State フォルダーはウイルス対策スキャンから除外されていますか?
トラブルシューティング戦略
トラブルシューティング戦略は、どのコンポーネントが非アクティブであるか、そのコンポーネントがトポロジ内にあり、問題がどの程度広がっているかによって決まります。 次の条件を検討してください。
- 特定の管理サーバーまたはゲートウェイに報告するエージェントが使用できない場合は、管理サーバーまたはゲートウェイ レベルでトラブルシューティングを開始する必要があります。
- 特定の管理サーバーにレポートするゲートウェイが使用できない場合は、管理サーバー レベルでトラブルシューティングを開始する必要があります。
- エージェントレス システム、ネットワーク デバイス、Unix および Linux サーバーの場合は、これらのオブジェクトを監視しているエージェント、管理サーバー、またはゲートウェイからトラブルシューティングを開始する必要があります。
- トラブルシューティングは通常、使用できないコンポーネントのすぐ上のレベルから開始されます。
シナリオ 1
この問題の影響を受けるエージェントはごくわずかです。 これらのエージェントは、別の管理サーバーにレポートします。 エージェントは定期的に使用できなくなります。 問題を一時的に解決するためにエージェント キャッシュをクリアすることはできますが、問題は数日後に再発します。
シナリオ 1 の解決策
このシナリオの問題を解決するには、次の手順に従います。
- 影響を受けるオペレーティング システムに適切な修正プログラムを適用します。
- ウイルス対策スキャンからエージェント キャッシュを除外します。 詳細については、「 Operations Manager に関連するウイルス対策の除外に関する推奨事項」を参照してください。
- 正常性サービスを停止します。
- エージェント キャッシュをクリアします。
- 正常性サービスを開始します。
シナリオ 2
この問題の影響を受けるエージェントはごくわずかです。 これらのエージェントは、別の管理サーバーにレポートします。 エージェントは常に非アクティブなままです。 エージェント キャッシュをクリアすることはできますが、この問題は解決されません。
シナリオ 2 の解決策
このシナリオの問題を解決するには、次の手順に従います。
正常性サービスが有効になっていて、現在管理サーバーまたはゲートウェイで実行されているかどうかを確認します。 正常性サービスが応答を停止した場合は、問題の原因を特定するために、サービスハング モードで ADPlus ダンプを生成します。 詳細については、「ADPlus.vbs を使用して "ハング" と "クラッシュ" のトラブルシューティングを行う方法」を参照してください。
エージェントの 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: <値>。
クリーンアップ: <値>次の特定のイベントが見つからない場合は、次のガイドラインに従ってください。
イベント 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 の解決策
このシナリオの問題を解決するには、次の手順に従います。
管理サーバーまたはゲートウェイが監視しているワークロードの種類を調べてみます。 このようなワークロードには、ネットワーク デバイス、クロスプラットフォーム エージェント、代理トランザクション、Windows エージェント、エージェントレス コンピューターなどがあります。
正常性サービスが管理サーバーまたはゲートウェイで実行されているかどうかを判断します。
管理サーバーがメンテナンス モードで実行されているかどうかを確認します。 必要に応じて、メンテナンス モードからサーバーを削除します。
シナリオ 2 に記載されているすべてのイベントについて、エージェントの Operations Manager イベント ログを調べます。 イベント ID 21006 がある場合は、「 シナリオ 2 の解決」で説明されているのと同じガイドラインに従ってください。 また、この場合、このイベントは、管理サーバーまたはゲートウェイが親サーバーと通信できないことを示します。 ゲートウェイの場合、親サーバーは任意の管理サーバーである可能性があります。 ( シナリオ 2 の解決策の手順 3 を参照してください)。
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また、実行アカウントの構成が正しくないか、実行アカウントのアクセス許可がないため、イベント ID 3155X がログに記録されることがあります。
注:
管理サーバーまたはゲートウェイのパフォーマンスとSQL Serverパフォーマンスのトラブルシューティングについては、「シナリオ 4 の解決策」セクションを参照してください。
シナリオ 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がアドレス指定できるメモリの量が制限される可能性があります。 これらのシステムでは、スイッチを/paeBoot.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
メモリ負荷を識別するためのカウンター
| パフォーマンス カウンター名 | 説明 |
|---|---|
| MSSQL$<instance>: Buffer Manager: ページの平均余命 | バッファー プールにページが保持される期間。 この値が 300 秒未満の場合は、サーバーがより多くのメモリを使用できることを示している可能性があります。 また、インデックスの断片化が発生する可能性もあります。 |
| MSSQL$<instance>: Buffer Manager: Lazy writes/sec | 遅延ライターは、ページをディスクに移動することで、バッファー内の領域を解放します。 一般に、値は一貫して 1 秒あたり 20 回の書き込みを超えないようにしてください。 理想的には、0 に近いでしょう。 |
| メモリ: 使用可能な MB | 100 MB 未満の値は、メモリ不足を示している可能性があります。 メモリの負荷は、この量が 10 MB 未満の場合に明確に存在します。 |
| プロセス: プライベート バイト: _Total | これは、すべてのプロセスが組み合わせて使用するメモリ (物理とページ) の量です。 |
| プロセス: ワーキング セット: _Total | これは、すべてのプロセスが組み合わせて使用する物理メモリの量です。 このカウンターの値が の値 Process: Private Bytes: _Totalを大幅に下回っている場合は、プロセスのページングが大きすぎることを示します。 10% を超える差はおそらく重要です。 |
ディスクの負荷を識別するためのカウンター
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 のパフォーマンスを監視およびトラブルシューティングするために使用できるパフォーマンス カウンターについて説明します。
ゲートウェイ サーバーロール
全体的なパフォーマンス カウンター
これらのカウンターは、ゲートウェイの全体的なパフォーマンスを示します。
| パフォーマンス カウンター名 |
|---|
| Processor(_Total)\% Processor Time |
| Memory\% Committed Bytes In Use |
| ネットワーク インターフェイス(*)\Bytes Total/sec |
| LogicalDisk(*)\% アイドル時間 |
| LogicalDisk(*)\Avg. Disk Queue Length |
Operations Manager プロセスの汎用パフォーマンス カウンター
これらのカウンターは、ゲートウェイでの Operations Manager プロセスの全体的なパフォーマンスを示します。
| パフォーマンス カウンター名 | 説明 |
|---|---|
| Process(HealthService)\% プロセッサ時間 | |
| Process(HealthService)\Private Bytes | このゲートウェイが管理しているエージェントの数によっては、この数が異なる場合があり、数百メガバイトになる可能性があります |
| Process(HealthService)\Thread Count | |
| Process(HealthService)\Virtual Bytes | |
| Process(HealthService)\Working Set | |
| Process(MonitoringHost*)\% プロセッサ時間 | |
| Process(MonitoringHost*)\Private Bytes | |
| Process(MonitoringHost*)\Thread Count | |
| Process(MonitoringHost*)\Virtual Bytes | |
| Process(MonitoringHost*)\ワーキング セット |
Operations Manager 固有のパフォーマンス カウンター
これらのカウンターは、ゲートウェイ上の Operations Manager の特定の側面のパフォーマンスを示す Operations Manager 固有のカウンターです。
| パフォーマンス カウンター名 | 説明 |
|---|---|
| Health Service\Workflow Count | |
| Health Service 管理グループ(*)\Active File Uploads | このゲートウェイが処理しているファイル転送の数。 これは、エージェントにアップロードされる管理パック ファイルの数を表します。 この値が長い間高いレベルに留まり、特定の時点で管理パックのインポートがあまりない場合、これらの条件によってファイル転送に影響する問題が発生する可能性があります。 |
| Health Service 管理グループ(*)\Send Queue % Used | 永続キューのサイズ。 この値が長い間 10 より大きいままであり、ドロップしない場合は、キューがバックアップされていることを示します。 この状態は、管理サーバーまたはデータベースがビジーまたはオフラインであるため、Operations Manager システムが過負荷になっていることが原因で発生します。 |
| OpsMgr コネクタ\受信バイト数 | ゲートウェイが受信したネットワーク バイト数 (つまり、展開前の受信バイト数)。 |
| OpsMgr コネクタ\送信バイト数 | ゲートウェイによって送信されるネットワーク バイト数 (つまり、圧縮後の送信バイト数)。 |
| OpsMgr Connector\Data Bytes Received | ゲートウェイが受信したデータ バイト数 (つまり、展開後の受信データの量)。 |
| OpsMgr Connector\Data Bytes Transmitted | ゲートウェイによって送信されたデータ バイト数 (つまり、圧縮前の送信データの量)。 |
| OpsMgr Connector\Open Connections | ゲートウェイで開いている接続の数。 この数は、ゲートウェイに直接接続されているエージェントまたは管理サーバーの数と同じである必要があります。 |
管理サーバーの役割
全体的なパフォーマンス カウンター
これらのカウンターは、管理サーバーの全体的なパフォーマンスを示します。
| パフォーマンス カウンター名 |
|---|
| Processor(_Total)\% Processor Time |
| Memory\% Committed Bytes In Use |
| ネットワーク インターフェイス(*)\Bytes Total/sec |
| LogicalDisk(*)\% アイドル時間 |
| LogicalDisk(*)\Avg. Disk Queue Length |
Operations Manager プロセスの汎用パフォーマンス カウンター
これらのカウンターは、管理サーバー上の Operations Manager プロセスの全体的なパフォーマンスを示します。
| パフォーマンス カウンター名 | 説明 |
|---|---|
| Process(HealthService)\% プロセッサ時間 | |
| Process(HealthService)\Private Bytes | この管理サーバーが管理しているエージェントの数によっては、この数が異なる場合があり、数百メガバイトになる可能性があります。 |
| Process(HealthService)\Thread Count | |
| Process(HealthService)\Virtual Bytes | |
| Process(HealthService)\Working Set | |
| Process(MonitoringHost*)\% プロセッサ時間 | |
| Process(MonitoringHost*)\Private Bytes | |
| Process(MonitoringHost*)\Thread Count | |
| Process(MonitoringHost*)\Virtual Bytes | |
| Process(MonitoringHost*)\ワーキング セット |
Operations Manager 固有のパフォーマンス カウンター
これらのカウンターは、管理サーバー上の Operations Manager の特定の側面のパフォーマンスを示す Operations Manager 固有のカウンターです。
| パフォーマンス カウンター名 | 説明 |
|---|---|
| Health Service\Workflow Count | この管理サーバーで実行されているワークフローの数。 |
| Health Service 管理グループ(*)\Active File Uploads | この管理サーバーが処理しているファイル転送の数。 これは、エージェントにアップロードされる管理パック ファイルの数を表します。 この値が長い間高いレベルに留まり、特定の時点で管理パックのインポートがあまりない場合、これらの条件によってファイル転送に影響する問題が発生する可能性があります。 |
| Health Service 管理グループ(*)\Send Queue % Used | 永続キューのサイズ。 この値が長い間 10 より大きいままであり、ドロップしない場合は、キューがバックアップされていることを示します。 この状態は、Operations Manager システム (ルート管理サーバーなど) がビジー状態であるか、オフラインになっているため、Operations Manager システムが過負荷になっていることが原因で発生します。 |
| Health Service Management Groups(*)\Bind Data Source Item Drop Rate | データベースまたはデータ ウェアハウスデータ収集書き込みアクションの管理サーバーによって削除されるデータ項目の数。 このカウンター値が でない 0場合、管理サーバーまたはデータベースは、受信データ項目を十分に高速に処理できないか、データ項目バーストが発生しているためにオーバーロードされます。 削除されたデータ項目は、エージェントによって再送信されます。 オーバーロードまたはバーストの状況が完了すると、これらのデータ項目がデータベースまたはデータ ウェアハウスに挿入されます。 |
| Health Service Management Groups(*)\Bind Data Source Item Incoming Rate | データベースまたはデータ ウェアハウスデータ収集書き込みアクションに対して管理サーバーが受信したデータ項目の数。 |
| Health Service 管理グループ(*)\Bind Data Source Item Post Rate | 管理サーバーがデータ収集書き込みアクションのためにデータベースまたはデータ ウェアハウスに書き込んだデータ項目の数。 |
| OpsMgr コネクタ\受信バイト数 | 管理サーバーが受信したネットワーク バイト数 (つまり、展開前の受信バイトのサイズ)。 |
| OpsMgr コネクタ\送信バイト数 | 管理サーバーによって送信されるネットワーク バイト数 (つまり、圧縮後の送信バイトのサイズ)。 |
| OpsMgr Connector\Data Bytes Received | 管理サーバーが受信したデータ バイト数 (つまり、展開後の受信データのサイズ)。 |
| OpsMgr Connector\Data Bytes Transmitted | 管理サーバーから送信されたデータ バイト数 (つまり、圧縮前の送信データのサイズ)。 |
| OpsMgr Connector\Open Connections | 管理サーバーで開いている接続の数。 直接接続されているエージェントまたはルート管理サーバーの数と同じである必要があります。 |
| OpsMgr データベース書き込みアクション モジュール(*)\Avg. Batch Size | データベース書き込みアクション モジュールによって受信されるデータ項目またはバッチの数。 この数が 5,000 の場合、データ項目バーストが発生します。 |
| OpsMgr DB 書き込みアクション モジュール(*)\Avg. 処理時間 | データベース書き込みアクション モジュールがバッチをデータベースに挿入するのにかかる秒数。 この数値が 60 を超えることが多い場合は、データベース挿入のパフォーマンスの問題が発生しています。 |
| OpsMgr DW ライター モジュール(*)\Avg. Batch Processing Time,ms | データ ウェアハウスにデータ項目のバッチを挿入するデータ ウェアハウス書き込みアクションのミリ秒数。 |
| OpsMgr DW ライター モジュール(*)\Avg. Batch Size | データ ウェアハウス書き込みアクション モジュールによって受信されたデータ項目またはバッチの平均数。 |
| OpsMgr DW ライター モジュール(*)\Batches/sec | 1 秒あたりのデータ ウェアハウス書き込みアクション モジュールによって受信されたバッチの数。 |
| OpsMgr DW ライター モジュール(*)\Data Items/sec | 1 秒あたりのデータ ウェアハウス書き込みアクション モジュールによって受信されたデータ項目の数。 |
| OpsMgr DW ライター モジュール(*)\Drop Data Item Count | データ ウェアハウス書き込みアクション モジュールによって削除されたデータ項目の数。 |
| OpsMgr DW ライター モジュール(*)\Total Error Count | データ ウェアハウス書き込みアクション モジュールで発生したエラーの数。 |