カスタムトレンド管理

カスタムトレンドは標準のNexthinkデータモデルを拡張し、既存のデータの1日ごとのスナップショットを保存し、その変化を最大13か月間観察することができます。

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

ライブラリからインストールされたカスタムトレンド

Nexthinkは、Nexthinkライブラリから手動でインストールできる一連の事前構成されたカスタムトレンドを提供します。 Nexthinkインスタンス内のNexthinkライブラリモジュールにアクセスして、事前定義されたカスタムトレンドをインストール、管理、更新します。

詳細情報については、Nexthink ライブラリドキュメントをご覧ください。

新しいカスタムトレンド

カスタムトレンドを最初から作成することで、ニーズやユースケースに応じたデータを表示できます。

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

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

1. メインメニューから管理を選択します。

2. ナビゲーションパネルのコンテンツ管理セクション内でカスタムトレンドをクリックします。

カスタムトレンドの管理

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

• 表の左上にあるトータルカスタムトレンド数を確認します。

• ページの右上にある検索ボックスを使用してトレンド名で検索し、リスト内の結果を絞り込みます。

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

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

• 編集: カスタムトレンドの構成詳細を表示し、名前、説明、NQLクエリを変更します。

• タグの管理: 関連するタグを追加または削除します。

• エクスポート: カスタムトレンドをJSON形式でダウンロードして保存します。

• 削除: カスタムトレンドを削除します。

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

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

1. 管理 > カスタムトレンドページの右上にあるインポートボタンをクリックします。

2. 複数のJSONファイルを選択またはドラッグしてハードドライブからインポートします。

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

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

タグ付けによりカスタムトレンドを効率的に整理し、データを迅速かつ簡単にナビゲートできるようにします。

右側パネルでタグを開きます。

• パネル上部にある指定したタグを検索します。

• カスタムトレンドテーブルをフィルタリングするために1つ以上のタグを選択します。

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

1. カスタムトレンドにカーソルを合わせてアクションメニューを表示し、タグの管理を選択します。

2. タグの管理ポップアップから：

   • 新しいタグを入力するか、既存のものを選択してカスタムトレンドに追加します。

   • 特定のタグアイテムのアクションメニューを開いてタグの削除やタグの色を変更します。

     • タグを削除しても、それが関連付けられているカスタムトレンドからのみ削除されます。

3. 必要に応じて複数のカスタムトレンドを選択してタグの管理をまとめて行います。

カスタムトレンドの作成

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

1. カスタムトレンドページの右上隅にある新しいカスタムトレンドボタンをクリックします。

2. カスタムトレンド設定ページに名前と詳細を入力します。

3. 必要に応じて、NQLの一意の識別子であるクエリIDを調整します。

4. 他の人がこのトレンドデータの意味と目的を理解するための任意の説明を入力します。

5. Nexthinkプラットフォームが日々のスナップショット評価中に実行するNQLクエリを記述します。

カスタムトレンドを保存した後は、NQLクエリやクエリIDの値を変更することはできません。

カスタムトレンド用NQLクエリの作成

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

• クエリはdevices名前空間を対象とする必要があります。

• devicesに許可されている時間間隔は過去1日のうちとなります。 この時間間隔を省略してシステムに登録されているすべてのデバイスを対象にします。

• クエリは最大で2つのincludeおよびcompute句を含む必要があります。

• イベントコレクションのinclude句の後に許可される唯一の時間間隔は過去1日のうちとなります。 オブジェクトコレクションを時間間隔を指定せずに含めることができます。

• Nexthinkは、compute句の結果に適用したときにwhere句を許可しません。

• クエリには、デバイス名、従業員のメールアドレスなどの個人識別情報（PII）を含めることはできません。

• クエリは、最大2つのメトリクス（数値）と最大5つのプロパティ（文字列、列挙型、またはブール値）を含むlist句で終わる必要があります。

• システムはas(), sort, limit, summarize, countif(), sumif(), またはwithキーワードを許可しません。

日時メトリクスの制限

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

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

• オペレーティングシステムプラットフォーム

• オペレーティングシステム名

• 場所（国、州、ロケーションタイプ）

• 組織（エンティティ、カスタム組織）

カスタムトレンドデータに含まれるデバイスの理解

カスタムトレンドの定義において、デバイスの活動に基づいたデバイスセットを指定できます。

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

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

• スナップショットが撮影された日中にアクティブであったデバイスでスナップショットを保存するには、カスタムトレンドの定義でdevicesの後に過去1日のうちを追加します。

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

デバイスの時間枠を指定しなかった場合、同じ期間の運用データとトレンドデータを比較すると若干の不一致を予期する可能性があります。

データ保持の受諾

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

• 新しいカスタムトレンドを保存するには[保存]ボタンをクリックします。

カスタムトレンドの使用

カスタムトレンドを保存した後、NQLで新しいトレンドデータをクエリできます。 最初に、カスタムトレンド定義が保存された日の3日前からのデータのみがクエリで返されます。 これにより、設定したカスタムトレンドが期待される形式でデータを返すかどうかを検証できます。

最初のデータは3日前から計算されますが、デバイスのコンテキスト情報は当日のみが含まれます。

システムは夜間に追加のスナップショットを保存します。 スナップショットには、前日の真夜中から計算日の真夜中までのイベントが含まれます（顧客のタイムゾーンで）。

以下は、カスタムトレンド定義で使用される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	関数の括弧 () は省略されます。

上記の例で、devicesテーブルの| list句で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			…

カスタムトレンドデータを調査でクエリしたり、ダッシュボードウィジェットを作成して、タイムライン上でトレンドを監視することができます。 カスタムトレンドデータを取得するための構文は次のとおりです：

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

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

トレンドの関連

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

hardware_manufacturer などのカスタムトレンドフィールドは、最大13か月の保持期間があります。ただし、関連するデバイスのプロパティはデバイスがシステムに登録されている限り利用可能です。 デバイスを削除または匿名化した場合、またはデバイスが 30 日以上非アクティブである場合、トレンドにはデバイスのプロパティが直接保存されていないため、クエリは "-" を返します。 これは、カスタムトレンドがデフォルトで保存するデバイスコンテキスト情報には適用されず、こちらは 13 ヶ月間保持されます（詳細はカスタムトレンドのための NQL クエリの書き方を参照してください）。

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

カスタムトレンドを効果的に活用するには、トレンドデータをプロットすることがカスタムトレンドの設定とダッシュボードの設計という2つのステッププロセスを含むことを理解することが重要です（詳細な手順についてはライブダッシュボードの管理を参照してください）。

取得したいすべてのメトリックに対してカスタムトレンドを作成する必要があるわけではないことに注意してください。 1 つのカスタムトレンドは、NQL データモデルの拡張として機能し、メトリックや集計のさまざまな組み合わせをクエリすることができます。

カスタムトレンドの設定と取得に関する次の推奨事項を考慮してください。

フィルタと集計は可能な限り取得時に適用する

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

ハードウェアメーカーごとにクラッシュを経験したデバイス数のトレンドラインをプロットしたい場合の例を考えてみます。 いくつかの戦略が考えられますが、すべてが最適ではありません。

最適でない戦略

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

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

最適な戦略

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

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

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

• 少なくとも1つのクラッシュと関連するハードウェアプロバイダーを持つデバイスをフィルタリングします：

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

• または、少なくとも1つのクラッシュがあるデバイスのみを集計し、ハードウェアプロバイダーでさらにグループ化を追加するために条件付き集計を使用します。

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は、予期しない技術的な不具合によって引き起こされるカスタムトレンドデータのギャップを防ぐためのメカニズムを使用しています。 システムが特定の日のスナップショットの計算と保存に失敗した場合、次の日次計算の際に、現在のスナップショットを計算する前に欠落しているデータを計算しようとします。 このメカニズムは過去3日分のデータを復元でき、問題の対処とダッシュボード上のトレンドの継続性を維持するための時間を追加で確保できます。

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

権限

• Nexthink のWebインターフェイスで、 すべてのカスタムトレンドデータを管理する 権限が有効な場合、カスタムトレンドを作成できます。

• NQLでプラットフォームのログを表示する 権限が有効な場合は、platform.custom_trends_logs テーブルにアクセスできます。

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