サービスマッピング および ディスカバリー の CI タイプの作成

  • リリースバージョン: Yokohama
  • 更新日 2025年01月30日
  • 所要時間：9分

    • デフォルトでは サービスマッピング と ディスカバリー でサポートされていないアプリケーションやデバイスの CI タイプ (または CI クラス) を作成します。

    始める前に

    必要なロール： service_mapping_admin、personalize_dictionary、または admin

    このアプリケーションおよびデバイスの CI タイプが存在しないことを確認してください。

    このタスクについて

    組織内のすべてのアプリケーションとホストには、対応する構成アイテム (CI) タイプが必要です。これは、アプリケーションとホストの正しい検出、処理に必要になります。
    注:
    ディスカバリー と CMDB のインターフェイスでは、CI タイプは CI クラスと呼ばれます。

    最も一般的に使用されているアプリケーションをカバーする、事前設定されたさまざまな CI タイプを利用できます。対応する CI タイプがない、知名度の低いアプリケーションや独自のアプリケーションを組織で使用している場合は、CI タイプを新たに作成する必要があります。

    CI タイプは複数の ServiceNow アプリケーションが使用する一般的な概念ですが、サービスマッピング や ディスカバリーには特有の属性がいくつかあります。

    CI タイプ (またはクラス) には、それに属するすべての CI に適用される次のような重要な定義がいくつか含まれています。
    • CI 属性は、フィールドとして CMDB テーブルに追加されます。
    • 識別子は、サービスマッピング や ディスカバリー での新規の CI と既存の CI の区別に役立ちます。たとえば、CMDB で定義された Apache Web サーバー CI タイプがあり、 サービスマッピング と ディスカバリー の両方が Apache Web サーバー CI を検出した場合、識別子を使用してその CI を処理します。その後、この CI は、新しい Apache Web サーバー CI ではなく、システムに既に存在する Apache Web サーバー CI の更新バージョンとして認識されます。
    • 調整ルールは、さまざまなアプリケーションから受け取った CI 属性を ServiceNow プラットフォームで正しく統合するのに役立ちます。こうしたルールは、複数のアプリケーションがディスカバリープロセスに関与している組織に必要です。調整ルールでは、さまざまなディスカバリーソースが検出した、同じ CI の属性を結合する方法を定義しています。たとえば、サービスマッピング が Apache Web サーバー CI のバージョンとホームディレクトリ属性を検出し、ディスカバリー が同じ Apache Web サーバー CI のバージョンとパッチレベル属性を検出したとします。Now Platform で調整ルールが適用されるため、サービスマッピング は、ディスカバリー が検出した属性を上書きすることはありません。
    • 関連アイテム (CI と非 CI の両方) は参照として機能し、CI に関する追加情報を提供します。たとえば、ハードウェアサーバーの関連アイテムとして、シリアル番号、ポート、およびネットワーク APR テーブルを定義できます。システムは識別にこれらのアイテムを使用しません。CI タイプの関連アイテムを構成した後、関連アイテムとともにこのタイプの CI に対して水平ディスカバリーを使用できます。詳細については、「メイン CI と関連アイテムの検出」を参照してください。
      注:
      非 CI は構成アイテム (CI) [cmdb_ci] テーブルを拡張しないアイテムです。非 CI の例として、ポート、シリアル番号、または Network ARP テーブルが挙げられます。
    • CMDB は CI クラスを階層構造で保存します。CI クラスには子 CI クラスを持つものがあり、子 CI クラスには、ユーザーがそのクラスに特別に設定した属性の他に、親の属性が自動的に引き継がれます。CI クラス階層は、CI の動作、関係、表示の構成に幅広く使用されます。この例では、Apache Web サーバー CI は Web サーバー CI の子であり、名前、バージョン、モデル ID など、親から多くの属性を受け継いでいます。デフォルトでは、子 CI クラスは親 CI クラスから識別子を受け継ぎます。

    こうした CI タイプ定義に加えて、水平ディスカバリープロセスは CI 分類を使用して、CI がどの CI タイプに属しているかを定義します。SNMP を使用するデバイスの CI タイプを作成する場合や、アプリケーション CI タイプのプロセス CI 分類を作成する場合は、デバイス CI 分類を作成してください。

    手順

    1. 次のように移動する。 All (すべて) > 構成 > CI クラスマネージャー.
    2. 既存の CI タイプを新しい CI タイプの親として使用するには、[階層] をクリックして、CI クラスリストを表示します。
    3. 必要な CI タイプのコンテキストメニューをクリックして、[子クラスを追加] を選択します。
    4. CI タイプ属性を格納するCreate a tableを実行します。
      表 : 1. 新しいテーブルフォーム
      フィールド 説明
      ラベル CI タイプ名。例：Apache Web サーバー。
      名前

      テーブル名。例：cmdb_ci_apache_web_server。

      他の CMDB クラス (u_cmdb_ci_laptop など) に似た名前を使用します。
      拡張テーブル 親 CI タイプのテーブル名。

      すべての CI タイプは、構成アイテム [cmdb_ci] テーブルまたはその子テーブルの拡張です。たとえば、新しいクラスがラップトップ (コンピュータのサブクラス) の場合は、[cmdb_ci_computer] テーブルを選択します。新しいクラスがトップレベルクラスの場合は、[cmdb_ci] テーブルを選択します。

      最も一般的に使用される親 CI タイプは、次のとおりです。
      • cmdb_ci：基本
      • cmdb_ci_database：データベース用
      • cmdb_ci_app_server：アプリケーションサーバー用
      • cmdb_ci_infra_service：インフラストラクチャサービス用
      • cmdb_ci_endpoint_inclusion：包含タイプのエントリーポイント用
      • cmdb_ci_appl：アプリケーション用
      • cmdb_ci_web_server：Web サーバー用
      • cmdb_ci_lb：ロードバランサー用
      • cmdb_ci_endpoint：エントリーポイント用
    5. 検出された CI がインスタンス内の既存の CI のアップグレードか、新しい CI かを判断する方法を設定します。
      詳細な手順については、「CI 識別ルールの作成または編集」を参照してください。
      警告:
      CI タイプの CI 識別ルールが存在しない場合、サービスマッピング は、このタイプに属する CI を検出しますが、ディスカバリープロセスの結果を解釈することはできません。この場合、Now Platform では、こうした CI のディスカバリー結果は拒否され、情報は更新されません。
      1. 識別子ページで、パラメーターを次のように設定します。
        表 : 2. 識別子フォーム
        フィールド 説明
        名前 わかりやすい名前を使用します。
        適用先 CI タイプを入力します。
        アクティブ チェックボックスをオンにします。
        依存なし チェックボックスをオフにします。
      2. 識別子エントリパラメーターを次のように設定します。
        表 : 3. 識別子エントリフォーム
        フィールド 説明
        基準属性 CI を識別するために使用する属性を選択します。例：クラス、インストールディレクトリ、シリアル番号。
        null 属性を許可 チェックボックスをオンにします。
        優先度 複数の識別子エントリがある場合は、優先度を追加して、サービスマッピング でこうしたエントリに適用される順番を決定します。検出された CI と整合する識別基準がない場合、この CI は新規です。
    6. オプション: 他の CI または非 CI への参照を CI タイプの関連アイテムとして設定します。
      表 : 4. 関連エントリフォーム
      フィールド 説明
      アクティブ 関連エントリが有効であることを指定するチェック ボックス。
      関連テーブル 一致する CI を参照する関連テーブル。
      参照フィールド 参照された CI を格納する必要がある関連テーブルの参照済みフィールド。このフィールドは、cmdb_ci テーブル、または cmdb_ci テーブルの子孫を常に参照します。
      優先度 指定された関連テーブルの関連エントリの優先度。特定の関連テーブルの関連アイテムを照合する際、優先度番号の低いルールには高い優先度が指定されます。同一の優先度を持つ指定された関連テーブルの関連エントリはランダムに適用されます。

      優先度の数値は間を空けて設定できます。これにより、既存の優先順位を変更せずに、未使用の優先度の数値を新しいエントリにアサインすることができます。
      基準属性 関連アイテムを一意に識別する属性のセット。属性は、現在のクラスまたは親クラスに属することができます。
      注:
      基準属性として参照フィールドを追加することができます。ただし、そのようなフィールドが常に有効であるとは限りません。
      • 参照フィールドには別のテーブル内のレコードを指す sys_id が格納されているため、現在のテーブルに対して (一意性の点で) 弱い条件の属性と見なされます。
      • システムは、参照フィールド内の無効な値を検出し、「不明」に置き換えます。たとえば、無効な Model ID 値は「不明」の値に置き換えられます。また、複数の CI が、「不明」に設定された同じ参照フィールドを持つ場合、これらの CI は重複 CI になります。

      識別ルールの属性を表示、追加、または削除するには、ロックアイコンを選択します。
      null 属性を許可 関連テーブルの少なくとも 1 つの基準属性が null でない場合は、null である基準属性がある場合でも、識別子エントリとの一致を試みることを許可します。
      フィルター条件 一致する関連アイテムを検索するレコードのセットを絞り込むフィルターを作成するための条件を追加します。
    7. オプション: さまざまなデータソースから受け取った CI 属性を正しく統合するようにインスタンスを設定します。
      「CI 調整ルールの作成または編集」を参照してください。

      サービスマッピング に関連する次のパラメーターを正しく設定します。

      表 : 5. 調整定義フォーム
      フィールド 説明
      データソース [ServiceWatch] を選択します。
      適用先 関連する CI タイプを選択します。
      オプションの条件 必要に応じて条件を設定します。
      注:
      CI 調整ルールを作成しない場合は、パターンで検出されたデータを使用して CI 属性が更新されます。
    8. CI タイプの CI 分類を設定します。
      注:
      これらの分類はベースシステムに含まれているため、ホストの CI 分類を作成する必要はありません。
    9. 包含を表す CI タイプの場合は、新しい CI タイプの階層を定義します。

      この設定を実行しているときは、[リレーションシップの方向を逆にする] チェックボックスをオフにします。

      「依存関係性ルールの作成」を参照してください。
    10. 必要に応じて、マップ内で CI を表すアイコンをカスタマイズします。
      「マップアイコンの作成または変更」を参照してください。