カスタムトレンド管理
カスタムトレンドは標準のNexthinkデータモデルを拡張し、既存データの日次スナップショットを保存してその変化を最大13ヶ月間観察することができます。
カスタムトレンドは最大200件まで設定できます。
ライブラリからインストールしたカスタムトレンド
Nexthinkは、Nexthinkライブラリから手動でインストールできる一連の事前構成されたカスタムトレンドを提供します。 Nexthinkインスタンス内のNexthinkライブラリモジュールにアクセスして、事前定義されたカスタムトレンドをインストール、管理、更新します。
詳細については、Nexthink Library ドキュメントを参照してください。
新しいカスタムトレンド
最初からカスタムトレンドを作成することで、ニーズや使用ケースに応じたデータを表示できます。
詳細については、カスタムトレンドの作成を参照してください。
カスタムトレンドページへのアクセス
メインメニューから 管理 を選択します。
ナビゲーションパネルのコンテンツ管理セクションで カスタムトレンド をクリックします。
カスタムトレンドの管理
カスタムトレンド管理ページには、すでに定義されたカスタムトレンドのリストが表示されます。
テーブルの左上にあるカスタムトレンドの総数を表示します。
ページの右上にある検索ボックスを使用してカスタムトレンドを名前で検索し、一覧の結果を絞り込みます。
カスタムトレンドアクションメニューの使用
カスタムトレンドの縦に並んだ3点アイコンにカーソルを合わせて、以下のオプションが表示されるアクションメニューを表示します。
編集: カスタムトレンドの構成を詳細表示し、名前、説明、NQLクエリの変更を行います。
タグの管理: 関連するタグを追加または削除します。
エクスポート: カスタムトレンドをJSON形式でダウンロードして保存します。
削除: カスタムトレンドを削除します。
カスタムトレンドのインポート
ローカルデバイスからJSON形式のカスタムトレンドをインポートするには:
ページの右上隅にある 管理 > カスタムトレンド ページで インポート ボタンをクリックします。
複数のJSONファイルをハードドライブから選択またはドラッグしてシステムにインポートします。
すべてのインポートされたアイテムはカスタムコンテンツとして分類されます。
カスタムトレンドにタグを付ける
タグ付けにより、カスタムトレンドを効率的に整理し、データを迅速かつ簡単にナビゲートできます。
右側の タグ パネルを開いて:
パネル上部で特定のタグを検索します。
カスタムトレンドテーブルをフィルターするために1つ以上のタグを選択します。
管理 > カスタムトレンド ページから、カスタムトレンドに1つ以上のタグを追加するには
カスタムトレンドにカーソルを合わせてアクションメニューを表示し、タグの管理 を選択します。
タグの管理 ポップアップからは:
新しいタグを入力するか、既存のものを選択してカスタムトレンドに追加します。
特定のタグ項目のアクションメニューを開いて タグを削除 したり、タグの色を変更します。
タグを削除しても、関連付けられたカスタムトレンドからのみ削除されます。
別の方法として、複数のカスタムトレンドを選択してタグを一括管理することも可能です。
カスタムトレンドの作成
新しいカスタムトレンドを作成するには:
カスタムトレンドページの右上隅にある 新しいカスタムトレンド ボタンをクリックします。
カスタムトレンド構成ページで 名前 と 説明 を入力します。
必要に応じて、NQLの一意識別子である クエリID を調整します。
このトレンドデータの意味と目的を他の人が理解しやすくするため、オプションの 説明 を入力します。
日次スナップショット評価中にNexthinkプラットフォームが実行する NQLクエリ を記述します。
カスタムトレンドを保存した後は、NQLクエリとクエリIDの値を変更できませんので注意してください。
カスタムトレンドのNQLクエリの記述
クエリを記述する際、次のルールに従ってください。
クエリは
devices名前空間をターゲットとしなければなりません。devicesの許可される時間間隔は過去1日です。 この時間間隔を省略すると、システムに登録されているすべてのデバイスがターゲットになります。クエリには最大2つの
include節およびcompute節を含めることができます。イベントコレクションの
include節の後に許可される時間間隔は過去1日です。 時間間隔を指定せずにオブジェクトコレクションを含めることができます。compute節の結果に適用されるwhere節はNexthinkでは許可されていません。クエリには、デバイス名や従業員のメールアドレスなど個人を特定する情報(PII)を含めることはできません。
クエリは、2つのメトリクス(数値)と最大5つのプロパティ(文字列、列挙、またはブール)を含む
list節で終了しなければなりません。システムでは、
as()、sort、limit、summarize、countif()、sumif()、withキーワードは許可されていません。
日時メトリクスの制限
カスタムトレンドはデータ型の一部のサブセットのみをネイティブにサポートします。 ほとんどの場合、これが機能に影響を及ぼすことはありません。 しかし、日時メトリクスはネイティブタイプとして保存されないため、nql-time_elapsed.mdやnql-date-time-functionsなどのタイムスタンプ関数を使用できません。
システムは、デフォルトでデバイスのコンテキストの一部として日次スナップショットを評価する際に、いくつかのデバイスプロパティを含めます。 これには以下が含まれます:
オペレーティングシステムプラットフォーム
オペレーティングシステム名
位置 (国、州、位置タイプ)
組織 (エンティティ、カスタム組織)
カスタムトレンドデータに含まれるデバイスの理解
カスタムトレンドの定義において、デバイスセットをその活動に基づいて指定できます。
システムに登録されているすべてのデバイス（過去30日間にアクティブだったすべてのデバイス、データ解像度と保持を参照）でスナップショットを保存するには、カスタムトレンドの定義で
devicesテーブルの時間選択を省略します。
スナップショットが撮られた日にアクティブだったデバイスでスナップショットを保存するためには、カスタムトレンドの定義で
during past 1dをdevicesの後に追加します。
デバイスの時間枠を指定していない場合、同じ期間内のオペレーショナルデータとの比較時に両者の間にわずかな不整合が見込まれます。
データ保持の承認
このトレンドデータがシステムに13ヶ月保存されることを認めるためにデータ保持チェックボックスを選択します。
新しいカスタムトレンドを保存するには、保存ボタンをクリックします。
カスタムトレンドの使用
カスタムトレンドを保存した後、NQLで新しいトレンドデータをクエリすることができます。 最初は、保存されたカスタムトレンド定義の日を起点とした3日前からのデータのみがクエリによって返されます。 これにより、設定したカスタムトレンドが期待どおりにデータを返すかどうかを確認できます。
3日間の初期データは、その日ごとのデバイスコンテキスト情報のみを含むことになります。
システムは毎晩追加のスナップショットを保存します。 スナップショットには、顧客のタイムゾーンで計算日から前日の真夜中までのイベントを含みます。
以下は、カスタムトレンドの定義で使用されるNQLクエリの例です。
| list 節を使用してトレンドにメトリクスとプロパティを保存すると、カスタムトレンドテーブル内に新しいフィールドが作成されます。 システムは以下のルールに従って新しいフィールド名を構成します:
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 という新しいフィールド名が作成されます。
カスタムトレンドテーブルは以下のようになります。
2024/01/19 00:00:00 AM
デバイス1のコンテキスト情報
デバイス1の nb_crashes
デバイス1の hardware_manufacturer
2024/01/19 00:00:00 AM
デバイス2のコンテキスト情報
デバイス2の nb_crashes
デバイス2の hardware_manufacturer
2024/01/19 00:00:00 AM
デバイス3のコンテキスト情報
デバイス3の nb_crashes
デバイス3の hardware_manufacturer
2024/01/19 00:00:00 AM
…
2024/01/20 00:00:00 AM
デバイス1のコンテキスト情報
デバイス1の nb_crashes
デバイス1の hardware_manufacturer
2024/01/20 00:00:00 AM
デバイス2のコンテキスト情報
デバイス2の nb_crashes
デバイス2の hardware_manufacturer
2024/01/20 00:00:00 AM
デバイス3のコンテキスト情報
デバイス3の nb_crashes
デバイス3の hardware_manufacturer
2024/01/20 00:00:00 AM
…
Insightsまたはタイムライン上のダッシュボードウィジェットを作成して、カスタムトレンドデータを照会できます。 カスタムトレンドデータを取得するための構文は次の通りです。
ウィジェットを設定する際に、特定のメトリクスの時間経過による変化を視覚的に表現するために、既存のカスタムトレンドのNQL IDを使用します。
トレンドの関連付け
トレンドテーブルは devices テーブルと関連付けられています。 トレンドデータを取得する際には、これらの関連付けを利用して、クエリ内にデバイスプロパティを含めることができます。 ただし、これらのプロパティは元のテーブルに保存されている限り、有効とされます。 詳細については、データ解像度と保存ページを参照してください。
カスタムトレンドフィールド、例えば hardware_manufacturer は最大13ヶ月の保持期間がある一方で、関連付けられたデバイスのプロパティはシステムに登録されている間にのみ有効です。 デバイスが削除または匿名化された場合、または30日以上アクティブでない場合は、デバイスプロパティがトレンドに直接保存されていないため、クエリは "-" を返します。 これは、カスタムトレンドがデフォルトで保存し、13か月間保持されるデバイスコンテキスト情報には適用されません（このページの カスタムトレンドのためのNQLクエリの作成 を参照）。
カスタムトレンドの最適化
カスタムトレンドを効果的に活用するには、トレンドデータをプロットすることがカスタムトレンドの構成とダッシュボード設計の2段階のプロセスであることを理解することが重要です（詳細な指示については ライブダッシュボード管理 を参照）。
追跡したいすべての指標に対してカスタムトレンドを作成する必要は必ずしもないことに注意してください。 単一のカスタムトレンドは、メトリクスと集計のさまざまな組み合わせで長期データを照会できるようにするNQLデータモデルの拡張として機能します。
カスタムトレンドの構成と取得に関する次の推奨事項を考慮してください。
可能な限り取得時にフィルターと集計を適用する
デバイスでデータをフィルタリングし、傾向の定義ではなく取得時に集計を適用することを推奨します。
クラッシュを経験しているデバイスの数をハードウェア製造元ごとにプロットするトレンドラインを考えてみましょう。 さまざまな戦略が可能ですが、すべてが最適であるわけではありません。
非最適戦略
非最適な戦略は、各ハードウェアプロバイダーのためにデバイスの集計を伴う複数のカスタムトレンド定義を作成することです。 次のクエリは、特定のデバイスでクラッシュが発生しなかった場合に0を示し、少なくとも1回のクラッシュが発生した場合に1を示すデバイスのリストを返します。
カスタムトレンドデータを取得する際に、フィルターは必要ありません。
最適戦略
最適戦略では、クラッシュの数を指標として、ハードウェア製造元をプロパティとして抽出するカスタムトレンド定義を1つ作成します。
カスタムトレンドデータを取得する際：
クラッシュが少なくとも1回発生したデバイスと関連するハードウェアプロバイダーのフィルター：
代替案として、クラッシュが1回以上発生したデバイスのみを要約し、ハードウェアプロバイダーごとに追加のグループ化を行う条件付き集計を使用します：
ダブル集計は慎重に使用する
カスタムトレンドは、トレンドデータを取得するときに追加の集計を実行することもできます。 取得中、トレンドデータに対して追加の集約を行うこともできます。 ただし、スナップショットは、定義で使用された集計に関する情報を失います（ユニークなオブジェクト（たとえば、users）にcount()を使用した場合を除く）。
次の例を考えてみましょう。 カスタムトレンド定義のNQLは、指定された日の各デバイスの平均起動時間を含むスナップショットを作成します。
デバイス全体で毎日のスナップショットの平均を計算する際、データを取得できます。
この場合、avg() 集計が返す結果は、起動を持つデバイスの数で割った各デバイスの平均値の合計となります。
スナップショットの障害をトラブルシュートする
カスタムトレンドログの調査
スナップショットを保存できなかった場合、カスタムトレンドデータは不完全になる可能性があります。 これらの障害を理解することは、問題を迅速に解決し、表示されたデータの潜在的な問題を可視化する上で重要です。 システムでは、各カスタムトレンド計算を、計算時間、状態、カスタムトレンドNQL IDなどの詳細とともに platform.custom_trends_logs テーブルに保存します。
システムは各カスタムトレンドの計算を、計算時間、ステータス、およびカスタムトレンドNQL IDなどの詳細とともにplatform.custom_trends_logsテーブルに保存します。 プラットフォームのカスタムトレンド計算の失敗の原因を調査するには、次のNQLクエリを使用します。
Nexthinkは、カスタムトレンドのすべての障害を検出するモニターを構成することを推奨します。 次のモニターNQLクエリと設定を使用してください。
詳細については、カスタムモニターの作成ページを参照してください。
トレンドバックフィル
Nexthinkは、予期しない技術的な障害によって生じるカスタムトレンドデータのギャップを防ぐためのメカニズムを使用しています。 システムが特定の日のスナップショットの計算と保存に失敗した場合、次の毎日の計算では、現在のスナップショットの計算を行う前に、欠落しているデータの計算を試みます。 このメカニズムは、ダッシュボードでのトレンドの継続性を維持するために、問題を解決する時間を追加で提供し、過去3日間のデータを復元できます。
前日のデータから計算されたデータには、現在の日のデバイスコンテキスト情報のみが含まれます。
権限
あなたのユーザー役職が すべてのカスタムトレンドデータを管理する 権限を有効にした場合、Nexthinkウェブインターフェースでカスタムトレンドを作成できます。
あなたのユーザー役職が NQLでプラットフォームログを表示する 権限を有効にした場合、
platform.custom_trends_logsテーブルにアクセスできます。
詳細については 役割 ドキュメントを参照してください。
Last updated
Was this helpful?