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: block; max-width: ; width: auto; height: auto; } } 注意： CMDB ベースラインは廃止された機能であり、お客様は使用しないことをお勧めします。 フォーマッターの使用を停止する場合は、「CMDB ベースライン KB1262214データベースフットプリントとディスク容量の使用量の説明」を参照してください。この説明では すべてを削除し、フォームレイアウトからフォーマッターを削除する方法についても説明しています。 目次 Planning (計画立案)： ベースラインに含める CI クラスを決定しますこれらのクラスのすべての CI にベースラインを設定するかどうかを決定します新しいベースラインを作成する頻度を決定する古いベースラインを維持する期間を決定する 実装： 関連する CMDB テーブルとフィールドの監査の構成ベースラインを作成するスケジュール済みスクリプトを実装削除ポリシーの実装CI フォームへのフォーマッターの追加 トラブルシューティング フォームがロードされず、タイムアウトするすべての変更がロードされるわけではありませんベースラインは表示されません表示されるはずの変更が表示されません 既知の制限/問題 Planning (計画立案)： ベースラインに含める CI クラスを決定します CMDB ベースラインが必要なテーブル/クラスを決定します。CMDB 拡張テーブルには 700 を超える CI クラスがあり、そのほとんどはベースラインを必要としません。ベースラインを使用することに興味を持っているのは何ですか?ハードウェアのメインの親 CI のみ?サーバーとコンピューターのみ?通常、CMDB のいくつかの分岐のみを含む短いリストになります。 その後、通常は、関心のある CMDB の各ブランチに対してベースラインが作成されます。ベースラインの作成時に指定されたテーブルは、拡張テーブルブランチの最上位テーブルであり、条件でフィルタリングされない限り、そのブランチのすべてのサブクラスも含まれます。より単純な条件を持ついくつかの小さなベースラインは、cmdb_ciの1つの大きなベースラインよりもはるかに簡単に設定できます。 注意:ベースラインに含まれるフィールドと関連レコードは設定できません。どの CI が含まれるかのみ。 これらのクラスのすべての CI にベースラインを設定するかどうかを決定します ステータスが廃止の CI や、ベースラインが無意味であることを意味するその他の属性値を除外するための条件をさらに制限する必要があります。 新しいベースラインを作成する頻度を決定する CMDB ベースライン差分フォーマッターは、完全な監査履歴リストではありません。これは、CI とその関連 CI に固有の最近の変更をすばやく確認するために、ベースラインが記録されてからの属性、CMDB 関係、および関連レコードに対する変更のリストです。完全な監査履歴の場合は、代わりに [履歴 - リスト] 機能を使用する必要があります。 CMDB ベースラインには、 ベースラインが最初に作成された時点で存在していた CI のみ のスナップショットが含まれます。後で既存のベースラインに CI を追加したり、ベースラインの作成後に作成された CI のベースラインエントリーを追加したりする方法はありません。1 か月または 2 か月以内に、かなりの割合の CI でベースラインが使用できなくなります。 定期的に新しいベースラインを作成する必要があります。欠落している CI が多すぎるためにベースラインがどれだけ早く役に立たなくなるかによって、これをどの程度の頻度で作成するかが決まります。毎月は普通で、毎週はそうではありません。CMDB の大部分の日次ベースラインは、ベースラインの作成中にインスタンスとデータベースの負荷が原因でパフォーマンスの問題が発生する可能性があります。あなた自身のニーズに合った賢明な期間を考え出してください。 古いベースラインを維持する期間を決定する ベースラインから欠落しているインプレイ CI が多すぎるため、ベースラインは時間の経過とともに役に立たなくなり、表示する変更の時間枠が長くなるため、あまりにも多くの変更が表示され、フォームが使用できなくなります。 数か月以上前の変更は、通常、CI で行っている作業には関連しないため、常に [履歴 - リスト] を参照してさらにさかのぼるオプションがあります。 この機能にはテーブルクリーナーが事前定義されていないため、削除戦略が必要になります (PRB1283806)。データベースクエリのパフォーマンスは、CMDB ベースラインからのデータによって深刻な影響を受ける可能性があります。変更に関するビジネスルールを介してベースラインの作成をトリガーしたあるお客様は、削除戦略なしで、最終的に 6,600 万件のレコードを含む 3.4 TB の cmdb_baseline_entry テーブルになり、ログと添付ファイルを含むインスタンスデータベース全体のディスク容量の 90% 以上を占めました。 古い変更を確認したい場合に備えて、通常は 1 つまたは 2 つの古いベースラインを保持するだけで済みます。 実装 : 関連する CMDB テーブルとフィールドの監査の構成 CMDB ベースラインは、ベースラインを作成する各 CI クラスに対して、最初に から監査をオンにしないと機能しません 。変更に関するデータは、それ以降のみ利用可能になります。フォームのベースライン差分フォーマッターは、ベースラインが最初に記録されたときに作成されたスナップショットに基づいており、その後すべての変更が監査されます。 フォーマッターでフィールドを除外する方法はないため、フォーマッターから不要なノイズを除去する唯一の方法は、最初にフィールドが監査されないようにすることです。監査不要なフィールドまたは不要なフィールドの監査をオフにします。[最終検出日] などのフィールドは監査する必要はありません。 計算フィールド (値が他の監査対象フィールドの連結で構成されている表示名など) には、通常、監査は必要ありません。 ノイズをさらに低減するには、定期的にフラッピングする値を持つフィールドや定期的に変化する値を持つフィールドの監査をオフにします。例:ディスカバリーによって毎日更新される空きディスクスペース。また、IP アドレス (PRB1380126) など、ディスカバリーでフラッピング値が発生することでフォーマッターが使いにくくなる既知の問題がある可能性がありますが、アップグレードまたはワークアラウンドを実装することで修正を試みることができます。 フラッピングは、 、識別および調整エンジンのデータ優先順位ルールが正しく設定されていないことが原因で発生する可能性もあります たとえば、検出された値と SCCM インポートとは異なる方法で丸められることがわかっている値との間で RAM 値が毎日フラッピングするなど。これは、SCCM データソースがディスカバリーデータソースによって設定された値を上書きできないようにすることで防止できます。(統合プラグインを Orlando Store 以降のバージョンにアップグレードすると、IRE とデータ優先順位ルールが完全に実装される場合があります)。 関係の変更 もリストされており、通常は表示される変更の大部分を占めています。ベースライン差分フォーマッターに属性の変更のみを表示する場合に、関係の監査を完全にオフにする方法については、次の 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 テーブルが巨大なサイズに増大し インスタンスとデータベースのパフォーマンスとディスク容量の問題が発生する可能性があるCI にそれを参照するレコードが大量にある場合 アプリノードのメモリ不足 を引き起こす CMDB ベースライン作成ジョブPRB1611377PRB591082 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: block; max-width: ; width: auto; height: auto; } }