収集および保存するデータ

データカテゴリ

Nexthinkでは、データをオブジェクトとイベントの2種類に分類します。

オブジェクト

インベントリオブジェクト

インベントリオブジェクトは、デジタル環境に関連する物理的または仮想的なアイテムを表します。 オブジェクトには一度取得されるとほとんど変化しない要素が含まれています。 &#x20

オブジェクト	プロパティ
binary	name, size, version, …
user	name, username, department, …
device	name, CPU, OS, …
…	…

設定オブジェクト

設定オブジェクトは、Nexthinkユーザーが設定するすべてのオブジェクトを指し、例えばアラート、アプリケーション、キャンペーン、リモートアクションなどです。

オブジェクト	プロパティ
monitors	name, threshold, priority, …
campaigns	name, status, trigger_method
remote_actions	name, …
…	…

イベント

イベントの主な特徴は、時間依存であることです。 言い換えれば、イベントはIT環境内で特定の時間に発生した出来事を表します。例えば、execution.events、web.errorsなどです。

イベントデータは、その用途に応じて様々な目的に役立ちますが、主要な区別は運用利用とトレンド観察です。

運用データ

運用データを使用して、特定の問題を検出、診断、解決します。 これには、従業員のデバイスから取得されたライブイベントや、モニターによってトリガーされたアラートが含まれます。

例：

• execution.events

• execution.crashes

• device_performance.events

• remote_action.executions

• alert.alerts

運用データは粒度が高く、広範です。 Nexthinkはこのデータを最大30日間保存します。 Nexthinkのさまざまなモジュールを通じて運用データにアクセスし、ドリルダウン機能を使用して調査でデータを表示します。 あるいは、調査に直接アクセスし、ビジュアルエディターを使用するか、NQLクエリを作成して運用データを取得します。

トレンド

トレンドは、長期にわたるメトリクスの変化を分析し、パターンを観察して戦略的な意思決定をサポートするのに役立ちます。 トレンドは粒度が低く、最大13ヶ月間保存されます。 トレンドには、一日のサンプルまたは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に報告していることを示すサンプル	user, device	protocol, session_ID, …	RTT, latency, interaction_time, …
execution.events	リソースを消費するプロセスの実行	user, device, binary		CPU_time, outgoing_traffic, memory_used, …
device_performance.events	デバイスが消費するリソース	device		CPU_usage, read_operation_per_second, used_memory, …
…	…	…	…	…

サンプリングイベントの集約

集約中、システムは類似のイベントを結合し、データタイプに応じて異なる関数（合計、平均、百分位数など）を使用してメトリクスを組み合わせます。 Nexthinkはデータポイントの価値を保つために最も意味のある集計関数を選びます。

例えば、outgoing_trafficは合計され、connection_etablishment_timeは平均されます。

例1 - 複数のプロセス

同じデバイスで同じユーザーがchrome.exeを実行しているが、3つのプロセスがあると考えます。

time	binary.name	outgoing_traffic	connection_establishment_time.avg
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分のサンプリングイベントとして集約されて保存されます

start_time	end_time	binary.name	outgoing_traffic	connection_establishment_time.avg
08:00	08:15	chrome.exe	30 MB (15 + 5 + 10)	12ms ( (6 + 10 + 20) / 3 )

NQLで次のようにクエリします：

|

execution.events during past 15min
| where binary.name == "chrome.exe"
| list start_time, end_time , outgoing_traffic, connection_establishment_time.avg







例2 - デバイスCPU
特定のデバイスのcpu_usageを保存するために、Nexthink Collectorは30秒ごとにCPU負荷のサンプルを取ります。


































08:00から08:05まで実行されているデバイスに対して、10個のサンプルが生成され、それがNexthinkインスタンスに送信されて新しい値に集約されます。
















NQLを使用して、次の方法でクエリを行います：
| device_performance.events during past 5min| list start_time, end_time, cpu_usage.avg集約は、システムが長期間のデータを保存し、それを迅速に取得することを可能にし、洞察を生成する能力を損なうことはありません。事前計算されたメトリクス現在、DEXスコアの計算で使用されている事前計算されたメトリクスは、過去7日間のデータに基づいています。 DEXスコアは毎日計算され、7日間のデータを考慮に入れているものの、計算時点の特定のイベントとしてデータベースに保存されます。今日計算されたDEXスコアの値を取得するには、過去7日間のデータに基づいて、次のように使用します： dex.scores during past 24h。例あなたの会社は、2024年6月1日にWorkflowsを使用してSharePointの問題の自動修正を導入しました。 修正後に発生したイベントのみを含むアプリケーションDEXスコアを取得するには、2024年6月8日以降にスコアをクエリし始めてください：users| include dex.application_scores on Jul 8, 2024| where application.name in ["Sharepoint"] and node.type == application| compute sharepoint_score_per_user = node.value.avg()| summarize sharepoint_score = sharepoint_score_per_user.avg()