CMDB 健全性プロセスの追跡
次の情報を使用して、CMDB 健全性プロセスの問題を追跡して解決します。
ログ記録
デフォルトでは、ソース名 CMDBHealth で syslog テーブルにエラーメッセージのみが記録されます。「情報」および「警告」メッセージ (通常は各処理サイクルの開始時と終了時に記録されます) のログ記録を有効にするには、システム プロパティ glide.cmdb.logger.use_syslog.CMDBHealth を更新します。このプロパティの使用方法については、「CMDB 健全性システムプロパティ」を参照してください。
処理ステータス
ジョブスケジュールが有効で、CMDB ダッシュボードにデータが表示されていない場合は、CMDB 健全性評価指標ステータス [cmdb_health_metric_status] テーブルで処理ステータスを確認できます。inactiveな測定基準のステータスに応じて、続行方法を決定します。
最初は、すべての測定基準の状態が「処理中」です。
- 完了
- すべてのクラスが処理され、失敗の数は最大の失敗のしきい値を下回ります。
- エラー最大回数
- この測定基準の失敗数は、最大の失敗のしきい値に達しました。処理は中断され、次回の実行時に再開されます。
- 日次タイムアウトによる一時停止
- プロセッサーが処理時間の制限に達しました。処理は一時停止され、次の実行で再開されます。
- 完了
- すべての関連測定基準が完了状態になり、スコア計算が完了します。
- 未完了
- 関連測定基準の 1 つが最大障害のしきい値に達したため、スコアは計算されません。
- 日次タイムアウトによる一時停止
- 関連測定基準の 1 つが処理時間の制限に達したためタイムアウトしました。
処理時間
測定基準の処理がタイムアウトした場合、処理に時間がかかりすぎるクラスを見つけることができます。この情報を使用して、妥当性確認ルールが弱いかどうかを調べます。
各測定基準の進捗状況は、CMDB 健全性 - プロセッサー ステータス テーブル [cmdb_health_processor_status] で追跡されます。測定基準のために処理されたクラスのステータスは完了であり、まだ処理されていないクラスはドラフトです。各クラスの更新時間を調べることで、各クラスの処理時間の長さを計算できます。
壊れた階層が原因で孤立したレコード
孤立ルールがアクセスおよび削除できない孤立 CI を検出することがあります。または、孤立レコードを表示するリスト ビューと合計レコード数との間に不一致が起きることがあります。これらの結果は、CMDB 階層内の 1 つのテーブルからのみデータベースのレコードが削除されるためです。
これらの CI レコードは GlideRecord からアクセスできず、データベースから直接削除する必要があります。したがって、この場合、データベースから孤立 CI を削除するには、サポートにお問い合わせいただく必要があります。
孤立テストの結果は、階層が壊れている正確な場所の詳細を提供します。たとえば、「この cmdb_ci_linux_server CI [91054fc24f22520053d6e1d18110c713] は cmdb_ci_computer テーブルにないレコードです」というメッセージは、その sys_id のレコードを CMDB、cmdb_ci、cmdb_ci_hardware、cmdb_ci_server、および cmdb_ci_linux_server テーブルから削除する必要があることを意味します (コンピューター クラスは階層内のハードウェア クラスとサーバー クラスの間です)。
スクリプト化された監査のスキップ
スクリプト化された監査の結果がコンプライアンス KPI に含まれていない場合、エラーメッセージが記録されます。その理由は、監査のスクリプトが更新されておらず、[最終実行日] フィールドに入力されていないためです。[最終実行日] の値がないと、CMDB 健全性はこれらの実行結果を最近の完全な監査実行の一部として識別することができず、その結果をスキップします。