サポート (英語のみ)

ルールベースのCollector割り当て（クラシック）

概要

ルールベースのコレクター割り当てには、すべてのコレクターのために Nexthink インスタンスの完全修飾ドメイン名 (FQDN) を使う単一のインストーラーが必要です。 最初の接続時には、各コレクターが割り当てられた Nexthink V6 エンジンのアドレスを受け取ります。 その後は通常通りエンジンに情報を送信し始めることができます。 Nexthink へのその後の接続では、各コレクターが同じエンジンに割り当てられているかどうかを確認し、必要に応じてエンジンを切り替えます。

Nexthink はルールのセットを使って割り当てプロセスを管理します。 これらのルールを調整することで、コレクターを動的に異なるエンジンに再割り当てできます。 ルールはコレクターをエンジンだけでなく、エンティティにも割り当てることを定義します。 これらはデバイスを階層的に整理するためのベースを形成します。 同じルールで指定されたエンティティの割り当ては、Windows と Mac のコレクターインストールのどのバージョンでも有効です。

ルールベースのコレクター割り当てのサポート

ルールベースの割り当ては、次のデバイスフィールドに条件を持つルールをサポートします。

  • 最後の IP アドレス

  • 最後のローカル IP アドレス

  • 名前

  • コレクターによって報告された識別名

  • AD サイト

  • コレクタータグ番号

  • コレクター文字列タグ

デバイスの最後の IP アドレスのみに基づいて割り当てられているエンジン間を切り替えるローミングデバイスがないことを確認してください。 V6.24からは、デバイスの最後のローカル IP アドレスを使用することで、この問題を解決します。

デバイスのIPアドレスに依存する条件の場合、ローカルIPアドレスのベータ機能がV6.24から廃止され、最後のローカルIPアドレスフィールドに置き換えられたため、ルールベースのコレクター割り当ては互換性がありません。

割り当てルールの記述

CSV ファイルの表形式でコレクター割り当てのルールを定義します。

entity_rule
エンジン
エンティティ
Field1
Pattern1
Field2
Pattern2

oui

Engine-1

Lyon

ad_site

Lyon-?

dn

*OU=PROD*

non

Engine-2

Paris

local_ip

192.168.212.0/24

名前

DESKTOP-FR*

oui

Engine-3

Los Angeles

collector_tag

212

non

Engine-4

New York

名前

DESKTOP-US*

ip

10.100.0.0/16

entity_rule (大文字小文字を区別) no の設定時は、そのルールがデバイスをエンジンとエンティティの両方に割り当てます。 yes の設定時は、そのルールがエンジンでフィルタリングされたエンティティのみにデバイスを割り当てます。

エンジン (大文字小文字を区別しない ターゲットエンジンのホスト名。

エンティティ (大文字小文字を区別) ターゲットエンティティの名前。

Field1 割り当てに使用する最初のデバイスフィールドの名前。

Pattern1 指定された最初のフィールドが、デバイスに指定されたエンジンとエンティティを割り当てるために一致する必要があるパターン。

Field2 割り当てに基づく2番目のデバイスフィールドの名前。

Pattern2 指定された2番目のフィールドが、デバイスに指定されたエンジンとエンティティを割り当てるために一致する必要があるパターン。

Field1 および Field2 の列は次の値をサポートします。

ip

デバイスの最後のIPアドレス。 フィールドのパターンとして、以下のいずれかを指定します。

- 点十進法での単一の IP アドレス (例: 192.168.10.1)

- CIDR 表記におけるサブネット (例: 192.168.10.0/24)

local_ip

デバイスの最後のローカル IP アドレスはローカルネットワーク上のIPアドレスに対応しています。 ip フィールドと同様の方法でパターンを指定します。

name (大文字小文字を区別しない)

デバイスのホスト名。

collector_tag

コレクターのインストール時に割り当てられたタグ番号。 正確な番号のみを一致させます。

collector_string_tag

インストール時にコレクターに割り当てられたラベル。この値はパターンマッチングをサポートします。

dn

コレクターによって報告されたデバイスの識別名。 デバイスはActive Directoryドメインの一部である必要があります。

コレクターによって報告された識別名の形式は、最も特定的な属性から最も一般的な属性まで、コンマで接続された属性=値の標準シーケンスです。 例えば CN=ex01,OU=Computers,DC=example,DC=org

一方、Active Directory から取得した際には、デバイス (やユーザー) の識別名フィールドは、順序が逆で元素がスラッシュで繋がれた類似のシーケンスを使用します。 例えば /DC=org/DC=example/OU=Computers/CN=ex01

ad_site

デバイスが所属する Active Directory サイト。 1つ以上のTCP/IPサブネットを表すサイト。

name、collector_string_tag、dn、そして ad_site のフィールドは文字のパターンマッチをサポートします。 関連する文字列パターンを定義するために、次のワイルドカードを使用してください。

- ? 文字は単一の文字を代替します。

- * 文字は0またはそれ以上の文字を代替します。

\r\nルール用のCSVファイルを書くために、UTF-8 文字エンコーディングを使用し、サイズを20MBに制限してください。 (例えばWindowsのNotepad) ファイルの先頭に BOM 文字を作成するテキストエディタでルールを記述するのは避けてください。 このような追加文字は、設定ウィザードで解析された際にヘッダーエラーを引き起こします。

ヘッダーの後に、各ルールを新しい行に書き込みます。 各項目を二重引用符で括ることで、システムが特殊文字をエスケープし、セミコロンをデリミタとして使用するようにします。 例えば、様々なタイムゾーンに支社を持つ小規模企業のためのCSVファイル:

"entity_rule";"Engine";"Entity";"Field1";"Pattern1";"Field2";"Pattern2"
"no";"Engine-2";"BOSTON";"local_ip";"10.102.0.0/16";"name";"DESKTOP-*"
"no";"Engine-3";"DUBAI";"local_ip";"10.103.0.0/16";"name";"DESKTOP-*"
"no";"Engine-4";"BRISBANE";"local_ip";"10.104.0.0/16";"name";"DESKTOP-*"
"no";"Engine-5";"ZURICH";"local_ip";"10.107.0.0/16";"name";"DESKTOP-*"
"no";"Engine-1";"REMOTE";"name";"LAPTOP-*"

ルールが満たされるためには、Field1 と Field2 の条件がどちらも満たされる必要があるため、両方のパターンが一致する必要があります。 ルールの優先順位は上から下へ確立されます。 エンティティのみのルールにより、特にスティッキー、ローミング、または VPN デバイス用のキャッチオールなデフォルトケースが提供され、空の - エンティティへの割り当てが発生するのを防ぎます。

CSV ファイルをアップロードするには:

  1. Nexthink の Webインターフェースに、中央管理者のプロファイルを持つアカウントでログインします。

  2. メインナビゲーションバーの 管理 メニューから システム構成の下でコレクターを選択します。

  3. 新しいルールセットを追加 ボタンをクリックします。

    1. ダイアログボックスのフィールドに入力します。

      • ルールセット名 にはルールのユニークな名前を入力します。

      • 説明 にはルールの目的を説明します。

      • CSVファイル の下で、新しいファイルをアップロード をクリックし、事前に作成したCSVファイルを選択します。

コレクター割り当てのシミュレーション

ルールセットの変更をスムーズにするために、Nexthinkはまずルールをシミュレーションすることを強く推奨します。 コレクター割り当てルールのシミュレーションは、現在割り当てられているエンジンやエンティティを実際に変更することなく、ルールの適用効果を確認させます。

シミュレーションモードを有効にするには:

  1. 中央管理者のプロファイルを持つアカウントで Nexthink の Webインターフェースにログインします。

  2. メインナビゲーションバーの管理メニューからシステム構成の下でコレクターを選択します。

  3. プロセスをトリガーするために シミュレート をクリックします。

      <figure><img src="../../../../.gitbook/assets/image-20220303-085423.png" alt=""><figcaption></figcaption></figure>

  4. 結果はブラウザが自動的にダウンロードするCSVファイルに保存されます。 インスタンスにリンクされたすべてのデバイスと、いくつかのプロパティがカラムに整列しているリストです。 最後のカラムにはシミュレートされた値が含まれています。

デバイス名
コレクタバージョン
IPアドレス
ローカル IP アドレス
AD サイト
識別名
コレクタ タグ
コレクタ 文字列タグ
最終確認日 (UTC)
最終確認日
割り当てられたエンジン
割り当てられたエンティティ
ローミング開始日 (UTC)
現在の『使用割り当て』フラグ
現在のフラグを持つシミュレートされたエンジン
現在のフラグを持つシミュレートされたエンティティ
フラグ = YES の場合のシミュレートされたステータス
フラグ = YES の場合のシミュレートされたエンジン
フラグ = YES の場合のシミュレートされたエンティティ

device-36e68c7a

6.30.4.9

194.3.224.3

10.19.3.61

c40034

1000

BOSTON

22.11.21 19:03

10.244.14.5:8443

-

BOSTON

-

不明 (NO として考慮)

engine-1

BOSTON

割り当てられた

engine-1

BOSTON

device-938b6df4

22.2.1.22

194.3.224.3

10.18.6.2

c40034

1000

MADRID

24.02.22 12:07

10.244.14.5:8443

-

MADRID

-

不明（いいえと見なします）

エンジン-1

マドリッド

割り当てられた

エンジン-1

マドリッド

デバイス-8cfae42b

21.7.1.19

194.3.224.3

10.5.3.23

c40034

1000

ボストン

11.10.21 23:05

10.244.14.133:8443

-

ボストン

-

不明（いいえと見なします）

エンジン-1

ボストン

割り当てられた

エンジン-1

ボストン

デバイス-1df8e1ce

21.7.1.19

194.3.224.3

10.29.2.4

1000

マドリッド

13.10.21 13:20

10.244.14.133:8443

-

マドリッド

-

不明（いいえと見なします）

エンジン-1

マドリッド

割り当てられた

エンジン-1

マドリッド

デバイス-784c6e93

21.8.1.24

194.3.224.3

10.21.22.15

1000

ロンドン

14.10.21 16:16

10.244.14.133:8443

-

ロンドン

-

不明（いいえと見なします）

エンジン-1

ロンドン

割り当てられた

エンジン-1

ロンドン

デバイス-51d1eb73

6.30.4.11

194.3.224.3

10.9.4.3

0

不明

01.11.21 11:32

10.244.14.133:8443

-

デフォルト

-

不明（いいえと見なします）

エンジン-1

デフォルト

割り当てられた

エンジン-1

デフォルト

デバイス-a639e2f6

21.8.1.25

194.3.224.3

10.26.17.12

9c6a68

0

-

23.11.21 15:00

10.244.14.5:8443

-

デフォルト

-

不明（いいえと見なします）

エンジン-1

デフォルト

割り当てられた

エンジン-1

デフォルト

デバイス-9acf29ca

6.30.4.9

194.3.224.3

10.5.19.6

c40034

1000

不明

24.11.21 18:53

10.244.14.5:8443

-

デフォルト

-

不明（いいえと見なします）

エンジン-1

デフォルト

割り当てられた

エンジン-1

デフォルト

シミュレーション後にダウンロードされたCSVの一部の例。

コレクターの発見

インスタンスに接続するコレクターのリストを確認してください。

  1. 中央管理者プロファイルのアカウントでNexthink Webインターフェースにログインします。

  2. メインのナビゲーションバーの管理メニューから、システム構成の下にあるコレクターを選択します。

  3. インスタンスに関連付けられたデバイスのリストをデバイスの下で確認します。

  4. 全リストを取得するにはすべてをエクスポートをクリックします。

テーブルの列には、コレクターの割り当て状況に関する現在の情報が提供されています。 これらの列には次のプロパティが含まれます:

  1. デバイス名

  2. コレクタバージョン

  3. IP アドレス (最後のもの)

  4. ADサイト

  5. 識別名

  6. コレクタータグ番号

さらに、以下の追加列を見つけることができます:

最終確認日 (UTC)

コレクターから受け取った最後の割り当て要求の時間。

最終確認日

コレクターが最後に確認されたアプライアンスのIPアドレスとポート。

割り当て済みエンジン

コレクターがデータを送信するように構成されているエンジン。

割り当て済みエンティティ

コレクターが現在所属するエンティティ。

ローミング開始日 (UTC)

デバイスがローミングを開始した時間。

エラーメッセージ

コレクターの割り当てにおける最後のエラー。

再割り当て

Nexthinkインスタンスがコレクターにエンジンを正常に割り当てたら、コレクターは割り当てられたエンジンから新しい割り当て情報を受け取ります。 コレクターのTCP接続が中断されるたびに、新しい割り当て情報を尋ねます。

さらに、割り当てルールが変更されるたびに、コレクターは他のエンジンに動的に再割り当てされることがあります。 再割り当てメッセージのコレクターへの配布は最大で60分かかる場合があります。

一方、望ましくないエンジンの切り替え数を制限するために、プロパティ (たとえば IPアドレス) を変更するデバイスの再割り当ては、新しいルールの有効化後、デフォルトで10日間遅延されます。 これは、ローミングしているユーザーのラップトップなど、サブネットを頻繁に変更するデバイスに特に重要です。

割り当て失敗のシナリオ

コレクターが新しい割り当てを受け取ると、コレクターは最初のFQDNを宛先として割り当てられたエンジンにTCP接続を確立しようとします。 コレクターが3回の再試行後にも到達できない場合、それは失敗を報告するために以前に割り当てられたエンジンに依存します。 その後、新しい割り当てを待ちます。 待機中は、コレクターはトラフィックを送信しません。

割り当てが失敗しているかどうかを確認するには、次の手順を実行します。

  1. 中央管理者プロファイルのアカウントでNexthink Webインターフェースにログインします。

  2. メインのナビゲーションバーの管理メニューから、システム構成の下にあるコレクターを選択します。

  3. インスタンスに関連付けられたデバイスのリストをデバイスの下で確認します。

  4. エラーメッセージ列で、次のような値を持つリストエントリを探します:\n最後の割り当てが失敗しました: エンジン [IPアドレス] tcpポート [番号]: ...

  5. デフォルトでは、100デバイスのみが表示されます。 全リストを取得するにはすべてをエクスポートをクリックします。

Last updated

Was this helpful?