収集・保存されるデータ
データカテゴリー
Nexthinkは、オブジェクトとイベントという2種類のデータを区別します。
オブジェクト
インベントリオブジェクト
インベントリーオブジェクトは、デジタル環境に関連する物理的または仮想的なアイテムを表します。 オブジェクトには、一度キャプチャされるとほとんど変化しない要素が含まれます。
バイナリー
（例：名前、サイズ、バージョン、 …）
ユーザー
（例：名前、ユーザー名、部門、 …）
device
（例：名前、CPU、OS、 …）
…
…
構成オブジェクト
構成オブジェクトは、警告、アプリケーション、キャンペーン、リモートアクションなど、Nexthinkユーザーが構成するすべてのオブジェクトを指します。
モニター
（例：名前、しきい値、優先度、 …）
キャンペーン
（例：名前、ステータス、トリガー_方法）
リモート_アクション
（例：名前、 …）
…
…
イベント
イベントの主な特性は、それが時間にリンクされていることです。 言い換えれば、イベントはIT環境内で特定の時点で発生した何かを表します。たとえば、execution.events、web.errorsなどです。
イベントデータはさまざまな目的に役立ちますが、主な違いは運用利用と傾向観察にあります。
運用データ
運用データを使用して、特定の問題を検出し、診断し、解決します。 これには、従業員のデバイスからキャプチャされたライブイベントと、モニターによってトリガーされたアラートが含まれます。
コンテンツセクションには、以下のようなものがあります。
execution.eventsexecution.crashesdevice_performance.eventsremote_action.executionsalert.alerts
運用データは、詳細で広範です。 Nexthinkは、このデータを最大で30日間保存します。 さまざまなNexthinkモジュールを通じて運用データにアクセスし、ドリルダウン機能を使用して調査で表示します。 あるいは、調査に直接アクセスし、ビジュアルエディターを使用するか、NQLクエリを作成して運用データを取得します。
トレンド
トレンドを使用すると、長期間にわたるメトリクスの変動を分析してパターンを観察し、戦略的な決定をサポートできます。 トレンドは、あまり詳細ではなく、最大13か月間保存されます。 これらは、運用イベントデータを1日または7日のサンプル単位で集計し、重要なメトリクスやプロパティに凝縮したものです。
さまざまなNexthinkモジュールは、デフォルトでトレンドデータを保存します。 モジュールのコンテンツを構成し、関連する運用データを十分な期間収集した後にトレンドを観察します。
コンテンツセクションには、以下のようなものがあります。
ソフトウェアメータリングモジュールでは、最大90日間のデータを表示します。 調査でこのデータをクエリすることもできます：
software_metering.events。リモートアクションモジュールでは、最大13か月間のデータを表示し、調査でこのデータをクエリします：
remote_action.executions_summary。アプリケーションモジュールでは、特定のアプリケーションのデータを最大90日間表示します。
デジタルエクスペリエンスモジュールでは、最大13か月間のDEXスコアを表示します（このページの計算済みメトリクスも参照してください）。
長期的なデータを捉えるカスタムトレンドを作成し、調査でクエリし、貴重な洞察を得るためにダッシュボードを作成します。 詳細については、カスタムトレンドの管理のドキュメントページを参照してください。
イベント収集の種類
イベント収集には、即時型とサンプリング型の 2 種類があります。
即時イベント
即時イベントは、発生した瞬間の出来事を反映します。 これには、クラッシュ、起動、ログインが含まれます。
execution.crash
バイナリのクラッシュ
user, device, binary
time, binary_path
cardinality
session.login
デバイスでのユーザーログイン
user, device
time, session_uid
time_until_desktop_ready, time_until_desktop_visible
device_performance.boot
デバイスの起動
device
time, type
boot_duration
…
…
…
…
…
サンプリングイベント
サンプリングイベントとは、継続的かつ長期的な活動に関連する動的メトリクスを監視するために不可欠なデータ収集方法を指します。 これは、CPU 使用率、メモリ使用量、プロセストラフィックなど、絶えず変動し、正確なデータ表現には定期的なサンプリングと集計が必要となるメトリクスに特に重要です。
Collector のサンプリングプロセスは 20〜30 秒ごとに頻繁に行われ、高解像度のデータが得られます。 その後、このデータは集計されたタイムスライスに構造化されます。タイムスライスの長さは、データ収集の特定の要件に応じて、5 分または 15 分の場合があります。 これらのタイムスライスにより、データの分析が容易になります。
session.events
デバイスが Nexthink に報告しているタイミングを示すサンプル
ユーザー、デバイス
protocol、session_ID、…
RTT、latency、interaction_time、…
execution.events
消費リソースを伴うプロセスの実行
ユーザー、デバイス、バイナリ
CPU_time、outgoing_traffic、memory_used、…
device_performance.events
デバイスによって消費されるリソース
device
CPU_usage、read_operation_per_second、used_memory、…
…
…
…
…
…
リソース使用率指標
サンプリングされたイベントは、CPU、GPU、NPU の使用量などの動的なメトリクスを時間の経過とともに取得します。 これらのメトリクスは、分析を容易にするために時間バケット（たとえば、5 分または 15 分間隔）に集計されます。
各時間バケット内のリソースの動作をより包括的に把握できるよう、Nexthink は CPU、GPU、NPU リソース向けに複数種類の使用率メトリクスを提供しています：
平均使用量（
*.avg）: 時間バケット内の典型的な使用率レベルを表します。 このメトリクスを使用して、通常の動作条件を把握します。時間（総消費量）: 時間バケット内で消費されたリソースの総量を表します。 このメトリクスを使用して、アプリケーションおよびデバイス間のリソース需要を比較します。
さまざまなレベルで：
アプリケーションレベル: 特定のバイナリが消費したコンピューティングリソースの量を示します
デバイスレベル: デバイス上のコンピューティングリソースの総使用量を示します
最大使用量（
max_*）: 時間バケット内で観測された最高使用率を表します。 このメトリクスを使用して、平均値では確認できない可能性がある短時間のスパイクを特定します。高使用量の継続時間（
duration_with_high_*）: 時間バケット内で、使用率があらかじめ定義された高使用量のしきい値を超えた合計時間（秒）を測定します。 このメトリクスを使用して、リソース負荷が持続している期間を検出します。
各メトリクスは、リソースの動作に関する異なる視点を提供します：
平均使用量が答える質問: 典型的な負荷はどの程度か?
時間が答える質問：最も多く消費しているのは誰か？ 需要はどのように比較されるか?
最大使用量が答える質問: スパイクはどの程度高かったか?
高使用量の継続時間が答える質問: 負荷状態はどのくらい続いたか?
これらのメトリクスを組み合わせることで、次の事項を区別できます：
高消費のワークロードと低消費のワークロード。
最大値は高いが継続時間が短い短時間のスパイク。
継続時間が長い持続的な負荷。
これらのメトリクスは CPU、GPU、NPU 全体で一貫したモデルに従うため、異なる処理ユニットを比較分析できます。
サンプリングされたイベントの集約
集計時に、システムは類似したイベントをマージし、データ型に応じて異なる関数（合計、平均、パーセンタイルなど）を使用してそのメトリクスを組み合わせます。 Nexthink は、データポイントの値を維持するために最も意味のある集計関数を選択します。
たとえば、outgoing_traffic は合計され、connection_etablishment_time は平均化されます。
例 1 - 複数のプロセス
同じデバイス上で同じユーザーにより、3 つのプロセスで実行されている chrome.exe について考えてみましょう。
08:00 - 08:12
chrome.exe
15 MB
6ms
08:05 - 08:12
chrome.exe
5 MB
10ms
08:10 - 08:14
chrome.exe
10 MB
20ms
データは集計され、08:00 に開始して 08:15 に終了する 15 分間のサンプリングイベントとして保存されます
08:00
08:15
chrome.exe
30 MB (15 + 5 + 10)
12ms ( (6 + 10 + 20) / 3 )
次のように NQL でクエリを実行します：
例 2 - デバイス CPU
特定のデバイスの cpu_usage を保存するため、Nexthink Collector は 30 秒ごとに CPU 負荷をサンプリングします。
08:00:00
80%
08:00:30
55%
08:01:00
75%
…
…
08:04:00
90%
08:04:30
95%
08:00 から 08:05 まで稼働しているデバイスでは、10 個のサンプルが生成されて Nexthink インスタンスに送信され、そこで新しい値に集計されます。
08:00
08:05
82% (80 + 55 + 75 + … + 90 + 95) / 10
次のように NQL でクエリを実行します：
集計により、システムはインサイトを生成する能力を損なうことなく、長期間にわたってデータを保存し、迅速に取得できます。
事前計算済みメトリクス
現在 DEX スコアの計算に使用されている事前計算済みメトリクスは、過去 7 日間のデータに基づいています。 DEX スコアは、7 日間全体のデータを考慮する一方で、毎日計算され、計算時刻に対応するポイントイベントとしてデータベースに保存されます。
過去 7 日間のデータに基づいて本日計算された DEX スコア値を取得するには、dex.scores during past 24h を使用します。
例
貴社では、2024 年 6 月 1 日に、ワークフローを使用した SharePoint の問題の自動修復を導入しました。 修復の開始後に発生したイベントのみを含むアプリケーション DEX スコアを取得するには、2024 年 6 月 8 日以降のスコアをクエリします：
Nexthink の使用状況データ
Nexthink は、IT 担当者の推測に依存せず、製品およびアカウントロールごとの使用アクティビティを測定するために、usage.account_actions NQL テーブルを通じてプラットフォームテレメトリを公開しています。
このプラットフォーム使用状況データセットでは、次のことができます：
使用されているモジュールと機能を追跡する
使用状況の傾向を経時的に測定する
有効化のギャップを検出する
ロール間で使用状況を比較する
ROI の導入状況追跡イニシアチブを支援する。
Nexthink の使用状況テレメトリをクエリするには、Nexthink の使用状況へのデータモデルの可視性を持つユーザーロールが必要です。 ロール を参照してください。
プラットフォームの usage データは、調査やライブダッシュボードなど、NQL をサポートするすべての機能で使用できます。
調査から Nexthink 製品全体の使用状況を一覧表示する
Nexthink の使用状況と製品固有の導入状況を一覧表示するには、調査で特定の期間に対して usage.account_actions NQL テーブルをクエリします。 以下のクエリと画像を参照してください。
NQL フィールドの詳細については、名前空間使用 を参照してください。
usage.account_actions の調査結果を取得した後：
テーブルのフィールド列を確認またはエクスポートして、Nexthink のモジュールおよび機能が特定のタスクの実行に使用される頻度と、その利用者を確認します。
ロールおよび機能における導入のギャップを探し、IT 組織内で摩擦が大きい可能性のあるプロセスとの相関を確認します。
導入に関する問題がある場合は、Nexthink Learn の学習パス、評価、および認定プログラムを活用するデジタル導入戦略を実施する必要があります。
ライブダッシュボードから Nexthink の使用状況と導入状況を可視化する
Nexthink の使用状況と製品固有の導入状況を可視化するには、ライブダッシュボードでウィジェットを構成し、Nexthink usage.account_actions のカスタム表現を設定します。
次の例では、製品モジュールなどのフィールド別にプラットフォームアカウント数を分類する棒グラフウィジェットを表示します。 NQL フィールドの詳細については、名前空間使用 を参照してください。
棒グラフのクエリ例を参照してください：
usage.account_actions データセットは、Nexthink プラットフォームの導入状況を示します。 セキュリティ関連コンテンツの監査には、代わりに監査ログを使用してください。
usage.account_actions のデータ保持に関する詳細は、データカテゴリごとの保持期間 を参照してください。
例
プラットフォームの usage データは、調査やライブダッシュボードなど、NQL をサポートするすべての機能で使用できます。 以下の例を参照してください。
usage.account_actions NQL データセットのその他のユースケースには、次のものがあります：
動的データモデル
NQL を使用すると、オートコンプリートまたはビジュアルエディターによって提案されるものの、NQL データモデルのドキュメントには記載されていないフィールドが表示される場合があります。 これらのフィールドは動的データモデルの一部であり、組織の環境に適応するために文書化されたデータモデルを拡張します。 動的フィールドは、複数のソースから取得される場合があります。
最終更新
役に立ちましたか？