CMDB ベースラインライフサイクルのベストプラクティスと差分フォーマッターのトラブルシューティングSummary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 注意： CMDB ベースラインは廃止された機能です。お客様はご使用をお控えいただくことをお勧めします。フォーマッターの使用を停止する場合は、KB1262214「CMDB ベースラインデータベースのフットプリントとディスク容量使用量の説明」を参照してください。この記事では、すべてのデータを削除する方法と、フォームレイアウトからフォーマッターを削除する方法についても説明しています。 目次 Planning (計画立案)： ベースラインに含める CI クラスを決定しますこれらのクラスのすべての CI にベースラインを設定するかどうかを決定します新しいベースラインを作成する頻度を決定する古いベースラインを維持する期間を決定する 実装： 関連する CMDB テーブルとフィールドの監査の構成ベースラインを作成するスケジュール済みスクリプトを実装削除ポリシーの実装CI フォームへのフォーマッターの追加 トラブルシューティング フォームがロードされず、タイムアウトするすべての変更がロードされるわけではありませんベースラインは表示されません表示されるはずの変更が表示されません 既知の制限/問題 Planning (計画立案)： ベースラインに含める CI クラスを決定します CMDB ベースラインが必要なテーブル/クラスを決定します。CMDB 拡張テーブルには 700 を超える CI クラスがあり、そのほとんどはベースラインを必要としません。ベースラインの用途は何でしょうか。ハードウェアのメインの親 CI のみが対象ですか？サーバーとコンピューターのみですか？通常、CMDB のいくつかの分岐のみを含む短いリストになります。 ベースラインの作成時に指定するテーブルは、拡張テーブルブランチの最上位テーブルであり、条件でフィルタリングされない限り、そのブランチのすべてのサブクラスも含まれます。より単純な条件を持ついくつかの小さなベースラインは、cmdb_ciの1つの大きなベースラインよりもはるかに簡単に設定できます。 注意:ベースラインに含めるフィールドおよび関連レコードの種類は変更できません。 これらのクラスのすべての CI にベースラインを設定するかどうかを決定します ステータスが「廃止」の CI や、ベースラインの作成が不要なその他の属性値を持つ CI を除外するよう、条件をさらに絞り込む必要があります。 新しいベースラインを作成する頻度を決定する CMDB ベースライン差分フォーマッターは、完全な監査履歴リストではありません。これは、ベースラインが記録されてからの属性、CMDB 関係、および関連レコードへの変更を一覧表示するもので、CI およびその関連 CI に固有の最近の変更をすばやく確認することを目的としています。完全な監査履歴の場合は、代わりに [履歴 - リスト] 機能を使用する必要があります。 CMDB ベースラインには、 ベースラインが最初に作成された時点で存在していた CI のみ のスナップショットが含まれます。後で既存のベースラインに CI を追加したり、ベースラインの作成後に作成された CI のベースラインエントリーを追加したりする方法はありません。1〜2 か月のうちに、かなりの割合の CI でベースラインが使用できなくなります。 定期的に新しいベースラインを作成する必要があります。欠落している CI が多すぎることでベースラインが役に立たなくなる速さに応じて、作成頻度を決定してください。月次が一般的で、週次はあまり一般的ではありません。CMDB の大部分を対象とした日次ベースラインは、作成中のインスタンスおよびデータベースへの負荷によりパフォーマンス上の問題が発生する可能性があります。運用要件に応じた適切な頻度を設定してください。 古いベースラインを維持する期間を決定する ベースラインから欠落しているインプレイ CI が多すぎるため、ベースラインは時間の経過とともに役に立たなくなり、表示する変更の時間枠が長くなるため、あまりにも多くの変更が表示され、フォームが使用できなくなります。 数か月以上前の変更は、通常、CI で行っている作業には関連しません。さらに古い変更を確認したい場合は、[履歴 - リスト] を使用してください。 この機能にはテーブルクリーナーが事前定義されていないため、削除戦略が必要になります (PRB1283806)。データベースクエリのパフォーマンスは、CMDB ベースラインからのデータによって深刻な影響を受ける可能性があります。変更のビジネスルールを介してベースラインの作成をトリガーし、削除戦略を設けなかったあるお客様の場合、最終的に cmdb_baseline_entry テーブルが 6,600 万件のレコードを含む 3.4 TB にまで肥大化し、ログや添付ファイルを含むインスタンスデータベース全体のディスク容量の 90% 以上を占める結果となりました。 古い変更を確認したい場合に備えて、通常は 1 つまたは 2 つの古いベースラインを保持するだけで済みます。 実装 : 関連する CMDB テーブルとフィールドの監査の構成 CMDB ベースラインは、ベースラインを作成する各 CI クラスに対して、事前に監査をオンにしないと機能しません。変更に関するデータは、それ以降のみ利用可能になります。フォームのベースライン差分フォーマッターは、ベースラインが最初に記録されたときに作成されたスナップショットに基づいており、その後すべての変更が監査されます。 フォーマッターでフィールドを除外する方法はないため、フォーマッターから不要なノイズを除去する唯一の方法は、最初にフィールドが監査されないようにすることです。監査する必要のないフィールドの監査をオフにします。[最終検出日] などのフィールドは監査する必要はありません。 計算フィールド (値が他の監査対象フィールドの連結で構成されている表示名など) には、通常、監査は必要ありません。 ノイズをさらに低減するには、定期的にフラッピングする値を持つフィールドや定期的に変化する値を持つフィールドの監査をオフにします。例:ディスカバリーによって毎日更新される空きディスクスペース。また、IP アドレス (PRB1380126) など、ディスカバリーでフラッピング値が発生することでフォーマッターが使いにくくなる既知の問題がある可能性がありますが、アップグレードまたはワークアラウンドを実装することで修正を試みることができます。 フラッピングは、 識別および調整エンジンのデータ優先順位ルールが正しく設定されていないことが原因で発生する可能性もあります たとえば、検出された値と SCCM インポートとは異なる方法で丸められることがわかっている値との間で RAM 値が毎日フラッピングするなど。これは、SCCM データソースがディスカバリーデータソースによって設定された値を上書きできないようにすることで防止できます。（IRE とデータ優先順位ルールを完全に実装するために、統合プラグインを Orlando Store 以降のバージョンにアップグレードする必要がある場合があります）。 関係の変更 もリストされており、通常は表示される変更の大部分を占めています。ベースライン差分フォーマッターに属性の変更のみを表示する場合に、関係の監査を完全にオフにする方法については、次の KB 記事を参照してください。KB0817973 CMDB 関係の監査をオフにする ベースラインを作成するスケジュール済みスクリプトを実装 ベースラインレコードが手動で挿入されると、「SNC ベースラインを作成」ビジネスルールが実行され、テーブル/条件に含まれる各 CI のベースラインエントリが作成されます。スクリプトは単にレコードを挿入することもできます。 ベースラインは手動で作成できますが、作成は、月次、週次、または 30 日ごとに実行されるスケジュール済みスクリプトを使用して行う必要があります。名前、テーブル、条件の 3 つの値が必要です。これらの値を取得する最も簡単な方法は、ベースラインを設定するレコードのみを含む CMDB リストを作成することです。 例えば「名前」を作成しますが、ベースラインの作成日から始めることをお勧めします (例:「2020-06-22 Windows コンピューター」)。サブクラスを Windows 固有のクラスに制限するフィルター条件を含む「テーブル」のリスト (コンピューター [cmdb_ci_computer] など) を開き、[不在/廃止ステータス] を除外します。クエリを右クリックしてコピーすると、「条件」が表示されます。 これらの 3 つの値を持つレコードを挿入する簡単なスクリプトは次のとおりです。 var baselineGr = new GlideRecord('cmdb_baseline'); // set up a GlideRecord object for the CMDB Baseline table baselineGr.initialize(); // initialize a new blank record. baselineGr.name = new GlideDateTime().getDate() + ' Windows Computers'; // uses the current date at the time the script runs baselineGr.table = 'cmdb_ci_computer'; baselineGr.condition = 'sys_class_name=cmdb_ci_computer^ORsys_class_name=cmdb_ci_win_server^ORsys_class_name=cmdb_ci_hyper_v_server^install_statusNOT IN100,7' baselineGr.insert(); // Insert the record, which will trigger the "SNC Create Baseline" business rule 次に、 スケジュール済みスクリプト を設定して、定期的に (例えば 30 日ごと) 実行することができます。 特定のベースラインは、要件に応じてより定期的に作成し、後で削除できます。これが、異なる CMDB 分岐を異なるベースラインに分割するもう 1 つの理由です。 削除ポリシーの実装 最も簡単な方法は、テーブルクリーンアップ [sys_auto_flush] ジョブを使用して、特定の経過時間 (90 日など) より古いすべてのベースラインを削除することです。これは、ベースラインを作成する頻度と、保持している古いベースラインの数と一致します。 データ管理ドキュメントの「テーブルクリーナー」セクションを参照してください。 システムメンテナンス:>テーブルクリーンアップ新規以下のようにフィールドに入力し、送信します テーブル名:CMDB ベースライン [cmdb_baseline]一致フィールド:sys_created_on経過時間 (秒):7776000 (90 日間)Active : trueカスケード削除:true (各 CI のcmdb_baseline_entry子レコードも削除するため)Conditions: (空のままにする) CI フォームへのフォーマッターの追加 CI クラスおよびフォームビューの場合:ヘッダーの右クリック -> 構成 -> フォームレイアウトセクションを選択[CMDB ベースライン差分] を選択した側の必要な位置に移動します保存 フォームにフォーマッターを追加すると、フォームの読み込み時間に顕著な影響が生じます。ベースラインを作成した CI クラスのフォームにのみフォーマッターを追加します。また、ユーザーの特定のロールのみのフォームビューにフォーマッターを追加することも検討できます。 トラブルシューティング フォームがロードされず、タイムアウトする フォームレイアウトから CMDB ベースライン差分フォーマッターを一時的に削除すると、フォームがロードされない原因がフォーマッターであるかどうかを確認できます。同じクラスのすべての CI に問題があるのか、一部の特定の CI のみに問題があるのかを確認します。特定の CI またはクラスは、問題の原因がその CI またはクラスに固有の監査データであることを示しています。フォームからフォーマッターを削除した状態で、[履歴 - リスト] を読み込んでみてください。読み込めるかどうか、更新件数、更新者、対象フィールド、更新日時を確認します。 デフォルトで設定または選択されているベースラインの作成日を確認します。数か月以上前に作成された場合は、古すぎてもはや役に立たないため、削除して置き換えることをお勧めします。 通常、ベースラインの作成時点までさかのぼる日付範囲が大きすぎるか、監査履歴に膨大な数の変更が含まれていることが原因です。このコードは、処理できる監査データが多い場合、データベースのクエリ、データのコンパイル、またはリストのレンダリングの完了に失敗する可能性があります。これを解決するには、次の点を調査・確認する必要があります。 更新の発生源（フィールド）を特定します。インポート、ディスカバリー、ビジネスルールなど、原因はさまざまです。この手法は、履歴 - リストで特定できない場合にコードを特定するのに役立つことがあります。これらの更新は本来発生すべきものか、また停止できるか確認します。変更がない場合でもコードが更新を実行していないか確認します。フラッピングを防止するデータ優先順位ルールが正しく設定されているか確認します。これらのフィールドは監査が必要なフィールドかどうか、また今後監査対象外に設定できるかどうかを確認します。既存の監査データのクリアについては、ServiceNow テクニカルサポートへの依頼が必要になる場合があります。セキュリティ上の理由から、お客様がご自身でこの操作を行うことはできません。 すべての変更がロードされるわけではありません com.cmdb.baseline.max_changes システムプロパティは、CI フォーム (PRB1283753) のベースライン差分セクションに表示される関係と変更の数を制限します。その値 (デフォルトでは 10) を増やしてみることができますが、上限が存在する理由は、過去の多くのパフォーマンスの問題によるものです。設定が高すぎると、フォームをロードするために値を下げなければならない場合があります。変更が多すぎるとフォームが実用的でなくなるため、ベースラインを定期的に置き換え、何がレコードを更新しているか、またその更新を監査する必要があるかどうかを監視することで、表示される変更を減らすことをお勧めします。 ベースラインは表示されません CI に対してベースラインが作成されていない場合、フォーマッターのドロップダウンにベースラインは表示されません。 テーブル/条件上は対象となるべき CI を持つベースラインが存在する場合でも、その CI がベースライン作成後に追加されている可能性があります。 表示されるはずの変更が表示されません これらのテーブルに変更がない場合は表示されません。履歴 - リストは同じテーブルからデータを取得するため、おそらくそこでも変更が表示されないでしょう。 システム監査 [sys_audit]削除されたレコード [sys_audit_delete] の監査リレーションシップ変更の監査 [sys_audit_relation] 関連するフィールドまたはテーブルに対して監査が最近オンになったばかりですか?監査をオンにすると、それ以降のみ記録が開始されます。 変更がベースラインの作成日より前のものである場合、その変更は表示されないはずです。 既知の制限/問題 PRB1283806 CMDB ベースライン:cmdb_baseline_entry テーブルが巨大なサイズに増大し インスタンスとデータベースのパフォーマンスとディスク容量の問題が発生する可能性があるPRB1611377 CI にそれを参照するレコードが大量にある場合、CMDB ベースライン作成ジョブがアプリノードのメモリ不足を引き起こすPRB591082 CMDB ベースラインでは、データを表示できない場合でも、CMDB 以外のテーブルのベースライン設定が可能ですPRB1476641 ベースラインに入力 (計算) するレコードが多数ある場合、CI フォームのロードが遅くなる PRB1611377 を除き、これらの問題が修正される見込みはありません。 Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } }