カスタム傾向管理

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

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

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

</div>

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

<figure><img src="../../../../.gitbook/assets/customtrends-1707990723.png" alt="Line chart configuration using a custom trend" width="760"><figcaption></figcaption></figure>

### トレンドの関連付け

トレンドテーブルは`デバイステーブル`と関連付けられています。 トレンドデータを取得する際に、これらの関連を利用して、デバイスの特性をクエリに含めることができます。 ただし、これらの特性はオリジナルのテーブルに保存されている限りのみ利用可能です。 詳細は[データ解像度と保持期間](../../../../getting-started/understanding-key-data-platform-concepts/data-resolution-and-retention.md)ページをご覧ください。

カスタムトレンドフィールド（`hardware_manufacturer`など）には最大13ヶ月の保持期間がありますが、関連付けられたデバイスの特性は、デバイスがシステムに登録されている限り利用可能です。 デバイスを削除または匿名化した場合、またはデバイスが30日以上非アクティブであれば、クエリは「-」を返します。これはデバイス特性がトレンドに直接保存されていないためです。 これは、カスタムトレンドがデフォルトで保存するデバイスコンテキスト情報には該当せず、それも13か月間保持されます（このページで[カスタムトレンド用のNQLクエリの作成]をご覧ください）。

## カスタムトレンドの最適な活用法

カスタムトレンドを効果的に活用するためには、トレンドデータのプロットは、カスタムトレンドの構成とダッシュボード設計という2段階のプロセスを伴うことを理解することが重要です（詳細な指示については[ライブダッシュボードの管理](../../../live-dashboards/managing-live-dashboards.md)を参照してください）。

すべての追跡したい指標に対して個別のカスタムトレンドを作成する必要はないことに注意することが重要です。 単一のカスタムトレンドはNQLデータモデルの拡張として機能し、さまざまな指標と集計の組み合わせを用いて長期データをクエリすることができます。

カスタムトレンドの構成および取得に関する以下の推奨事項を検討してください：

<details>

<summary>可能であれば、取得時にフィルターおよび集計を適用する</summary>

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

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

**非最適戦略**

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

<div data-gb-custom-block data-tag="code" data-lineNumbers='true'>

</div>

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

<div data-gb-custom-block data-tag="code" data-lineNumbers='true'>

</div>

**最適戦略**

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

<div data-gb-custom-block data-tag="code" data-lineNumbers='true'>

</div>

カスタムトレンドデータの取得時：

 - 少なくとも1回のクラッシュを持ち、関連するハードウェアプロバイダーを持つデバイスをフィルター：

<div data-gb-custom-block data-tag="code" data-lineNumbers='true'>

</div>

 - あるいは、条件付き集計を使用して、1回以上のクラッシュを持つデバイスのみを要約し、ハードウェアプロバイダーごとに追加のグループ化を行う：

<div data-gb-custom-block data-tag="code" data-lineNumbers='true'>

</div>

</details>

<details>

<summary>二重集計を思慮深く使用する</summary>

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

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

<div data-gb-custom-block data-tag="code" data-lineNumbers='true'>

</div>

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

<div data-gb-custom-block data-tag="code" data-lineNumbers='true'>

</div>

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

</details>

## スナップショット失敗のトラブルシューティング<a href="#troubleshooting-snapshot-failures" id="troubleshooting-snapshot-failures"></a>

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

スナップショット計算はさまざまな理由で失敗する可能性があります。たとえば、[カスタムフィールド](../custom-fields-management.md) や [組織構造](../../system-configuration/product-configuration.md#organization) のような動的データモデルの変更による不正確なカスタムトレンドNQLクエリ定義が原因であったり、システムの一時的な障害が原因であったりします。 失敗は不完全なカスタムトレンドデータの結果となる場合があります。 これらの失敗を理解することは、問題を迅速に解決し、ダッシュボードに表示されるデータの問題に対して視認性を向上するために重要です。

システムは、`platform.custom_trends_logs` テーブル内にカスタムトレンド計算の各詳細、例えば計算時間、ステータス、カスタムトレンドNQL IDなどを保存します。 特定のカスタムトレンド計算の失敗原因を調査するために、以下のNQLクエリを使用してください：

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

<figure><img src="../../../../.gitbook/assets/custom_trend_alert.png" alt=""><figcaption></figcaption></figure>

詳細については、[カスタムモニターの作成](../../../alerts-and-diagnostics/managing-alerts/creating-custom-monitors/) ページを参照してください。

#### トレンドバックフィル

Nexthinkでは、予期せぬ技術的な障害により発生したカスタムトレンドデータのギャップを防ぐメカニズムを使用しています。 システムが特定の日のスナップショットを計算し保存することに失敗した場合、翌日の計算時に、現在のスナップショットを計算する前に、欠けているデータを計算することが試みられます。 このメカニズムは過去3日間のデータを復旧でき、問題に対処してダッシュボード上でトレンドの連続性を維持するための時間を追加で提供します。

<div data-gb-custom-block data-tag="hint" data-style='info'>

過去の日数から計算されたデータは、現在の日付のデバイスコンテキスト情報のみを含みます。

</div>

## アクセス権限 <a href="#customtrendsmanagement-permissionspermissions" id="customtrendsmanagement-permissionspermissions"></a>

 - Nexthinkのウェブインターフェースで、ユーザー役割に**すべてのカスタムトレンドデータを管理する**権限がある場合、カスタムトレンドを作成できます。&#x20;
 - ユーザー役割にNQLでプラットフォームログの**閲覧権限**がある場合、`platform.custom_trends_logs`テーブルにアクセスできます。

詳細については、[役割](../../account-management/roles/)のドキュメントをご参照ください。