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 Dashboard (CMDB ヘルスダッシュボード) のコンプライアンス KPI を見て、なぜ空に見えたり、0 で止まったり、完全性や正確性のようで動作しないのか疑問に思ったことはありませんか?あなたは一人ではありません - そしてそれには非常に具体的な理由があります。 コンプライアンスは、ダッシュボード上の他のすべての KPI とはまったく異なる仕組みをします。CI はスキャンされません。フィールド値は評価されません。関係性はチェックしません。代わりに、個別に構成して実行するデータ認定監査に完全に依存します。健全性ジョブは、これらの監査で既に生成されたものを読み取るだけです。監査が正しく設定されていないか実行されていない場合、コンプライアンススコアは 0 または欠落しており、健全性ジョブは問題ではありません。 この記事では、それがどのように機能するか、エンジンが何を探しているのか、どこで問題が発生しているのかを正確に説明します。 コンプライアンスと他の KPI の違い — これは理解しておくべき最も重要なことです 多くの混乱は、コンプライアンスが完全性または正確性と同じように機能すると仮定することから生じます。そうではありません。 KPI健全性ジョブは CI を直接スキャンしますか?スコアの要因は何ですか?完全性はいCI ごとに評価されるフィールド入力ルール正確性はいCI ごとに評価された未更新、孤立、および重複ルールコンプライアンスいいえ個別に構成するデータ認定監査の結果 → 完全性と正確性については、健全性ジョブが評価者です。CI を確認し、合格と失敗を判断します。 → コンプライアンスの場合、健全性ジョブはリーダーにすぎません。データ認定監査で既に生成された行cert_audit_resultを調べ、そこからの失敗をカウントします。 → これは、コンプライアンスには、他の KPI にはない 2 段階の依存関係があることを意味します。 ステップ何が起こる必要があるかステップ 1データ認定監査が構成され、アクティブになっており、実際に実行されている必要があります。これにより、state = Failed の cert_audit_result 行が生成されます。ステップ 2CMDB ヘルスジョブが実行され、これらの行が読み取られ、エラーが書き込まれ、スコアが計算されます → ステップ 1 が正しく行われていない場合、ステップ 2 では何も生成されません。エラーもアラートもなく、スコアが欠落しているかゼロであるだけです。 コンプライアンスに実際に含まれるもの →コンプライアンスは、子サブメトリクスが 1 つのみである AUDIT を持つ親 KPI です。 →監査は、アクティブなデータ認定監査に照らして CI を評価します。前回の監査実行期間内に cert_audit_result に [失敗] 行がある場合、CI はコンプライアンス違反となります。 → AUDIT は唯一の子であるため、エンジンは個別のコンプライアンススコアカード行を書き込むことはありません。ダッシュボード KPI ウィジェットは、cmdb_health_scorecardから AUDIT の行を読み取ります。調査するときは、常にコンプライアンスのsys_idではなく、監査のsys_idでフィルタリングしてください。 評価を実行するタイミングと方法 → スケジュール済みジョブは、実行ごとに新しい ComplianceManager を起動してインスタンス化します。ジョブがグローバルドメインから実行されていることを確認します。サブドメインからトリガーされた場合は、すぐに終了します。 → ミューテックスは、2 つの実行を同時に実行できないようにします。以前の実行が glide.cmdb.health.max.inactivity.period 日 (デフォルトは 1 日) 以上アクティビティがない状態でIN_PROGRESSスタックしているように見える場合、ハングした実行はクリーンアップされ、新しい実行が開始されます。 → エンジンは AUDIT をコンプライアンスの唯一のアクティブな子として検出し、監査バッチセットアップを開始します。 どの監査が選択されるか → エンジンは、実行の開始時にcert_auditクエリを実行します。次の 2 つのタイプの監査が対象となります。 監査タイプ選択される条件テンプレートベースアクティブ、テンプレートがアサインされている、ターゲットがcmdb_ciまたはサブクラステーブルがあるスクリプト化済みアクティブ、タイプ = スクリプト化、テンプレートなし、ターゲットcmdb_ciまたはサブクラステーブル → 非 CMDB テーブルを対象とする監査は、アクティブで完全に構成されている場合でも、取得されません。クエリはcmdb_ciサブクラステーブルのみを参照します。 → 各認定監査は 1 つの処理バッチになり、すべてグローバルドメインの下にロードされます。 コンプライアンススコアが 0 であるか、クラスが欠落している最も一般的な理由 これは、お客様の混乱のほとんどが発生する場所です。コードから正確な理由を、発生頻度順に示します。 →監査は実行されていません。cert_auditのlast_run_dateが空です。プロセッサーは監査をサイレントにスキップし、スキップされたフラグで完了としてマークします。エラーは表示されません。失敗は書き込まれません。監査は単にスコアに寄与しません。 → スクリプト化された監査が updateLastRunDate を呼び出さない - スクリプト化された監査の場合、last_run_dateが自動的に更新されることはありません。スクリプトは、結果が保持される前に、スクリプトの先頭で明示的に new SNC.CertificationProcessing().updateLastRunDate(auditId) を呼び出す必要があります。この呼び出しがない場合、last_run_dateは永遠に空のままになり、正常性ジョブは、監査自体が何回実行されたかに関係なく、正常性の実行ごとに監査をスキップします。 → 健全性ジョブが実行されたときに実行されている監査 — エンジンはprev_last_run_dateを使用して、以前に完了した実行ウィンドウにフォールバックします。監査が 1 回しか実行されていない場合は、prev_last_run_dateも空になり、再度監査はスキップされます。 →監査は間違ったテーブルをターゲットにします。cert_audit.table が cmdb_ci またはそのサブクラスのいずれでもない場合、ヘルスジョブはそれを認識しません。 →監査が実行されましたが、失敗した結果は生成されませんでした。last_run_dateは入力されていますが、該当ウィンドウ内の cert_audit_result に失敗行がありません。すべての CI が合格したか、監査条件が何も一致しませんでした。 →監査は非アクティブです。バッチクエリから完全に除外されます。 監査結果の期間の仕組み → 各監査バッチについて、プロセッサーはcert_audit_result行をプルする期間を決定します。 シナリオ使用されたウィンドウ通常:監査が前回の実行を完了しました現在までlast_run_date監査が現在実行中またはエラー状態の場合prev_last_run_dateからlast_run_date監査が一度も実行されていないか、前回の実行状態が不明の場合監査は完全にスキップされます CI がコンプライアンス違反とマークされたとき → プロセッサーは、ステータス = 失敗で、sys_created_onがその監査のために決定されたウィンドウ内にある行をcert_audit_resultに照会します。 → 結果は、CI sys_id順にバッチでフェッチされます。デフォルトのバッチサイズはパスあたり 10,000 行で、最大で 100,000 行です。有効サイズは、メトリクスで構成されたfailure_thresholdによっても制限されます。 → CI は、同じ監査実行に対して複数の失敗行をcert_audit_resultに持つことができます (失敗したフィールドまたは条件ごとに 1 行ずつ)。これらはすべて、その CI の単一のcmdb_health_result行の説明に追加され、監査名、日付、フィールド名、目標値、および実際の不一致値がキャプチャされます。 合計の計算方法:他の KPI とのもう 1 つの重要な違い → これはほとんどのお客様を驚かせます。コンプライアンススコアで使用される合計は、cmdb_ciからのクラス内のすべての CI の数ではありません。 → 合計は、前回の実行ウィンドウで監査によって実際に評価された CI の数、つまり、合格か不合格かにかかわらず、そのウィンドウのcert_audit_resultに表示される CI の数です。 → CI がアクティブな監査によって評価されなかった場合、その CI は合計に含まれません。合格とはみなされません。失敗とは見なされません。スコアにはまったく見えません。 監査の実行後に削除された CI → (結果の null sys_idまたはクラス名) も、合計から除外されます。 スコアの計算方法 →スコア計算は、AUDIT が完了または最大エラーステータスに達した後に開始されます。 → スコアリングが開始される前に、エンジンは読み込みレプリカが追いついたかどうかを確認します。そうでない場合、スコアリングは遅延し、glide.cmdb.health.metricProcessor.scoreCalculationDelay 分 (デフォルトは 15 分) 後に再試行されます。 → 各 CI クラスのスコアは、失敗を合計で除算し、100 を掛けて、最も近い整数に丸めたものです。 値ソースtotalそのクラスとそのすべてのサブクラスcert_audit_result最後のウィンドウの CIfailedそのクラスとすべてのサブクラスについて、to_delete = false の cmdb_health_result からの CI sys_idsの個別の数scoreMath.round((failed * 100) / total) → COMPLIANCE 親スコアカード行は書き込まれません。ダッシュボードには、メトリクス = AUDIT の sys_id でステータス = COMPLETE のcmdb_health_scorecardが表示されます。 → クラスの合計 = 0 の場合、スコアカード行は書き込まれず、そのクラスはダッシュボードにまったく表示されません。 → スコアは故障率であり、健全性のパーセンテージではありません。スコア = 20 は、監査対象 CI の 20% が失敗したことを意味します。スコア = 0 は、エラーが検出されなかったことを意味します。 スコアを有効にして結果をクリーンアップする方法 → スコアリングが完了すると、エンジンは次の順序でクリーンアップを実行します。 →失敗した CI (to_delete = false) は、cmdb_health_resultでアクティブ = true に設定されます。解決済みの CI (to_delete = true) は、アクティブ = false に設定されます。 → すべての IN_PROGRESS スコアカード行が COMPLETE に変わります。前の COMPLETE 行は HISTORIC になります。この後、新しいスコアがダッシュボードに表示されます。 → 親コンプライアンスメトリクスのステータスは、すべての子がクリーンに終了した場合は COMPLETE に設定され、すべての CI をスキャンする前に失敗のしきい値に達した子があれば INCOMPLETE に設定されます。 → to_delete = true とマークされているcmdb_health_result行はすべて物理的に削除されます。リンクされたタスクを含む行は、関連付けられたビジネスルールがタスクをクローズできるように、GlideRecord を介して削除されます。 結果とスコアが保存される場所 → cmdb_health_result — 失敗した CI ごとに 1 行。メトリクスによるフィルタリング = AUDIT のsys_id。キーフィールド: ci、class_name、metric、source、description、task、active、to_delete、last_evaluated_on、discovery_source、ownership → cmdb_health_result_count:ドメインごとのメトリクスごとの集計された失敗数。実行中のカウントクエリの繰り返しを避けるために使用されます。 → cmdb_health_scorecard — ドメインごとのクラスごとに 1 行。メトリクス = AUDIT の sys_id およびステータス = COMPLETE でフィルタリングします。キーフィールド: class、metric、total、failed、score、status、evaluated_on → cmdb_health_scorecard_service/cmdb_health_scorecard_group — スコアパスが有効になっている場合、サービスまたは CMDB グループによってキーとなる同じ構造。 すべてのステージを検証するために使用するテーブル → cert_audit — 監査はアクティブですか?last_run_date入力されていますか?cmdb_ciサブクラステーブルをターゲットにしていますか。スクリプト化された監査の場合、スクリプトは最初に updateLastRunDate を呼び出しますか。 → cert_audit_result — 想定される期間内に、監査sys_idにステータス = 失敗した行はありますか?これは、すべてのコンプライアンス違反の生のソースです。このテーブルに失敗した行がない場合、健全性ジョブには処理するものがありません。 → cmdb_health_processor_status — 監査バッチは処理されましたか、それともスキップされましたか?スキップ = true フラグは、last_run_dateがないか解決不可能な実行ステータスが原因で監査がスキップされたことを意味します。 → cmdb_health_result — メトリクスによるフィルタリング = AUDIT のsys_id。失敗した CI ごとに active、to_delete、source、last_evaluated_on、description を確認します。 → cmdb_health_result_count:実行中および実行後のドメインごとの集計された障害数。 → cmdb_health_scorecard — メトリクス = AUDIT の sys_id およびステータス = COMPLETE でフィルタリングします。合計、不合格、およびクラスごとのスコアを確認します。欠落しているクラスは、合計が 0 であったことを意味します。監査は、最後のウィンドウでそのクラスの CI を評価しませんでした。 → cmdb_health_metric_status — 実行がIN_PROGRESSでスタックしたのか、それとも未完了で終わったのか? 一般的な検証パス → cert_audit を確認します — アクティブか？last_run_date入力されていますか?監査を実行したことはありますか? →cert_audit_result を確認します — 前回の実行ウィンドウ内に失敗した行はありますか？ →cmdb_health_processor_status を確認します — 処理済みですか、それともスキップ済みですか？ → cmdb_health_result で AUDIT の sys_id に対して active = true、to_delete = false の行を確認します。 → cmdb_health_scorecard を確認します — AUDIT の sys_id の行で合計、failed、スコアが更新されていますか？ 要点 →コンプライアンスは、すべてデータ認定監査によって推進されます。健全性ジョブは監査結果を読み取りますが、監査結果は生成しません。監査が実行されておらず、cert_audit_resultで [失敗] の結果が生成されない場合、コンプライアンススコアは常に空になります。 → コンプライアンス KPI スコアは、監査サブメトリクスのスコアです。COMPLIANCE の親が独自のスコアカード行を取得することはありません。常に AUDIT のsys_idを使用してcmdb_health_resultとcmdb_health_scorecardをクエリします。 → cert_auditでlast_run_dateが空の場合、健全性の実行のたびに監査がサイレントにスキップされます。スクリプト化された監査の場合、スクリプトの先頭で updateLastRunDate が呼び出されない限り、これは常に当てはまります。 → スコア式の合計は、クラス内のすべての CI ではなく、前回の実行ウィンドウで監査が実際に評価した CI のみです。監査のスコープ外の CI は、コンプライアンスの採点ではまったく表示されません。 cmdb_health_result の結果と cmdb_health_scorecard のスコアはどちらも、コンプライアンスではなく、監査のsys_idをメトリクスの参照として使用します。 →スコア = 失敗率。スコア 0 = エラーは見つかりませんでした。ダッシュボードにクラスがない場合、そのクラスの合計が 0 であったことを意味します。前回の実行では、監査ではそのクラスの CI は評価されませんでした。