ルールベースのCollector割り当て(クラシック)
概要
ルールベースのコレクター割り当てには、すべてのコレクターに対してNexthinkインスタンスの完全修飾ドメイン名(FQDN)を使用する単一のインストーラーが必要です。 最初の接続時に、各コレクターは割り当てられたNexthink V6 エンジンのアドレスを受け取ります。 その後、コレクターは通常のようにエンジンに情報を送信し始めることができます。 Nexthinkへの後続の接続で、各コレクターは同じエンジンに割り当てられているか、別のエンジンに割り当てられているかを確認し、エンジンを切り替えます。
Nexthinkは、一連のルールを使用して割り当てプロセスを管理します。 ルールを調整することで、コレクターを動的に別のエンジンに再割り当てすることができます。 ルールは、エンジンへのコレクターの割り当てだけでなく、エンティティへの割り当ても定義します。 これらのルールによって、デバイスを階層化して整理するための基盤が形成されます。 同じルールで指定されたエンティティの割り当ては、WindowsとMacのコレクターインストールの任意のバージョンに対して有効です。
ルールベースの Collector 割り当てに対するサポート
ルールベースの割り当てでは、次のデバイスフィールドに条件を持つルールをサポートしています:
最後の IP アドレス
最後のローカル IP アドレス
[名前]
Collector によって報告された識別名
AD サイト
Collector マーク番号
Collector 文字列タグ
デバイスの IP アドレスに基づいて完全に割り当てられたエンジンを切り替えるローミングデバイスをないようにしてください。 V6.24以降は、デバイスの最後のローカル IP アドレスの使用でこの問題が解決されます。
条件がデバイスの IP アドレスに依存する場合、ルールベースの Collector 割り当てはローカル IP アドレスのベータ機能と互換性がありません。ベータ機能は V6.24 から廃止され、最後のローカル IP アドレスフィールドに取って代わられます。
割り当てルールの記述
CSV ファイルの表形式で Collector の割り当てルールを定義します。
はい
エンジン-1
リヨン
ad_site
リヨン-?
dn
*OU=PROD*
いいえ
エンジン-2
パリ
local_ip
192.168.212.0/24
[名前]
デスクトップ-FR*
はい
エンジン-3
ロサンゼルス
コレクタータグ
212
いいえ
エンジン-4
ニューヨーク
[名前]
デスクトップ-US*
ip
10.100.0.0/16
エンティティ_ルール (大文字小文字を区別) 「いいえ」に設定されている場合、ルールはデバイスをエンジンとエンティティの両方に割り当てます。 「はい」に設定されている場合、ルールはエンジンでフィルタしたエンティティにデバイスを割り当てます。
エンジン (大文字小文字を区別しない) ターゲットエンジンのホスト名。
エンティティ (大文字小文字を区別) ターゲットエンティティの名前。
フィールド1 割り当てに使用される最初のデバイスフィールドの名前。
パターン1 指定された最初のフィールドが、デバイスに割り当てるためのエンジンおよびエンティティに一致しなければならないパターン。
フィールド2 割り当ての基礎となる2番目のデバイスフィールドの名前。
パターン2 指定された2番目のフィールドが、デバイスに割り当てるためのエンジンおよびエンティティに一致しなければならないパターン。
列 フィールド1 および フィールド2 は、次の値をサポートします:
ip
デバイスの最後のIPアドレス。 フィールドのパターンとして、次のいずれかを指定します:
- 例: 192.168.10.1
という単一のIPアドレスを10進記法で指定
- 例: 192.168.10.0/24
というサブネットをCIDR表記で指定
ローカル_ip
デバイスの最後のローカルIPアドレスは、ローカルネットワーク上のIPアドレスに対応します。 ip フィールドと同様の方法でパターンを指定してください。
name (大文字小文字を区別しない)
デバイスのホスト名。
コレクター_タグ
コレクターのインストール時に割り当てられるタグ番号。 のみ正確な番号が一致します。
コレクター_ストリング_タグ
コレクターのインストール時に割り当てられるラベル。この値はパターンマッチングをサポートします。
dn
デバイスの識別名とCollectorが報告したもの。 デバイスはActive Directoryドメインの一部である必要があります。
Collectorにより報告される識別名の形式は、 属性=値
要素をカンマで連結し、最も特定的な属性から最も一般的な属性までの標準的な順序です。 例 CN=ex01,OU=Computers,DC=example,DC=org
対照的に、Active Directory から取得した場合デバイス (またはユーザー) の識別名フィールドは、要素をスラッシュでつなげ逆順の類似のシーケンスを使用します。 例 /DC=org/DC=example/OU=Computers/CN=ex01
ad_サイト
デバイスがあるADサイト。 サイトは1つ以上のTCP / IPサブネットを表します。
name、コレクター_ストリング_タグ、dnおよびad_サイトフィールドは、文字パターンの一致をサポートします。 関連付けられた文字列パターンを定義するには、次のワイルドカードを使用します:
- ?
文字は1つの文字を置き換えます。
- *
文字は、ゼロ以上の文字を置き換えます。
ヘッダーの後、新しい行に各ルールを書いてください。 システムが特殊文字をエスケープできるようにするために、各項目を二重引用符で囲み、セミコロンをデリミタとして使用することがオプションです。 例えば、さまざまなタイムゾーンにその支社がある小さな会社のためのCSVファイル:
ルールが満たされるためには、フィールド1とフィールド2の条件が両方とも満たされなければならず、したがって両方のパターンが一致しなければなりません。 ルールの優先順位は上から下へと設定されます。 エンティティのみのルールは、-エンティティ
の空の割り当てを防ぐためのキャッチオールデフォルトケースを許可します、特にスティッキー、ローミング、VPNデバイスに対して。
CSVファイルをアップロードするには:
Nexthink Webインターフェイスに中央管理者プロファイルのアカウントでログインします。
Navigationの主要メニューからCollectorsを選択し、システム構成。
新しいルールセットを追加ボタンをクリックします。
ダイアログボックスにフィールドに入力します。
ルールセットの名前の項目にルールに対して一意の名前を入力します。
説明フィールドに、ルールの目的を説明してください。
CSV ファイルの項目で、新しいファイルをアップロードをクリックし、事前に作成したCSVファイルを選択します。
Collector 割り当てのシミュレーション
1人のルールセットから別のルールセットへのシームレスな移行をするためには、まずルールをシミュレートすることを強くお勧めします。 Collector割り当てルールのシミュレーションを行うことで、現在割り当てられているエンジンおよびエンティティを実際に変更することなく、ルールを適用した影響を確認できます。
シミュレーションモードを有効にするには:
Nexthink Webインプロファイルの中央管理者アカウントでログインします。
Navigationの主要メニューからCollectorsを選択し、システム構成。
プロセスを促すためにシミュレートをクリック。
結果は、Webブラウザーが自動的にダウンロードするCSVファイルに保存されます。 それは、インスタンスおよびそれらの特性リンクされているすべてのデバイスを列に組織化してリストします。 最後のものには、シミュレーションによる値が含まれています。
device-36e68c7a
6.30.4.9
194.3.224.3
10.19.3.61
c40034
1000
ボストン
22.11.21 19:03
10.244.14.5:8443
-
ボストン
-
不明 (NOと見なされた)
エンジン-1
ボストン
割り当て済み
エンジン-1
ボストン
device-938b6df4
22.2.1.22
194.3.224.3
10.18.6.2
c40034
1000
マドリード
24.02.22 12:07
10.244.14.5:8443
-
マドリード
-
不明 (NOとみなされます)
エンジン-1
マドリード
割り当て済み
エンジン-1
マドリード
device-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
-
ボストン
-
不明 (NOとみなされます)
エンジン-1
ボストン
割り当て済み
エンジン-1
ボストン
device-1df8e1ce
21.7.1.19
194.3.224.3
10.29.2.4
1000
マドリード
13.10.21 13:20
10.244.14.133:8443
-
マドリード
-
不明 (NOとみなされます)
エンジン-1
マドリード
割り当て済み
エンジン-1
マドリード
device-784c6e93
21.8.1.24
194.3.224.3
10.21.22.15
1000
ロンドン
14.10.21 16:16
10.244.14.133:8443
-
ロンドン
-
不明 (NOとみなされます)
エンジン-1
ロンドン
割り当て済み
エンジン-1
ロンドン
device-51d1eb73
6.30.4.11
194.3.224.3
10.9.4.3
0
不明
01.11.21 11:32
10.244.14.133:8443
-
デフォルト
-
不明 (NOとみなされます)
エンジン-1
デフォルト
割り当て済み
エンジン-1
デフォルト
device-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
-
デフォルト
-
不明 (NOとみなされます)
エンジン-1
デフォルト
割り当て済み
エンジン-1
デフォルト
device-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
-
デフォルト
-
不明 (NOとみなされます)
エンジン-1
デフォルト
割り当て済み
エンジン-1
デフォルト
シミュレーション後にダウンロードされたCSVの一部の例。
コレクタの発見
インスタンスに接続するコレクタのリストを確認してください。
Nexthink ウェブインターフェースに中央管理者プロファイルのアカウントでログインします。
メインナビゲーションバーの 管理 メニューから、システム構成 の下で コレクタ を選択します。
インスタンスに関連付けられたデバイスのリストを デバイス の下で確認してください。
完全なリストを取得するために、すべてをエクスポート をクリックします。
テーブルの列には、コレクタの割り当て状況に関する現在の情報が表示されます。 これらの列には次のプロパティが含まれています;
デバイス名
コレクターバージョン
IPアドレス(最後のもの)
ADサイト
識別名
コレクタタグ番号
さらに、次の追加の列が見つかることがあります:
最後に見た (UTC)
コレクターからの最後の割り当てリクエストを受信した時間。
最後に見た場所
Collectorが最後に確認されたApplianceのIPアドレスとポート。
割り当てられたエンジン
Collectorがデータ送信するように設定されているエンジン。
割り当てられたエンティティ
Collectorが現在所属しているエンティティ。
ローミング開始 (UTC)
デバイスがローミングを開始した時間。
エラーメッセージ
Collectorの割り当てで最後に発生したエラー。
再割り当て
NexthinkインスタンスがCollectorにエンジンを正常に割り当てたら、エンジンから新しい割り当て情報を受け取ります。 TCP接続が中断されるたびに、Collectorは新しい割り当て情報を要求します。
また、割り当てルールが変更されるたびに、Collectorは別のエンジンに動的に再割り当てされることがあります。 再割り当てメッセージの配布には最大60分かかる場合があります。
一方、意図しないエンジンの切り替えを制限するために、新しいルールが適用されてから10日間、プロパティが変更されたデバイスの再割り当ては遅延されます (例: IPアドレス)。 これは、ローミングユーザーのラップトップのようにサブネットを頻繁に変更するデバイスにとって特に重要です。
割り当て失敗シナリオ
Collectorが新しい割り当てを取得したら、最初のFQDNを宛先として使用して割り当てられたエンジンへのTCP接続を確立しようとします。 Collectorが3回の再試行後にも到達できない場合、以前に割り当てられたエンジンに失敗を報告します。 その後、新しい割り当てを待ちます。 スタンバイ中、Collectorはトラフィックを送信しません。
割り当てが失敗したか確認するには:
中央管理者のプロファイルを持つアカウントでNexthinkウェブインターフェースにログインします。
メインナビゲーションバーの管理メニューから、システム構成の下にあるCollectorを選択します。
インスタンスに関連付けられたデバイスのリストをデバイスセクションで確認します。
エラーメッセージ列で、次のような値を持つリストエントリを探します:
最後の割り当てが失敗しました: エンジン [IPアドレス] TCPポート [番号]:...
デフォルトでは、100台のデバイスのみが表示されます。 完全なリストを取得するためにすべてをエクスポートをクリックします。
Last updated
Was this helpful?