CMDB ヘルス ダッシュボードで最大障害しきい値エラーを解決する方法<!-- /*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: ; } } 健全性メトリクスを満たしていない構成アイテム (CI) の数が、設定された失敗のしきい値 (デフォルトは 50,000) に達すると、システムは現在のサイクルのメトリクスの処理を停止します。CMDB ヘルス評価指標ステータス [cmdb_health_metric_status] テーブルの評価指標ステータスは [エラーの最大数] に設定され、その評価指標に対して集計された健全性スコアは生成されません。処理は、次のスケジュール済みサイクルで再試行されます。データが変更されていない場合は、同じことが再び発生します。 この記事では、これらのエラーを回避するために障害のしきい値を増やすのではなく、根本的な原因を特定して解決し、CMDB ヘルスを長期的に改善することに焦点を当てます。 開始する前に この記事は、3 つの健全性メトリクス (完全性、正確性、コンプライアンス) 別にまとめられています。影響を受けるメトリクスのセクションに移動して、最大障害エラーの原因を特定し、使用している環境に適用できる解決方法を判別して、手順に従って解決します。 CMDB ワークスペースから健全性ダッシュボードにアクセスします。従来の健全性ダッシュボードは廃止されました。 必要なロール： Australia リリース以降、ヘルス構成設定にアクセスして変更するには、sn_cmdb_admin ロールが必要です。Australia より前のリリースでは、itil_admin ロールが必要です。 根本原因の特定 修正を実装する前に、障害の原因を特定します。診断アプローチは、完全性、正確性、およびコンプライアンスのメトリクスでも同じです。 健全性ダッシュボードから、メトリクスカード (完全性、正確性、またはコンプライアンス) を選択して、失敗スコアカードを表示します。影響を受けるクラスの失敗スコアカードを選択して、失敗のリストビューを開きます。情報アイコンを選択すると、失敗の説明が表示され、フィールドの欠落、CI の重複、孤立状態、古いデータ、監査の失敗などの原因を特定できます。障害の一般的なパターンを探して、最も効果的な解決方法を決定します。 ディスカバリーソース列を追加すると、問題のあるデータを提供しているデータソースを特定するのに役立ちます。 完全性 完全性のエラーの最大値は、多数の CI で必須または推奨属性が欠落している場合に表示されます。失敗スコアカードには、最も多くの問題があるクラスが表示されます。 健全性構成から不要な属性を削除 使用タイミング:属性は、特に多くの CI にわたって属性が欠落している場合、必須または推奨どおりにビジネス上の意味をなしません。 CI クラスマネージャーに移動します。階層を選択し、影響を受けるクラスを選択します。[健全性] タブを選択します。 推奨属性の場合:[完全性] セクションで、問題のある属性を見つけて削除します。必須属性の場合:[属性] セクションに移動し、必須フィールドでソートし、属性を必須でないに設定します。 完全性ジョブを保存して再度実行します。 必要な属性の例 推奨属性の例 データソース構成を修正 使用するタイミング: 属性が存在するはずですが、データソース構成の問題により存在しません。この方法では、データソースが必要な情報を確実に適切にキャプチャして入力することで、根本原因に対処します。 データを提供するディスカバリーソースを特定します。データソースまたはコネクタ構成に移動します。特定の属性のマッピング構成を確認します。属性がソースシステムから正しくマッピングされていることを確認します。データを適切にキャプチャして入力するために、必要に応じてマッピング構成を変更します。 包含ルールを使用してクラスを除外する 使用タイミング:特定のクラスは処理にコストがかかるか、ヘルスアセスメントに有効なデータが含まれていません。 問題のあるクラスを健全性の計算から除外する包含ルールを作成します。常に失敗するクラスの評価をスキップするようにルールを構成します。 正確性 - 重複 重複の最大失敗回数が表示されている場合は、失敗スコアカードに表示されている上位 10 件のクラスを調べます。 重複排除テンプレート修正を使用 使用タイミング:解決が必要な正当な重複 CI があります。 重複 CI に添付されている重複排除タスクを探す重複を解決するには、重複排除テンプレートの修正を使用します。 (グローバル) 包含ルールを使用 使用タイミング:特定のクラスには、対処が困難な重複した問題が一貫して存在します。グローバルレベルで包含ルールを適用して、簡単に解決できないクラスを除外します。 正確性 - 孤立 CI 孤立 CI の最大エラー数については、スコアカードを調べて、孤立した問題の数が最も多いクラスを特定します。失敗の説明には、各 CI が孤立チェックに失敗する理由が説明されています。 孤立条件を調整 使用するタイミング:誤検出を減らすために、孤立ルールの条件を改善する必要があります。 CI クラスマネージャーに移動します。スコアカードから孤立した失敗が最も多いクラスを選択します。[健全性] タブを選択します。[健全性] セクションで Correctness を選択します。孤立ルールを確認し、定義された条件を評価します。意味がない場合は条件を調整し、失敗を減らすために条件を変更します。 包含ルールを使用 使用タイミング:特定のクラスは簡単に解決できないか、孤立チェックは意味がありません。グローバルレベルで包含ルールを適用して、これらのクラスを除外します。 正確性 - 古い CI 未更新の最大エラーを処理する場合は、古い CI スコアカードを選択して、古い CI の数が最も多いクラスを特定します。 未更新しきい値を調整 使用タイミング:未更新しきい値は、環境に対して制限が厳しすぎます。 CI クラスマネージャーに移動します。影響を受けるクラスを選択します。健全性> 正確性 > 未更新ルールに移動します。有効期間を調整して、しきい値違反の数を減らします。 データソースの問題への対処 使用タイミング:データソースが十分な頻度で実行されていないか、接続の問題があります。 健全性ダッシュボードの結果からデータを提供するソースを確認します。ソースが最後に実行されたのはいつで、CI が検出されない理由を確認します。コネクタを再実行してデータを更新し、未更新の失敗を減らします 包含ルールを使用 使用するタイミング:特定のクラスは未更新の監視を必要としないか、意図的に静的です。未更新評価からクラスを除外する包含ルールを作成します。 コンプライアンス コンプライアンスデータは監査、適切な状況、およびスクリプト化された監査を介して取得されるため、コンプライアンスの最大エラーは完全性および正確性とは異なります。各 CI の失敗の説明には、どの特定の監査が失敗の原因となっているかが示されます。 監査条件を調整 これは根本原因に対処するため、コンプライアンス違反を解決するための主要な方法です。 左側のナビゲーションから、 監査を選択します。失敗の原因となっている特定の監査 (CI 失敗の説明から特定) を見つけます。監査テンプレートに移動します。テンプレートで定義された認定条件を確認します。コンプライアンス要件を維持しながら障害を減らすための条件を調整します。 監査フィルター条件の変更 使用タイミング:評価されている CI が多すぎるため、スコープを縮小する必要があります。 失敗の原因となっている監査テンプレートに移動します。テンプレート内のフィルター条件を開きます。現在一致しているレコードの数を確認します。より具体的な条件を追加して、評価される CI の数を減らします。構成を保存します。 最後の手段:失敗のしきい値を上げる この方法は、前のセクションの解決策アプローチが実現不可能な場合にのみ使用してください。しきい値を増やすと計算コストが高くなり、システムのパフォーマンスに影響を与える可能性があります。 左側のナビゲーションから、 健全性設定に移動します。健全性メトリクスを選択します。適切なメトリクスタイプ (完全性、正確性、またはコンプライアンス) を選択します。サブメトリクスを選択します。[完全性] で、 推奨 または 必須 を選択して、対応するしきい値にアクセスします。失敗のしきい値設定を見つけて、値を増やします。構成を保存します。健全性ジョブを再実行します。 警告:失敗のしきい値を 500,000 を超えて増やすと、全体的なパフォーマンスが低下する可能性があります。最大しきい値はありませんが、高い値は推奨されません。最大エラー数をバイパスするためにしきい値を増やすのではなく、根本的なデータの問題に対処してください。 Xanadu 固有の動作 (Xanadu パッチ 1 で解決済み) Xanadu GA で導入された変更により、失敗のしきい値のデフォルトの上限が 100,000 に設定されました。この上限は、[健全性設定] で構成されたより高いしきい値を上書きします。しきい値が 100,000 を超えて Xanadu にアップグレードした場合、アップグレードの上限は 100,000 に設定されました。 システムプロパティ glide.cmdb.health.max_failure_threshold を使用して、より高い値を設定することでこの制限を回避できました。プロパティが存在しない場合は、システムプロパティ [sys_properties] テーブルに作成される可能性があります。 この動作と関連するプロパティは、Xanadu パッチ 1 で削除されました。パッチ 1 より前に Xanadu を実行している場合は、パッチ 1 以降にアップグレードして、予想されるしきい値の動作を復元します。 一般的なガイドライン しきい値を上げる前に、障害の具体的な原因を調査してください。主要な解決アプローチとして、データソースの問題と構成の問題に対処します。永続的なソリューションに取り組む際は、しきい値引き上げを一時的な手段として使用します。高い障害のしきい値と包含ルールがもたらすパフォーマンスへの影響を考慮してください。正常なしきい値レベルを維持するために、古い CI データ、重複する CI、または非準拠の CI データを定期的にレビューしてクリーンアップします。 関連リンク CMDB ヘルスダッシュボードのスコア計算の変更を理解するCMDB ヘルスダッシュボードは CMDB ワークスペースに移動しましたCMDB 健全性ダッシュボードの表示CMDB ヘルスの構成