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