CMDB ヘルスダッシュボード — 正確性 KPI:実行内容、仕組み、CI の評価方法、保存内容、検証場所Summary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } CMDB Health Correctness がデータが「正しい」かどうかをどのように判断するか考えたことはありますか?スケジュール済みジョブ CMDB ヘルスダッシュボード - 正確性スコアの計算) がスコープ内 CI セットを評価し >包含ルールを適用> 3 つのサブメトリクス (未更新、孤立、重複) を計算してから CMDB ヘルスダッシュボードに表示される正確性 KPI にロールアップすると開始されます。 「正確性」に含まれるもの →正確性は、未更新、孤立、重複の 3 つのサブメトリクスから構築された集計 KPI です (それぞれ CI ごとにスコアが付けられ、ロールアップされます)。 評価を実行するタイミングと方法 →スケジュールされた CMDB ヘルスジョブは、各サブメトリクスを評価し、CI レベルの「健全性結果」を書き込み、スコアをアクティブ化し、削除対象としてマークされた行をクリーンアップします。 CI が Stale とマークされたとき → クラス固有の未更新ルール (継承あり) は、有効期間を提供します。前回の更新時刻が現在より古い CI - 有効期間は古いとフラグが付けられます。→ エンジンは、そのメトリクス/クラスの健全性構成 (cmdb_health_config) の「アクティブなレコード」条件を満たす CI のみを評価します。その他は検討対象から除外されます。→ オプションの動作:古さ評価中に依存 CI タイプをスキップするには、 glide.cmdb.health.staleness_exclude_dependent_cis を true に設定します。→ 未更新の評価は、スループット (内部動作、より高速な実行としてのみ表示) のために 1000 CI のバッチでスキャンされます。→ ドキュメント注: cmdb_ci のデフォルトの 60 日間のルールはベースコンテンツに存在し、クラスごとに上書きできます。 CI が Orphan とマークされたとき → 評価では、クラスに孤立ルール (継承あり) が使用されます。CI がルールの条件に一致する場合、および/またはルールの「関係なし」要件が設定されていて CI に関係性がない場合、CI は孤立しています。→ メトリクス/クラスの健全性構成 (cmdb_health_config) の「アクティブなレコード」条件を満たす CI のみが含まれます。→ 孤立評価は 1000 CI のバッチで処理されます (長時間実行されるスキャンの進捗状況と回復力のため)。 CI が Duplicate とマークされたとき → 識別ルールが「独立」であるクラスには、重複チェックが適用されます。依存クラスはスキップされます。→候補 CI は、 discovery_source = 不明 かつ最終日以内に sys_updated_on 、または空の discovery_source の CI です。これらの候補は、重複を検出するために識別エンジンによって監査されます (この評価はスケジュール済みジョブからのものです)。このロジックの詳細については、「KB0726425) を参照してください。識別エンジンによって既に重複とマークされている → CI は、再フラグ付けを避けるために候補リストから除外されます。→ 健全性構成 (cmdb_health_config) の「アクティブレコード」条件 (メトリクス/クラスごと) により、評価される候補がさらに制限されます。 どの CI を含めるか (包含ルール) → 結果が作成/更新される前に、健全性設定レコード (cmdb_health_config) (メトリクス/クラスごと、継承あり) は、CI セットの事前フィルターとして使用されるエンコードされたクエリを提供します。このフィルターに合格した CI のみが、このサブメトリクスについて評価されます。 健全性構成 & ルールテーブル → CMDB ヘルス構成 :アクティブなレコード条件とルールテーブル — ヘルス構成 (継承あり)、cmdb_health_staleness_rule、およびcmdb_health_orphan_ruleによって、正確性に参加する CI と適用するしきい値/ロジックが決定されます。 →ヘルス構成 (cmdb_health_config) には、メトリクスとクラスごとのactive_record_conditionが格納されます。実行時に、プラットフォームはクラス継承を介して最も具体的な構成を解決し、そのエンコードされたクエリを各 CI に適用して包含を決定します。構成が存在しない場合、CI は含まれていると見なされます。 → Staleness ルール (cmdb_health_staleness_rule) は、applies_toクラスと期間 (「古い」がどの程度古いか) を定義します。エンジンは CI のクラス (およびドメイン) のルールを検索し、未更新を評価するときにその期間を使用します。 →孤立ルール (cmdb_health_orphan_rule) には、CI がいつ孤立するかを決定するために使用されるクラス、条件、オプションのフィルター、およびno_relationshipフラグが含まれます (たとえば、「必須タイプの関係なし」+ オプションの追加フィルター)。 → 包含ルールとメトリクスルールは、パフォーマンスのためにキャッシュされます。ヘルス構成、未更新、および孤立ルール用のキャッシュが存在するため、更新はこれらのキャッシュを経由します。 → 管理者向けのヒント (UI):CI クラスマネージャーの→健全性→健全性包含ルールから、クラスごとの健全性包含ルール (継承あり) を定義/管理できます。これらは、エンジンが評価するアクティブなレコード条件と同じです。 ディスカバリーと CMDB ヘルスソース (未更新) →ディスカバリーは、アイテム (存在しなくなった vCenter CI など) を個別に古いものとしてマークする場合があります。これらはディスカバリーなどのソースとともに表示されます。正確性 KPI で CMDB ヘルス結果のみをアグリゲートするには (ドリルダウンにはディスカバリーソースを引き続き表示できます)、 glide.cmdb.health.src.cmdb_health_audit_only = true に設定します。 結果の保存場所とライフサイクルフラグの仕組み → CI レベルの検出結果は、ci、class_name、メトリクス (未更新/孤立/重複)、source、last_evaluated_on、description/failure_description、active、to_delete などのフィールドを使用してcmdb_health_resultに保持されます。アクティブな結果は最新の評価を反映しています。 to_delete = true とマークされた行は、サイクルの終わりに削除されます。 → 処理とスコアのアクティブ化の後、まだto_delete とマークされている行は削除されます。これは、各サイクルで想定されるクリーンアップステップです。 所有権スタンプ (誰が修正を「所有」しているか) → 結果の所有権に使用されるフィールドは構成可能です。デフォルトでは、所有権は CI のmanaged_by_groupからスタンプされます。変更するには、使用する CI フィールド名に glide.cmdb.health.ci_ownership_field を設定します。(これは、新規/更新された結果にスタンプされた所有者に影響します。 カウントとスコアの生成方法 → ダッシュボードを高速化するために、メトリクスごとの障害数をcmdb_health_result_count にキャッシュできます。→ 実行により、正確性の親とその子のスコアとメトリクスのステータスがアクティブになります。最後に、まだ to_deleteとマークされているすべての行が削除されます。cmdb_health_scorecardテーブルの CMDB 全体、サービス、およびグループのスコアを確認します。 すべてのステージを検証するために使用するテーブル → cmdb_health_result :未更新、孤立、重複の CI ごとの結果。 アクティブ、 to_delete、 ソース、 last_evaluated_on、所有権をチェックします。→ cmdb_health_result_service_map / cmdb_health_result_group_map — どの CI レベルの結果がどのサービスまたはグループにロールアップされるか。→ cmdb_health_result_count :実行中または実行後にダッシュボードで使用されるオプションの集計数。→ cmdb_health_scorecard、 cmdb_health_scorecard_service、 cmdb_health_scorecard_group — KPI のロールアップとステータス。合計、失敗、スコア、ステータスを確認します。 一般的な検証パス → 実行後、cmdb_health_result の新規/進行中の検出結果には、新しい last_evaluated_onactive = true、 to_delete = false が表示されます。→サービス/グループのドリルダウンには、更新されたマッピングが反映されます。スコアカードには、更新されたカウント/スコアが反映されます。to_delete = true のまま残された行は、クリーンアップ中に削除されます。 知っておくべき主なプロパティ → glide.cmdb.health.ci_ownership_field :結果の所有者として使用される CI フィールド (デフォルト managed_by_group)。→ glide.cmdb.health.staleness_exclude_dependent_cis :true の場合、依存 CI タイプを未更新評価から除外します。→ glide.cmdb.health.src.cmdb_health_audit_only — true の場合、正確性 KPI は CMDB ヘルス結果のみを集計します (ディスカバリーはドリルダウンで CI ごとのソースとして表示されることがあります)。 要点 → 未更新 = クラスルールの有効期間中に CI が更新されていません。依存 CI のオプションのスキップ。包含ルールが最初に適用されます。→ Orphan = CI が孤立条件を満たすか、そのクラスルールに基づく関係がないかを示します。包含ルールが最初に適用されます。→ 重複 = 独立クラスの CI、不明/空のdiscovery_sourceによる候補、および識別エンジンの監査によって確認された最近の更新。すでにマークされている重複は無視されます。包含ルールが適用されます。→結果はライフサイクルフラグ付きで cmdb_health_result されます。スコアは実行終了時にアクティブ化され、古い行は通常のクリーンアップの一環として削除されます。