# バイナリのグループ化 現代のアプリケーションは、背景サービスやブラウザなどの組み込みコンポーネントのような、いくつかの相互接続されたバイナリで構成されることが多い。 このデザインはパフォーマンスを改善しますが、どのプロセスがどのアプリケーションの一部なのかを理解するのが難しくなります。 これを解決するために、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 のオペレーティング システムにおけるこのバイナリの階層を示しています。
Microsoft Teams in Application Monitor (macOS)

Microsoft Teams のアプリケーション モニター (macOS)

Microsoft Teams in Task Manager (Windows)

Microsoft Teams のタスク マネージャー (Windows)

**NQL データ モデル フィールド** バイナリのグループ化は、以下のNQLデータモデルフィールドを使用します:
フィールド名説明
binaryこの指標は、イベントに責任のあるアプリケーションのコンテキストを指します。 これは、もはや実行された本当のバイナリである必要はありません。
memory

このメトリックは、同一実行ツリー内のすべてのプロセス（メインプロセスおよびすべてのサブプロセス）が、時間バケット内の実行期間で重み付けされた平均メモリ使用量を示します。

この値は、メインプロセスにのみ利用可能であり、サブプロセスにはNULLです。

従来のデータはreal_binaryの平均メモリ使用量を報告します。

real_binaryこのメトリックは、イベントをトリガーしたプロセスで実行された実際のバイナリを識別します。
process_hierarchy

このメトリックは、プロセスの実行時の役割を示します。 可能な値:

  • main_process
  • sub_process
  • NULL for legacy data.
real_memoryこのメトリックは、timeバケットの間に同じreal_binaryを実行するすべてのプロセスによって使用される平均メモリを報告します。 値は各プロセスの実行期間に応じて重み付けされます。
{% hint style="info" %} 一貫した分析を確保するために、Nexthinkは高レベルの監視と帰属に`binary`を使用し、プロセスレベルでの詳細な調査には`real_binary`と`real_memory`を使用することを推奨します。 {% endhint %} **プロセスの階層を理解する** システムはランタイム中にメインプロセスを識別して、正しいアプリケーションコンテキストを決定します。 このロジックは、関連するすべての実行および接続イベントに対する`binary`フィールドの値を設定します。 イベントの原因となった実際の実行ファイルは、`real_binary`フィールドに記録されます。 Windowsでは、プロセスが以下の条件のいずれかを満たす場合、メインプロセスとして認定されます。 * プロセスが他のプロセスによって起動されてから30秒以内に可視の前景ウィンドウを開く。 * バイナリが、事前定義された既知のアプリケーション実行ファイルリストに一致する場合： ``` 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クエリを提供します。
Microsoft Teams実行中にクラッシュやフリーズが発生するデバイスはどれですか？ このクエリは、WindowsとmacOSの両方でアプリケーションコンテキスト（`binary`）に基づいて、Microsoft Teamsに関連するクラッシュ数を返します。 ダッシュボードで使用したり、カスタムトレンドを定義したりできます。 [カスタムトレンド管理](https://docs.nexthink.com/platform/ja/user-guide/administration/content-management/custom-trends-management) ドキュメントをご覧ください。 ```sql 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`とバージョンごとのフリーズの総数を要約し、サブプロセスなどアプリケーションの不安定性に寄与するコンポーネントを特定するのに役立ちます。 ```sql 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 ``` クエリは以下のテーブルを返します。
msedgewebview2.exe がフリーズする場合、どのアプリケーションに影響がありますか？ このクエリは、どのアプリケーション（`binary`）が`msedgewebview2.exe`を起動し、過去7日間でそのサブプロセスがどれだけのフリーズを引き起こしたかを特定します。 フリーズイベントをその親アプリケーションに遡って追跡するのに役立ち、バイナリの改善されたグループ化を使用します。 ```sql 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 ```
各デバイスでのMicrosoft Teamsによって生成される受信および送信トラフィックはどれだけですか？ このクエリは、過去7日間にMicrosoft Teamsのトラフィックがあるデバイスのリストを表示します。 各デバイスごとの受信および送信ネットワークトラフィックの合計を示し、Teamsのデータ使用量が最も多いエンドポイントを特定するのに役立ちます。 ```sql 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** 構文的には有効なクエリで、誤解を招く結果をもたらします： ```sql binaries | with execution.events during past 1h | where real_binary.name == "msedgewebview2.exe" | compute cpu_time_ = cpu_time.sum() ``` クエリは次のテーブルを返します。
Table with example
構文的には有効でも、結果が誤解を招く可能性があります： 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** 構文的に無効なクエリ： 
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_
Query example
NQLにおいて、`binaries`コレクションから`execution.events`に結合する際、クエリはデータモデルで定義されたバイナリ関連付けを使用します。 これは、`binaries`が`binary`フィールドを通じて参照される`execution.events`のみをアクセスできることを意味します。 `real_binary`関連付けは、この結合コンテキストで使用できません。 `binaries`が`execution.events`内の`binary`フィールドを通じてのみリンクされているため、`real_binary.name`にアクセスしようとすると、クエリコンテキストで利用できないため、エラーが発生します。