カスタム傾向管理
Last updated
Last updated
カスタムトレンドは標準のNexthinkデータモデルを拡張し、既存データの日次スナップショットを保存し、最大13カ月にわたる進化を観察可能にします。
カスタムトレンドは最大200個まで構成することができます。
Nexthinkは、Nexthinkライブラリから手動でインストールできる一連の事前設定されたカスタムトレンドを提供しています。 Nexthinkインスタンス内のNexthinkライブラリモジュールに移動して、事前定義されたカスタムトレンドのインストール、管理、更新を行います。
詳細については、Nexthinkライブラリのドキュメントを参照してください。
ゼロからカスタムトレンドを作成することで、求めているデータをニーズやユースケースに応じて表示することができます。
詳細については、カスタムトレンドの作成 を参照してください。
メインメニューからAdministrationを選択します。
ナビゲーションパネルのコンテンツ管理セクションでカスタムトレンドをクリックします。
カスタムトレンド管理ページは、すでに定義されたカスタムトレンドのリストを表示します。
テーブルの左上にある合計カスタムトレンド数を表示します。
ページの右上にある検索ボックスを使用して、名前でカスタムトレンドを検索し、リストされた結果を絞り込みます。
カスタムトレンドの横にある3つの垂直ドットアイコンにカーソルを置くと、次のオプションを含むアクションメニューが表示されます。
編集: カスタムトレンド設定の詳細を表示し、名前、説明、NQLクエリを変更します。
タグの編集: 関連するタグを追加または削除します。
エクスポート: カスタムトレンドをJSON形式でダウンロードして保存します。
削除: カスタムトレンドを削除します。
ページの右上のインポートをクリックします。
デバイスからインポートしたいカスタムトレンドのJSONファイルを選択します。
インポートされたアイテムはすべてカスタムコンテンツとして分類されます。
タグ付けを行うことで、カスタムトレンドを効率的に整理し、データを迅速かつ容易にナビゲートできるようにします。 右側のパネルからタグを入力または選択してテーブルをフィルターします。
タグを割り当て、削除、または編集するには:
カスタムトレンドにカーソルを合わせて、テーブルの右側にアクションメニューを表示します。
タグの編集をクリックして、タグポップアップを開きます。
新しいタグ名を入力するか既存のものを選択し、カスタムトレンドに追加します。
タグのアクションメニューを開いて、カスタムトレンドからタグを削除したり、タグの色を変更したりします。 タグを削除しても、関連するカスタムトレンドからしか削除されません。
新しいカスタムトレンドを作成するには:
カスタムトレンドページの右上にある新しいカスタムトレンドボタンをクリックします。
カスタムトレンド設定ページで名前と説明を入力します。
必要に応じて、NQLの一意の識別子であるクエリIDを調整します。
このトレンドデータの意味と目的を理解するのに役立つように、オプションで説明を入力します。
日次スナップショット評価時にNexthinkプラットフォームが実行するNQLクエリを記述します。
カスタムトレンドを保存した後は、NQLクエリとクエリIDの値を変更することはできませんのでご注意ください。
クエリを記述する際には、以下のルールに従ってください:
クエリはdevices
ネームスペースをターゲットにしなければなりません。
devices
のための許可された時間間隔は過去1日以内
です。 この時間間隔を省略すると、システムに登録されているすべてのデバイスをターゲットにします。
クエリは、最大2つのinclude
句と2つのcompute
句を持つ必要があります。
イベントコレクションのためのinclude
句の後に許可される唯一の時間間隔は過去1日以内
です。 時間間隔を指定せずにオブジェクトコレクションを含めることができます。
Nexthinkは、compute
句の結果に適用されるときにはwhere
句を許可しません。
クエリは、デバイス名や従業員のメールアドレスなどの個人識別情報(PII)を含むことはできません。
クエリは最大2つのメトリック(数値)と最大5つのプロパティ(文字列、列挙、またはブール値)を含むlist
句で終了しなければなりません。
システムは、as()
、 sort
、limit
、summarize
、countif()
、sumif()
、またはwith
キーワードを許可しません。
システムは、デフォルトでいくつかのデバイスプロパティを日次スナップショット評価時に含め、それらをデバイスのコンテキストの一部として保存します。 これには次が含まれます:
オペレーティングシステムプラットフォーム
オペレーティングシステム名
所在地(国、州、場所の種類)
組織(エンティティ、カスタム組織)
カスタムトレンドの定義において、デバイスの活動に基づいてデバイスのセットを指定することができます。
カスタムトレンドの定義でdevices
テーブルの時間選択を省略することで、システムに登録されている**すべてのデバイス(過去30日間アクティブだったすべてのデバイス、データの解像度と保持を参照)**を含むスナップショットを保存します。
カスタムトレンドの定義でdevices
の後に過去1日以内
を追加して、スナップショットが取得された日にアクティブだったデバイスを含むスナップショットを保存します。
デバイスの時間枠を指定していない場合、同期間の運用データとの比較において若干の結果の不一致が予想されることがあります。
このトレンドデータが最大13カ月間システムに保存されることを確認するために、データ保持チェックボックスを選択します。
新しいカスタムトレンドを保存するには、保存ボタンをクリックします。
カスタムトレンドを保存した後、新しいトレンドデータをNQLでクエリすることができます。 初期クエリは、カスタムトレンドの定義が保存された日の3日前からのデータのみを返します。 これにより、構成したカスタムトレンドが期待通りの形式でデータを返すかどうかを確認できます。
過去3日間に計算された初期データには、現在のデバイスコンテキスト情報のみが含まれます。
システムは追加のスナップショットを毎晩保存します。 スナップショットには、顧客のタイムゾーンで、計算日の深夜から前日の深夜までに発生したイベントが含まれます。
以下は、カスタムトレンドの定義で使用されるNQLクエリの例です:
| list
句を使用してトレンドでメトリックとプロパティを保存することで、カスタムトレンドテーブル内に新しいフィールドを作成します。 システムは以下のルールに従って新しいフィールド名を構築します:
nb_crashes
nb_crashes
クエリからのカスタムメトリックは、例のnb_crashes
のように変更されません。
hardware.manufacturer
hardware_manufacturer
ピリオド。
はアンダースコア_
に置き換えられます。
device.#custom_field
device__custom_field
先頭以外のハッシュ#
はアンダースコア_
に置き換えられます。
#custom_field
#custom_field
先頭のハッシュ#
はカスタムトレンドフィールド名にそのまま残ります。
device.last_seen.time_elapsed()
device_last_seen_time_elapsed
関数の括弧()
は省略されます。
上記の例で、カスタムトレンド定義の| list句の中でdevices
テーブルのhardware.manufacturer
フィールドを使用すると、カスタムトレンドテーブルにhardware_manufacturer
という名前の新しいフィールドが作成されます。
カスタムトレンドテーブルは以下のようになります:
19/01/2024 00:00:00 AM
デバイス1のコンテキスト情報
デバイス1のnb_crashes
デバイス1のhardware_manufacturer
19/01/2024 00:00:00 AM
デバイス2のコンテキスト情報
デバイス2のnb_crashes
デバイス2のhardware_manufacturer
19/01/2024 00:00:00 AM
デバイス3のコンテキスト情報
デバイス3のnb_crashes
デバイス3のhardware_manufacturer
19/01/2024 00:00:00 AM
….
20/01/2024 00:00:00 AM
デバイス1のコンテキスト情報
デバイス1のnb_crashes
デバイス1のhardware_manufacturer
20/01/2024 00:00:00 AM
デバイス2のコンテキスト情報
デバイス2のnb_crashes
デバイス2のhardware_manufacturer
20/01/2024 00:00:00 AM
デバイス3のコンテキスト情報
デバイス3のnb_crashes
デバイス3のhardware_manufacturer
20/01/2024 00:00:00 AM
…
Investigationsでカスタムトレンドデータをクエリしたり、ダッシュボードウィジェットを作成してタイムラインでトレンドを監視することができます。 カスタムトレンドデータを取得するための構文は以下の通りです:
ウィジェットを構成する場合、既存のカスタムトレンドのNQL IDを使用して、特定のメトリックの時間経過による進化を視覚的に表現します。
トレンドテーブルはdevices
テーブルと関連付けられています。 トレンドデータを取得する際には、これらの関連情報を使用してデバイスプロパティをクエリに含めることができます。 ただし、これらのプロパティは元のテーブルに保存されている限りのみ利用可能です。 詳細については、データ解像度と保持ページを参照してください。
hardware_manufacturer
のようなカスタムトレンドフィールドは最大13ヶ月の保持期間がある一方、関連するデバイスのプロパティはシステムにデバイスが登録されている限り利用可能です。 デバイスを削除または匿名化するか、デバイスが30日以上非アクティブであった場合には、トレンドにデバイスプロパティが直接保存されていないため、クエリは"-"を返します。 これはデフォルトでカスタムトレンドが保存するデバイスコンテキスト情報には適用されず、こちらも13ヶ月間保持されます(このページのNQLクエリを用いたカスタムトレンドの作成を参照)。
カスタムトレンドを効果的に利用するためには、トレンドデータのプロットはカスタムトレンドの設定とdashboardデザインの2段階のプロセスが必要であることを理解することが重要です(詳細な指示については、Live Dashboardsの管理を参照)。
追跡したいすべてのメトリックごとに必ずしもカスタムトレンドを作成する必要はないことに注意してください。 単一のカスタムトレンドはNQLデータモデルの拡張として機能し、さまざまなメトリックと集計の組み合わせで長期データをクエリすることができます。
カスタムトレンドの設定と取得に関する以下の推奨事項を考慮してください。
スナップショットの計算はさまざまな理由で失敗することがあります。たとえば、カスタムフィールドや組織構造などの動的データモデルの変更によりカスタムトレンドNQLクエリの定義が誤っている場合や、システムが一時的に障害を経験した場合などです。 失敗は不完全なカスタムトレンドデータの原因となる可能性があります。 これらの失敗を理解することは、ダッシュボードに表示されるデータの問題に迅速に対処し、可視性を向上させるために重要です。
システムは各カスタムトレンド計算を、計算時間、ステータス、カスタムトレンドNQL IDなどの詳細とともにplatform.custom_trends_logs
テーブルに保存します。 特定のカスタムトレンド計算の失敗の原因を調査するために次のNQLクエリを使用します。
Nexthinkは、すべてのカスタムトレンド失敗を検出するモニターを設定し、情報を把握し迅速に対応することを推奨しています。 次のモニターNQLクエリと設定を使用してください。
詳細については、カスタムモニターの作成ページをご覧ください。
Nexthinkは、予期しない技術的障害によるカスタムトレンドデータのギャップを防ぐメカニズムを使用しています。 システムが特定の日のスナップショットの計算と保存に失敗した場合、次の日の計算中に、現在のスナップショットを計算する前に不足しているデータの計算を試みます。 このメカニズムは過去最大3日間のデータを回復することができ、問題を解決しダッシュボード上のトレンドの継続性を維持するための追加の時間を提供します。
過去の日から計算されたデータには、現在の日からのデバイスコンテキスト情報のみが含まれます。
ユーザーロールにすべてのカスタムトレンドデータを管理する権限がある場合、Nexthink webインターフェースでカスタムトレンドを作成できます。
ユーザーロールにNQLでPlatformログを表示する権限がある場合、platform.custom_trends_logs
テーブルにアクセスできます。
詳細については、役割ドキュメントを参照してください。