現代のアプリケーションは、背景サービスやブラウザなどの組み込みコンポーネントのような、いくつかの相互接続されたバイナリで構成されることが多い。 このデザインはパフォーマンスを改善しますが、どのプロセスがどのアプリケーションの一部なのかを理解するのが難しくなります。
これを解決するために、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 のアプリケーション モニター (macOS) Microsoft Teams のタスク マネージャー (Windows) NQL データ モデル フィールド
バイナリのグループ化は、以下のNQLデータモデルフィールドを使用します:
この指標は、イベントに責任のあるアプリケーションのコンテキストを指します。 これは、もはや実行された本当のバイナリである必要はありません。
このメトリックは、同一実行ツリー内のすべてのプロセス(メインプロセスおよびすべてのサブプロセス)が、時間バケット内の実行期間で重み付けされた平均メモリ使用量を示します。
この値は、メインプロセスにのみ利用可能であり、サブプロセスにはNULL
です。
従来のデータはreal_binary
の平均メモリ使用量を報告します。
このメトリックは、イベントをトリガーしたプロセスで実行された実際のバイナリを識別します。
このメトリックは、プロセスの実行時の役割を示します。 可能な値:
このメトリックは、timeバケットの間に同じreal_binary
を実行するすべてのプロセスによって使用される平均メモリを報告します。 値は各プロセスの実行期間に応じて重み付けされます。
プロセスの階層を理解する
システムはランタイム中にメインプロセスを識別して、正しいアプリケーションコンテキストを決定します。 このロジックは、関連するすべての実行および接続イベントに対する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クエリを提供します。
Microsoft Teams実行中にクラッシュやフリーズが発生するデバイスはどれですか?このクエリは、WindowsとmacOSの両方でアプリケーションコンテキスト(binary
)に基づいて、Microsoft Teamsに関連するクラッシュ数を返します。 ダッシュボードで使用したり、カスタムトレンドを定義したりできます。 カスタムトレンド管理 ドキュメントをご覧ください。
Copy 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
クエリは以下のテーブルを返します。
msedgewebview2.exe がフリーズする場合、どのアプリケーションに影響がありますか?このクエリは、どのアプリケーション(binary
)がmsedgewebview2.exe
を起動し、過去7日間でそのサブプロセスがどれだけのフリーズを引き起こしたかを特定します。 フリーズイベントをその親アプリケーションに遡って追跡するのに役立ち、バイナリの改善されたグループ化を使用します。
Copy 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のデータ使用量が最も多いエンドポイントを特定するのに役立ちます。
Copy 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()
クエリは次のテーブルを返します。
構文的には有効でも、結果が誤解を招く可能性があります:
where
句はreal_binary
がmsedgewebview2.exe
であるイベントをフィルタリングします。
しかし、binaries
とexecution.events
間の結合は引き続きbinary
関連付けを使用して行われます。
その結果、計算された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
にアクセスしようとすると、クエリコンテキストで利用できないため、エラーが発生します。