カスタムトレンド管理

カスタムトレンドは標準のNexthinkデータモデルを拡張し、既存データの日次スナップショットを保存して、最大13か月にわたる経時的な変化を確認できます。

最大200件のカスタムトレンドを設定できます。

Libraryからインストールしたカスタムトレンド

Nexthinkは、Nexthink Libraryから手動でインストールできる一連の事前設定済みカスタムトレンドを提供します。 Nexthinkインスタンス内のNexthink Libraryモジュールに移動し、事前定義されたカスタムトレンドをインストール、管理、および更新します。

詳細については、Nexthink Library ドキュメントを参照してください。

新しいカスタムトレンド

カスタムトレンドを一から作成すると、ニーズやユースケースに応じて必要なデータを表示できます。

詳細については、カスタムトレンドの作成を参照してください。

カスタムトレンドページへのアクセス

1. メインメニューから 管理 を選択します。
2. ナビゲーションパネルの「コンテンツ管理」セクションで カスタムトレンド をクリックします。

カスタムトレンドの管理

カスタムトレンド管理ページには、すでに定義されているカスタムトレンドのリストが表示されます。

• テーブルの左上に表示されるカスタムトレンドの合計数を確認します。
• ページ右上の検索ボックスで名前によりカスタムトレンドを検索し、表示結果を絞り込みます。

カスタムトレンドのアクションメニューの使用

カスタムトレンドの縦三点アイコンにカーソルを合わせると、次のオプションを含むアクションメニューが表示されます：

• 編集: カスタムトレンド設定の詳細を表示し、名前、説明、NQLクエリを変更します。
• タグを管理: 関連付けられたタグを追加または削除します。
• エクスポート: カスタムトレンドをJSON形式でダウンロードして保存します。
• 削除: カスタムトレンドを削除します。

カスタムトレンドのインポート

ローカルデバイスからJSON形式のカスタムトレンドをインポートするには：

1. 管理 > カスタムトレンド ページの右上隅にある インポート ボタンをクリックします。
2. ハードドライブから複数のJSONファイルを選択またはドラッグして、システムにインポートします。

インポートされたすべての項目は、カスタムコンテンツとして分類されます。

カスタムトレンドへのタグ付け

タグ付けにより、カスタムトレンドを効率的に整理でき、データをすばやく簡単に移動できます。

右側の タグ パネルを開いて、次の操作を行います：

• パネル上部で特定のタグを検索します。
• 一つ以上のタグを選択して、カスタムトレンドテーブルをフィルタリングします。

管理 > カスタムトレンド ページからカスタムトレンドに一つ以上のタグを追加するには：

1. カスタムトレンドにカーソルを合わせてアクションメニューを表示し、タグを管理 を選択します。
2. タグを管理 ポップアップでは、次の操作を実行できます：

   • 新しいタグを入力するか既存のタグを選択して、カスタムトレンドに追加します。
   • 特定のタグ項目のアクションメニューを開き、タグを削除するかタグの色を変更します。

     • タグを削除しても、そのタグが関連付けられているカスタムトレンドから削除されるだけです。
3. または、複数のカスタムトレンドを選択して、一括でタグを管理できます。

カスタムトレンドの作成

新しいカスタムトレンドを作成するには：

1. カスタムトレンドページの右上隅にある 新しいカスタムトレンド ボタンをクリックします。
2. カスタムトレンド設定ページで 名前 と 説明 を入力します。
3. 必要に応じて、NQLの一意の識別子である クエリID を調整します。
4. このトレンドデータの意味と目的を他のユーザーが理解できるよう、任意の 説明 を入力します。
5. 日次スナップショットの評価時にNexthinkプラットフォームが実行する NQLクエリ を記述します。

カスタムトレンドを保存すると、NQLクエリとクエリIDの値は変更できなくなることに注意してください。

カスタムトレンド用のNQLクエリの記述

クエリを記述する際は、以下のルールに従ってください：

• クエリは devices 名前空間を対象にする必要があります。
• devices で使用できる時間範囲は past 1d です。 システムに登録されているすべてのデバイスを対象にするには、この時間範囲を省略します。
• クエリには include 句を最大二つ、compute 句を最大二つ含めることができます。
• イベントコレクションの include 句の後で使用できる唯一の時間範囲は past 1d です。 時間範囲を指定せずにオブジェクトコレクションを含めることができます。
• Nexthinkでは、compute 句の結果に適用する where 句は使用できません。
• クエリにデバイス名や従業員のメールアドレスなどの個人識別情報（PII）を含めることはできません。
• クエリは、最大二つのメトリクス（数値）と最大五つのプロパティ（文字列、列挙型、またはブール値）を含む list 句で終える必要があります。
• システムでは、as()、sort、limit、summarize、countif()、sumif()、with のキーワードを使用できません。

日時メトリクスの制限事項

カスタムトレンドは、ネイティブではデータ型の一部のみをサポートしています。 ほとんどの場合、これは機能に影響しません。 ただし、日時メトリクスはネイティブ型として保存されないため、NQL time_elapsed() や NQL datetime関数 などのタイムスタンプ関数は使用できません。

システムではデフォルトで、日次スナップショットの評価時に一部のデバイスプロパティを含め、デバイスのコンテキストの一部として保存します。 これには次が含まれます：

• オペレーティングシステムプラットフォーム
• オペレーティングシステム名
• 場所（国、都道府県、場所の種類）
• 組織（エンティティ、カスタム組織）

カスタムトレンドデータに含まれるデバイスについて

カスタムトレンドの定義では、アクティビティに基づいてデバイスのセットを指定できます。

• システムに登録されているすべてのデバイス（過去30日間にアクティブだったすべてのデバイス。詳細はデータ解像度と保存を参照）を含むスナップショットを保存するには、カスタムトレンドの定義で devices テーブルの時間指定を省略します。

devices
| include … during past 1d 
| compute … 
| list …

• スナップショット取得日にアクティブだったデバイスを含むスナップショットを保存するには、カスタムトレンドの定義で devices の後に during past 1d を追加します。

devices during past 1d
| include … during past 1d 
| compute … 
| list …。

デバイスの時間枠を指定していない場合、トレンドデータと同じ期間の運用データを比較すると、結果にわずかな差異が生じることがあります。

データ保持の承認

• データ保持チェックボックスを選択し、このトレンドデータが13か月間システムに保存されることを確認します。
• 保存ボタンをクリックして、新しいカスタムトレンドを保存します。

カスタムトレンドの使用

カスタムトレンドを保存すると、NQLで新しいトレンドデータをクエリできます。 最初に、クエリはカスタムトレンド定義を保存した日の前の三日間のデータのみを返します。 これにより、設定したカスタムトレンドが期待どおりの形式でデータを返すかを確認できます。

過去三日間から計算される初期データには、当日のデバイスコンテキスト情報のみが含まれます。

システムは毎晩、追加のスナップショットを保存します。 スナップショットには、顧客のタイムゾーンで前日の午前零時から計算日の午前零時までに発生したイベントが含まれます。

以下は、カスタムトレンドの定義で使用するNQLクエリの例です：

devices 
| include execution.crashes past 1d 
| compute nb_crashes = number_of_crashes.sum() 
| list nb_crashes , hardware.manufacturer

| 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でカスタムトレンドデータをクエリするか、ダッシュボードウィジェットを作成してタイムライン上のトレンドを監視できます。 カスタムトレンドデータを取得する構文は次のとおりです：

custom_trend.<NQL ID>.snapshots ...
…

ウィジェットを設定する際は、既存のカスタムトレンドのNQL IDを使用して、特定のメトリクスの経時的な変化を視覚的に表します。

トレンドの関連付け

トレンドテーブルは devices テーブルに関連付けられています。 トレンドデータを取得する際は、この関連付けを利用してデバイスプロパティをクエリに含めることができます。 ただし、これらのプロパティは元のテーブルに保存されている間のみ利用できます。 詳細については、データ解像度と保存ページを参照してください。

hardware_manufacturer などのカスタムトレンドフィールドは最大13か月保持されますが、関連付けられたデバイスのプロパティは、デバイスがシステムに登録されている間のみ利用できます。 デバイスを削除または匿名化した場合、またはデバイスが30日を超えて非アクティブであった場合、デバイスプロパティはトレンドに直接保存されないため、クエリは「-」を返します。 これは、カスタムトレンドがデフォルトで保存するデバイスコンテキスト情報には適用されません。この情報も13か月間保持されます（このページのカスタムトレンド用のNQLクエリの記述を参照）。

カスタムトレンドの使用の最適化

カスタムトレンドを効果的に活用するには、トレンドデータのプロットには、カスタムトレンドの設定とダッシュボード設計という二段階のプロセスがあることを理解する必要があります（詳しい手順についてはLive Dashboardsの管理を参照）。

追跡するすべてのメトリクスに対して、必ずしもカスタムトレンドを作成する必要はないことに注意してください。 一つのカスタムトレンドはNQLデータモデルの拡張として機能し、さまざまなメトリクスと集計の組み合わせで長期データをクエリできます。

カスタムトレンドの設定と取得について、以下の推奨事項を考慮してください：

可能な場合は、取得時にフィルターと集計を適用する

トレンド定義内ではなく、取得時にデータをフィルタリングし、デバイスに集計を適用することをお勧めします。

ハードウェアメーカー別にクラッシュが発生したデバイス数のトレンドラインをプロットする例を考えてみましょう。 複数の戦略が可能ですが、すべてが最適とは限りません。

最適ではない戦略

最適ではない戦略として、ハードウェアプロバイダーごとにデバイスの集計を含む複数のカスタムトレンド定義を作成する方法があります。 次のクエリは、特定のデバイスでクラッシュが発生していない場合はゼロ、少なくとも一回クラッシュが発生した場合は一を示すデバイスのリストを返します。

devices
| where hardware.manufacturer == "my_provider1"
| include execution.crashes past 1d
| compute nb_devices = device.count()
| list nb_devices

カスタムトレンドデータを取得する際、フィルターは不要です。

custom_trend.#name.snapshots during past 300d
| summarize my_provider1_with_crashes = nb_devices.sum() by 1d

最適な戦略

最適な戦略では、クラッシュ数をメトリクス、ハードウェアメーカーをプロパティとしてスナップショットに記録するカスタムトレンド定義を一つ作成します：

devices
| include execution.crashes past 1d
| compute nb_crashes = number_of_crashes.sum()
| list nb_crashes , hardware.manufacturer

カスタムトレンドデータを取得する際：

• 少なくとも一回クラッシュしたデバイスと、該当するハードウェアプロバイダーをフィルタリングします：

custom_trend.#name.snapshots during past 300d
| where nb_crashes > 0
| where hardware_manufacturer == "my_provider1"
| summarize my_provider1_with_crashes = count() by 1d

• または、条件付き集計を使用して少なくとも一回クラッシュしたデバイスのみを集計し、ハードウェアプロバイダーによる追加のグループ化を行います：

custom_trend.#execution_crashes.snapshots during past 300d
| summarize
fraction_with_crashes_per_manifacturer = countif(nb_crashes > 0) / count()
by 1d, hardware_manufacturer

二重集計を慎重に使用する

カスタムトレンドでは、カスタムトレンド定義内に集計を組み込むことができます。 取得時に、トレンドデータに対して追加の集計を実行することもできます。 ただし、スナップショットには定義で使用された集計に関する情報が保持されないことに注意してください（users などの一意のオブジェクトに count() を使用した場合を除く）。

次の例を考えてみましょう。 カスタムトレンド定義内のNQLは、特定の日における各デバイスの平均起動時間を含むスナップショットを作成します。

devices during past 1d
| include device_performance.boots during past 1d
| compute boot_duration = duration.avg()

データを取得する際、すべてのデバイスにわたる日次スナップショットの平均を計算できます。

custom_trend.#name.snapshots
| summarize c1 = boot_duration.avg() by 1d

この場合、avg() 集計が返す結果は、各デバイスの平均値の合計を、起動があったデバイス数で割った値になります。

スナップショット失敗のトラブルシューティング

カスタムトレンドログの調査

スナップショット計算は、さまざまな理由で失敗することがあります。たとえば、カスタムフィールドや組織構造などの動的データモデルの変更によりカスタムトレンドNQLクエリ定義が正しくなくなった場合や、システムで一時的な障害が発生した場合です。 失敗すると、カスタムトレンドデータが不完全になる可能性があります。 これらの失敗を理解することは、問題を迅速に解決し、ダッシュボードに表示されるデータの潜在的な問題を可視化するうえで重要です。

システムは、計算時刻、ステータス、カスタムトレンドNQL IDなどの詳細を含む各カスタムトレンド計算を platform.custom_trends_logs テーブルに保存します。 特定のカスタムトレンド計算の失敗原因を調査するには、次のNQLクエリを使用します：

platform.custom_trends_logs during past 30d
| where status = failure
| where details.nql_id ="#my_custom_trend_ID"
| list custom_trends_log.time, 
       custom_trends_log.status, 
       details.description, 
       details.n_retries, 
       details.nql_id

常に情報を把握し迅速に対応できるよう、すべてのカスタムトレンドの失敗を検出するモニターを設定することをNexthinkは推奨します。 次のモニターNQLクエリと設定を使用します：

platform.custom_trends_logs during past 24h
| where status = failure
| summarize failing_computations = count() by details.nql_id

詳細については、カスタムモニターの作成ページを参照してください。

トレンドのバックフィル

Nexthinkは、予期しない技術的障害によるカスタムトレンドデータの欠落を防ぐ仕組みを使用しています。 特定の日のスナップショットの計算と保存に失敗した場合、次の日次計算時に、現在のスナップショットを計算する前に不足データの計算を試行します。 この仕組みでは、過去三日間までのデータを復元できるため、問題に対処し、ダッシュボード上のトレンドの連続性を維持するための時間を確保できます。

過去の日から計算されたデータには、当日のデバイスコンテキスト情報のみが含まれます。

権限

• ユーザーロールで すべてのカスタムトレンドデータを管理 権限が有効になっている場合、Nexthink Webインターフェイスでカスタムトレンドを作成できます。
• ユーザーロールで NQLでプラットフォームログを表示 権限が有効になっている場合、platform.custom_trends_logs テーブルにアクセスできます。

詳細については、ロールドキュメントを参照してください。