バイナリグループ化

現代のアプリケーションは、背景サービスやブラウザなどの組み込みコンポーネントのような、いくつかの相互接続されたバイナリで構成されることが多い。 このデザインはパフォーマンスを改善しますが、どのプロセスがどのアプリケーションの一部なのかを理解するのが難しくなります。

これを解決するために、Nexthink は実行および接続イベントにおけるバイナリデータを追跡する特定の方法を実装しており、2つの明確なフィールドを使用します。

• binary は監視、帰属、およびレポート作成のためのアプリケーションレベルのコンテキストを示します。

• real_binary はイベントやプロセス中に実際に実行された実行可能ファイルを示します。

このアプローチはランタイム中のみ適用されます。Nexthink インスタンスのバイナリテーブルには反映されません。 各イベントが発生するたびに binary と real_binary のリンクが計算されます。

アプリケーションのコンテキストをプロセスの実行から分離することにより、Nexthink はより明確で正確な洞察を提供します。 これにより、IT チームはリソースの利用状況をよりよく追跡し、問題を診断し、正しいアプリケーションコンテキスト内でのネットワーク挙動を理解できます。

実際のバイナリグループ化

バイナリのグループ化がどのように機能するかを示すために、このセクションでは Microsoft Teams を例に使用します。 このアプリケーションには、バックグラウンド サービスや、組み込みブラウザである WebView などの共有コンポーネントといった複数のバイナリが含まれています。

Microsoft Teams が msedgewebview2.exe のようなヘルパー プロセスを起動すると、実行データには次のように表示されます。

• binary.name = ms-teams.exe は、アプリケーションのメインまたは親バイナリです。

• real_binary.name = msedgewebview2.exe は、実際に実行されたバイナリです。

以下の図は、macOS と Windows のオペレーティング システムにおけるこのバイナリの階層を示しています。

NQL データ モデル フィールド

バイナリのグループ化は、以下のNQLデータモデルフィールドを使用します:

プロセスの階層を理解する

システムはランタイム中にメインプロセスを識別して、正しいアプリケーションコンテキストを決定します。 このロジックは、関連するすべての実行および接続イベントに対するbinaryフィールドの値を設定します。 イベントの原因となった実際の実行ファイルは、real_binaryフィールドに記録されます。

Windowsでは、プロセスが以下の条件のいずれかを満たす場合、メインプロセスとして認定されます。

• プロセスが他のプロセスによって起動されてから30秒以内に可視の前景ウィンドウを開く。

• バイナリが、事前定義された既知のアプリケーション実行ファイルリストに一致する場合：

  Copy

  ```
  ms-teams.exe, msteams.exe, outlook.exe, olk.exe, widgets.exe,
  widgetboard.exe, onedrive.exe, powerpnt.exe, excel.exe, onenote.exe,
  winword.exe, msedge.exe, pad.console.host.exe, searchapp.exe,
  pbidesktop.exe, bingwallpaper.exe, zoom.exe, acrobat.exe,
  firefox.exe, chrome.exe
  ```

• プロセスがシステムランチャー、例えば explorer.exe, svchost.exe, またはwininit.exeによって開始された場合、あるいは有効な親プロセスが特定できない場合。

起動から3秒後に検出が始まり、可視化データを収集するために最大30秒間続行されます。 これらの条件がどれも適用されない場合、プロセスは独自のメインプロセスとして扱われます。

macOSでは、ユーザーとの対話と権限の処理に責任を持つプロセスをシステムが指定します。 Nexthinkは、この責任を持つプロセスを帰属のためのメインプロセスとして使用し、イベントがどのサブプロセスによって生成されたかにかかわらず使用します。

バイナリ実行メトリクスの使用方法

各executionおよびconnectionイベントには、2つの関連付けがあります：

• binary、アプリケーションのコンテキストを表し、例: teams.exe

• real_binary、実際に実行された実行可能ファイル、例: msedgewebview2.exe

バイナリ関連のメトリクス、例えばcpu_time, number_of_crashes, number_of_freezes, incoming_traffic 、またはoutgoing_trafficはreal_binaryレベルで記録され、必要な範囲によって標準的な関数を使用しbinary または real_binaryで集計できます。

メモリメトリクスは、その複雑さ故に異なる方法で扱われます。 プロセスごとに合計されたり、平均されたりする代わりに、メモリ使用量は各時間バケット内の加重平均として計算されます。 各バケットは、同じバイナリを実行しているすべてのプロセスをグループ化し、各プロセスの実行時間を重みとしてメモリ値を平均化します。

プロセスレベルとアプリケーションレベルの両方の可視性を提供するために、2つの異なるフィールドが用意されています：

• **real_memory**は、同じreal_binaryの下で、時間バケット内で各プロセスによって使用されたメモリを反映します。 正確なプロセスレベルでのリソース使用状況を提供します。

• **memory**は、実行ツリー全体のメモリの総フットプリントをキャプチャし、process_hierarchy == main_processの場合にのみ利用できます。 同じ実行ツリー内のすべての関連プロセスを対象に、加重平均として計算されます。

新しいモデルでのデータの解釈 - Microsoft Teams

このセクションでは、Microsoft Teamsの実行、接続、リソース使用データを調査するための即使用可能なNQLクエリを提供します。

devices
| include execution.crashes during past 24h
| where binary.name in ["ms-teams.exe", "msteams"]
| compute number_of_crashes_ = crash.number_of_crashes.sum()
| include execution.events during past 24h
| where binary.name in ["ms-teams.exe", "msteams"]
| compute number_of_freezes_ = number_of_freezes.sum()
| where number_of_crashes_ > 0 or number_of_freezes_ > 0
| list device.name, number_of_crashes_, number_of_freezes_

Microsoft Teamsがフリーズした場合、どのバイナリが責任を持っていますか？

このクエリは、過去7日間でフリーズを報告したMicrosoft Teamsで使用されるリアルバイナリを示します。 real_binaryとバージョンごとのフリーズの総数を要約し、サブプロセスなどアプリケーションの不安定性に寄与するコンポーネントを特定するのに役立ちます。

Copy

execution.events during past 7d
| where binary.name in ["ms-teams.exe", "msteams"]
| summarize number_of_freezes_ = number_of_freezes.sum() by binary.name, real_binary.name, real_binary.version
| where number_of_freezes_ > 0
| list binary.name, real_binary.name, real_binary.version, number_of_freezes_
| sort real_binary.name asc

クエリは以下のテーブルを返します。

execution.events during past 7d
| where real_binary.name in ["msedgewebview2.exe"]
| summarize number_of_freezes_ = number_of_freezes.sum() by binary.name, real_binary.name
| list binary.name, real_binary.name, number_of_freezes_
| sort number_of_freezes_ desc

devices
| include connection.events during past 7d
| where binary.name in ["ms-teams.exe", "msteams"]
| compute incomming_traffic_ = incoming_traffic.sum(), outgoing_traffic_ = outgoing_traffic.sum()
| list device.name, incomming_traffic_, outgoing_traffic_
| sort outgoing_traffic_ desc

withとincludeのためのNQLクエリの制限事項は何ですか？

各実行および接続イベントには、2つの関連付けが含まれます:

• binary、アプリケーションのコンテキストを表す、例：teams.exe

• real_binary、実際に実行された実行可能ファイル、例：msedgewebview2.exe

イベントテーブル、例えば execution.events または connection.events と binaries テーブルを結合するとき、NQLは**binary**関連付けのみを使用します。 NQLは、2つのテーブル間の単一の結合パスをサポートし、そのパスはreal_binaryではなく、binaryフィールドに基づいています。

実際のシナリオを使用した説明のために、以下の例をご覧ください。

例 1

構文的には有効なクエリで、誤解を招く結果をもたらします：

Copy

binaries 
| with execution.events during past 1h
| where real_binary.name == "msedgewebview2.exe" 
| compute cpu_time_ = cpu_time.sum() 

クエリは次のテーブルを返します。

構文的には有効でも、結果が誤解を招く可能性があります：

1. where句はreal_binaryがmsedgewebview2.exeであるイベントをフィルタリングします。

2. しかし、binariesとexecution.events間の結合は引き続きbinary関連付けを使用して行われます。

3. その結果、計算されたcpu_time_はmsedgewebview2.exeからのリソース使用量のみを反映していますが、teams.exeやoutlook.exeなどの親バイナリの下にグループ化され、混乱を招く可能性があります。

このような部分的帰属をダッシュボードやレポートで使用すると、誤った結論に導く可能性があります。 real_binaryでフィルタリングする際は、親コンテキスト下のreal_binary活動を要約する意図がない限り、binary関連付けを使用して結果を集計または表示しないようにしてください。

例 2

構文的に無効なクエリ：

Copy

binaries
| with execution.events during past 1h
| where real_binary.name == "msedgewebview2.exe"
| compute cpu_time_ = cpu_time.sum()
| list binary.name, real_binary.name, cpu_time_

NQLにおいて、binariesコレクションからexecution.eventsに結合する際、クエリはデータモデルで定義されたバイナリ関連付けを使用します。 これは、binariesがbinaryフィールドを通じて参照されるexecution.eventsのみをアクセスできることを意味します。

real_binary関連付けは、この結合コンテキストで使用できません。 binariesがexecution.events内のbinaryフィールドを通じてのみリンクされているため、real_binary.nameにアクセスしようとすると、クエリコンテキストで利用できないため、エラーが発生します。