ディスカバリーソース、最初の検出日、最新検出日、および手動入力は、あなたの思うような意味ではありません<!-- /*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 識別および調整エンジンが誕生しましたディスカバリーとサービスマッピングでパターンの使用が開始されましたService Graph Connector/ETL/RTE/E-IRE に移行されたインポートプラグインフィールドレベル調整、およびマルチソース CMDBまとめ 導入 この KB 記事では、CMDB IRE が CMDB テーブルの既存のディスカバリーフィールドの一部を再利用したときに生じる混乱を軽減したいと考えています。「理由」から、これはあなたが思うほど単純ではありません。その一部始終を経験してきた人物からの歴史の教訓をご紹介します。 当初はディスカバリーがありました 数十年前に遡ると、CMDB テーブルがあり、ディスカバリー (水平、エージェントレス、IP スキャン) またはディスカバリーの Help-The-Helpdesk スクリプト (HTHD、Windows ブラウザー javascript) 機能のいずれかによって入力されていました。 何が、いつ、何によって更新されたかをカスタマーが追跡できるように、ディスカバリーによって CMDB に次の 3 つのフィールドが追加されました。 ディスカバリーソース [discovery_source] 「Service-Now」（10 年前の社名変更に伴い「ServiceNow」に変更されました）は、当時はディスカバリーしかなかったため ServiceNow が検出したことを意味し、今でも「Discovery」製品を意味します。空とは、おそらく他の方法、手動、または資産管理を介して追加されたことを意味します。 最初の検出日 [first_discovered] ディスカバリーによって CI が最初に挿入されたタイムスタンプ 最新検出日 [last_discovered] ディスカバリーによってレコードが最後に更新された時刻 すべてのディスカバリーセンサーがこれらの 3 つのフィールドのいずれかまたはすべてに入力されるわけではなく、まだ入力されていないものもあります。特定のセンサーが実行していた挿入/更新の一部としてこれらを設定するには、特定のセンサーをコーディングする必要があります。必須というよりは持っていてよかったです。センサーがこれらをメイン CI に入力しておけば幸運で、メモリ、プロセス、ディスクなどの子 CI にこれが入力されるとは思わなかったでしょう。 タイムスタンプは、MID サーバーで以前に実行されていたディスカバリープローブからのデータがあったecc_queue入力に対してセンサーコードが実行されたときでした。そのため、ディスカバリーによってスキャンされた正確な時刻ではありませんが、そのフィールドの一般的な意味として定着するには十分なほど近い値です。 フィールド名にはディスカバリーという単語が含まれていることに注意してください。これは、当時はディスカバリーのためのものであり、ディスカバリーによるものであったためです。MID サーバーもディスカバリーの一部であり、特にディスカバリー用でした。現在、CMDB と MID サーバーは一般的なプラットフォーム機能と見なされていますが、そのため discovery_credentials などの非常に多くのテーブルやフィールドにもディスカバリーという単語が含まれています。 その後、インポートが登場しました お客様は、ディスカバリースキャンではなく、Microsoft System Center から Windows コンピューターのデータを取り込みたいと考えていたため、Microsoft SCCM 用の一連のインポートプラグインの最初のもの、Jamf、およびその他のサードパーティ管理システムが作成されました。これにより、夜間に実行するとディスカバリーが見逃すラップトップまたはコンピューターの電源をその時点でオンにしておく必要があるという問題が解決されました。 ヘルプデスクヘルプ機能も実際には役に立たず、ACC-V からのエージェントベースの検出が登場する前でさえ、すぐに時代遅れになりました。 また、れらのプラグインはさらに、「SCCM」や「ImportSet」のようにディスカバリーソースフィールドを直接更新していました。ただし、実際のスキャンは SCCM が行っていたため、SCCM によるスキャンのタイムスタンプが [最新のディスカバリー] フィールドに入力されていました。これは CI の更新タイムスタンプではなく、その後データを提供するソースとなったサードパーティシステムのスキャンのタイムスタンプでした。 そこで、CMDB 識別および調整エンジンが誕生しました 重複した CI データ、および複数のソースからのデータの競合/フラッピングの痛みと混乱は非常に悪いことであることが認識され、まったく新しい機能が作成されました。その 2 つの主な機能は次のとおりです。 識別:既存の CI レコードと照合して更新しますか、それとも新しい CI レコードを作成しますか?調整:どのデータソース、どのフィールドが他のデータソースよりも優先されるか IRE API は、識別に役立つすべての CI アイテム、子および関連 CI、およびそれらの関連アイテムを含む単一の JSON ペイロードを受け取ります。1 つのペイロードで、一度に多くの CI および CI 関係レコードが挿入または更新される可能性があります。 CMDB 開発者は、ディスカバリーフィールドを IRE 用に再利用することにしました。フィールドの目的は次のとおりに変わりました。 ディスカバリーソース [discovery_source] データの取得元の「データソース」。今では、多くのServiceNowが書かれており、サードパーティのアプリやプラグインがありました[ディスカバリーソース] フィールドは、まず次の 2 つの目的で使用されました。 データの取得元のデータソース (以前と同様)また、CI を別の CI の「重複」としてマークするためにも使用します。私たちはすぐにそれを止め、現在はその目的のための別の「Duplicate Of」参照フィールドがあります。 最初の検出日 [first_discovered] IRE API が CI を含むペイロードを最初に処理したとき 最新検出日 [last_discovered] IRE API が CI を含むペイロードを最後に処理したとき これらのすべての CI には、IRE コードによって自動的に入力される 3 つのフィールドが含まれます。これを行うための機能は不要になりました。IRE APIを使用するだけで完了します。 ディスカバリー日またはスキャン日という概念はもはや当てはまらないことに注意してください。これは、IRE API を実行するコードが CI に対して何らかの処理を行うときです。これはインポートやディスカバリーとは関係がないかもしれませんが、サービス CI が作成されたとき、またはダイナミック CI グループが再計算されて更新されたときである可能性があります。 IRE の調整側では、これらのタイムスタンプを使用して、レコードを最後に更新したデータソースを単純に比較したり、CI が古いと見なしたりします。 これは現在、ユーザー更新可能フィールドではなく IRE コードでのみ使用するための CMDB IRE メタデータです。 ディスカバリーとサービスマッピングでパターンの使用が開始されました Nebula ServiceWatch 製品が買収され、間もなくServiceNow Service Mapping製品へと生まれ変わり、サービス構成アイテム（CI）とその関連CIをトップダウンで検出する製品となりました。そのため、「ServiceWatch」のデータソースは実際には「Service Mapping」を意味します。それは決して修正されませんでした。 CMDB 更新の大きな変更点は、プローブがパターンに移行されたことです。これらは、多くのステップ/プローブをすべて 1 つのパターンで実行し、MID サーバーで実行します。大きな IRE ペイロードのみがインスタンスに渡され、CMDB IRE API を介して渡されます。IRE API は 3 つのフィールド値を追加します。 3 つのフィールドに入力されないディスカバリーセンサーに関する多くの未解決の問題は、同等のパターンの導入によってプローブ/センサーが古くなると、一夜にしてクローズされました。 そのため、ディスカバリーユーザーは、すべての CI についてすべてのディスカバリースキャンで 3 つのフィールドが入力されることを期待していました。これはパターンからのものである場合は当てはまりますが、残りの少数のプローブについては必ずしも当てはまりません。これにより、メイン CI の値は入力されるかもしれませんが、子 CI の値は入力されません。IRE を使用しない更新は、IRE に気付かず、まるでまったく発生しなかったかのように、調整ルールに影響を与えます。 Service Graph Connector/ETL/RTE/E-IRE に移行されたインポートプラグイン 以前のインポート変換フィールドマップが単に discovery_source フィールドに値を入力し、IRE をバイパスして CI とレコードを直接更新していた場合、IRE はこれらを更新として追跡できません。これは、調整ルールを使用できなかったことを意味します。3 つの IRE フィールドが入力されている場合は、IRE を介して行われたに違いないと想定していましたが、これらのフィールドに直接入力するフィールドが多数あり、今でもいくつかあり、IRE (および顧客/サポートエンジニア) を混乱させています。 ここまでの一般的な考え方では、CMDB に入力するものはすべて CMDB IRE API を介して機能する必要があり、インポートプラグインが問題になってきていました。 暫定的な解決策は、IRE を使用して CI を識別するが、sys_idが判明したら通常の更新を続行することでした。CMDBTransformUtil スクリプトインクルードには、多くの制限がありました。 最終的な解決策は、IntegrationHub の Extract Transform Load (ETL)、Robust Transform Maps (RTE)、および Enhance-IRE API を介して行われるデータの実際のコミットに基づく、Service Graph Connector と呼ばれる新しいフレームワークでした。これが導入されると、古い非 IRE プラグインが置き換えられました。 ただし、servicenow がデータを CMDB に追加したときではなく、サードパーティシステムによって収集されたときのタイムスタンプを「最新の検出」に入力するという考えをサポートするために、CMDB IRE API には、最新の検出 [last_discovered] フィールドを属性として IRE ペイロードデータに追加できるプロパティが追加されていました。 ペイロードに CI のlast_discovered属性がある場合は、代わりにそれが使用されます。それ以外の場合は、IRE API の実行時間が使用されます。 これは、これらのシステムプロパティを使用してさらに制御できます glide.identification_engine.skip_updating_source_last_discovered_if_olderglide.identification_engine.ire_message_listener_skip_updating_source_last_discovered_to_now およびこの IRE ペイロードプロパティ skip_updating_source_last_discovered_to_now 「識別および調整のプロパティを参照してください。 フィールドレベル調整、およびマルチソース CMDB しかし、結局のところ、IRE 調整ルールがレコードレベルではなくフィールドレベルで機能することに気付くと、この 3 つのフィールドは事実上廃止されます。それらを基にしたレポーティングは信頼性がありません。 これらの 3 つのレコードレベルフィールドは、フィールドの調整ルールの機能には影響しません。データソース履歴 [cmdb_datasource_last_update] テーブルは、ディスカバリーソースと最新のディスカバリーをフィールドレベルで追跡します。これは、データソースが古い CI を更新できるかどうかを判断するためにも使用されます。 ソース [sys_object_source] テーブルにも last_scan 属性があります。この属性も CMDB IRE に以前から存在しており、IRE 用に再利用されました。これは、識別ルールにフォールバックする前に、インポート中に CI を識別するために使用されます。 また最近では、マルチソース CMDB 機能により追跡テーブル (cmdb_multisource_column_metadata と cmdb_multisource_data が追加され、ペイロードが保存されるようになりました。これにより、調整ルールを遡及的に変更してから、新しいルールに基づいて最近更新されたものを再生できます。 まとめ ディスカバリーソースとは、統合/インポート/ディスカバリーデータソース、またはコードが CMDB IRE の更新を行うアプリケーションを意味します。 たとえば、サービスマッピングまたは認証情報なしディスカバリー機能が実際には使用されていなくても、ディスカバリーソースとして「ServiceWatch」または「CredentiallessDiscovery」と表示されることがあります。これは、これらの機能からの Java コードまたはスクリプトインクルードが CSDM やサービスモデルなどによって再利用され、IRE ペイロードとインスタンス内部の IRE API を介して CI のセットをバックグラウンドで更新するためです。 最初の検出日/最新の検出日は、RTE インポートペイロードの古い値によって上書きされない限り、ペイロードが IRE API を介して渡されたときです。 また、複数のソースが関係している場合、レコードレベルのフィールドは意味がない可能性があります。たとえば、SCCM が RAM 属性を更新したばかりで、ディスカバリーが CPU 属性を同じ日に同じレコードで更新した場合などです。レコードには「ディスカバリーソース = SCCM」と表示されている場合がありますが、そのソースからのフィールドは一部のみです。 最後に、「手動入力」ディスカバリーソースは手動入力を意味するものではありません。いくつかの例外 (サービスの作成/資産から CI への同期) を除き、実際の人間のユーザーによるフォーム/ワークスペースからの更新/挿入は IRE を通過しません。調整ルールでこのソースを使用しても、期待どおりに機能しませんのでご注意ください。 以上を踏まえ、誤った思い込みに基づいて判断を下すことを避けていただければ幸いです。