dotnet-trace-collect

.NET Trace Collect

このスキルは、環境に適した診断ツールを推奨し、データ収集を案内し、分析方法を提案することで、開発者による本番環境のパフォーマンス問題の診断を支援します。コードのアンチパターンを分析したり、分析そのものを実行したりはしません。

使用する場合

• 開発者が本番環境のパフォーマンス問題（CPU 使用率の高さ、メモリリーク、リクエストの遅延、過剰な GC、ネットワークエラーなど）を調査する必要がある場合
• 特定のランタイム、OS、デプロイ構成に適した診断ツールを選ぶ場合
• データ収集用の診断ツールのコマンドを設定して実行する場合
• 利用可能なツール間のトレードオフ（例：PerfView と dotnet-trace）を把握する場合
• コンテナー化されたワークロードや Kubernetes のワークロードから診断データを収集する場合

使用しない場合

• パフォーマンスのアンチパターンについてソースコードをレビューする場合（代わりにコードレビュースキルを使用してください）
• 開発中にベンチマークを実施する場合（例：BenchmarkDotNet の設定）
• 収集済みのトレースファイルやダンプファイルを分析する場合（このスキルは分析用のツールを推奨しますが、分析は実行しません）

入力

入力	必須	説明
症状	はい	開発者が確認している現象（CPU 使用率の高さ、メモリの増加、リクエストの遅延、ハング、過剰な GC、HTTP 5xx エラー、ネットワークのタイムアウト、接続の失敗、アセンブリの読み込み失敗など）
ランタイム	はい	.NET Framework または最新の .NET（バージョンも指定。特に .NET 10 以降かどうか）
OS	はい	Windows または Linux
デプロイ	はい	コンテナーを使用しない環境、コンテナー、または Kubernetes
管理者権限	推奨	対象マシンで開発者が管理者／root アクセス権を持っているかどうか
再現のしやすさ	推奨	問題を簡単に再現できるか、または発生するまでに長い時間がかかるか

ワークフロー

ステップ 1：環境を把握する

次の点を確認するか、開発者に明確にするよう依頼してください。

1. 症状：確認している現象（CPU 使用率の高さ、メモリリーク、リクエストの遅延、ハング、過剰な GC、HTTP 5xx エラー、ネットワークのタイムアウト、接続の失敗、アセンブリの読み込み失敗など）
2. ランタイム：.NET Framework と最新の .NET のどちらですか？最新の .NET の場合は、バージョンはいくつですか？（特に .NET 10 以降かどうか）
3. OS：Windows と Linux のどちらですか？
4. デプロイ：ホスト上で直接実行していますか、コンテナー内ですか、それとも Kubernetes 上ですか？
5. 管理者権限：対象マシンまたはコンテナーで管理者／root アクセス権を持っていますか？
6. 再現のしやすさ：問題はすぐに再現しますか、それとも発生するまでに長い時間がかかりますか？
7. ワークロードのコンテキスト：ワークロードのコンテキスト内で実行しているか（つまり、問題が発生している同じマシン上、または同じ環境に接続した状態か）を確認するか、ユーザーに尋ねてください。そうであれば、ユーザーに代わって診断コマンドを直接実行できます。そうでない場合は、ユーザー自身が実行するためのコマンドを案内してください。

この情報を使用して、ステップ 2 で適切なツールを選択してください。

ステップ 2：診断ツールを推奨する

以下の優先順位に従い、環境に応じてツールを選択してください。ツールを選択したら、詳細なコマンドラインの使用方法を確認するため、対応するリファレンスファイルを読み込んでください。

ツールのリファレンス検索

環境	リファレンスファイル
Windows + 最新の .NET + 管理者権限あり	references/perfview.md
Windows + 最新の .NET、管理者権限なし	references/dotnet-trace-collect.md
Windows + .NET Framework	references/perfview.md
Linux + .NET 10 以降 + root	references/dotnet-trace-collect-linux.md
Linux + .NET 10 より前	references/dotnet-trace-collect.md
Linux + ネイティブスタックが必要	references/perfcollect.md
コンテナー／K8s（コンソールアクセスあり）	references/dotnet-trace-collect.md（または dotnet-trace-collect-linux.md）
コンテナー／K8s（コンソールアクセスなし）	references/dotnet-monitor.md

迅速な判断マトリクス（初期トリアージ）

環境	推奨ツール	代替手段／注意事項
Windows + 最新の .NET + 管理者権限あり	PerfView	管理者権限がない場合は、dotnet-trace を使用します
Windows + .NET Framework + 管理者権限あり	PerfView	管理者権限がない場合、トレースの代替手段はありません。ハングやメモリリークの場合は、dump-collect が .NET Framework をサポートしていないため、ダンプコマンド（procdump -ma またはタスクマネージャー）を直接提示します
Linux + .NET 10 以降 + root	dotnet-trace collect-linux	root またはカーネルの前提条件を満たしていない場合は、dotnet-trace を使用します
Linux + .NET 10 未満	dotnet-trace	ネイティブスタックが必要な場合は、perfcollect を追加します（root が必要です）
Linux コンテナー／Kubernetes	ワークロードのコンテキストでコンソールツールを使用します。コンソールにアクセスできない場合は dotnet-monitor を使用します	詳細は「Linux コンテナー／Kubernetes」セクションを参照してください

Windows（コンテナー以外、最新の .NET）

1. PerfView（推奨）— より豊富な ETW ベースのデータを取得できます。管理者権限が必要です。リクエストの処理が遅い場合は、スレッドレベルの待機とブロックの詳細を取得するために /ThreadTime を追加します。
2. dotnet-trace — 管理者権限がない場合の代替手段です。
3. 長時間実行する再現テストには、取得したい症状が発生したときにトリガーされる /StopOn トリガー（例：/StopOnPerfCounter、/StopOnGCEvent、/StopOnException）と、循環バッファー（/CircularMB + /BufferSizeMB）を使って PerfView を使用します。**重要：停止トリガーは、復旧時ではなく、注目するイベントの発生時にトリガーされる必要があります。**循環バッファーは古いデータを継続的に上書きするため、復旧時にトリガーすると、収集が停止するまでに注目する動作がすでに上書きされている可能性があります。開始イベントが停止イベントより先に発生すると分かっている場合に限り、/StartOn を追加します。リクエストの処理が遅い場合は、ユーザーが個別のシナリオに基づいてトリガーを設計できるよう、デフォルトでは停止トリガーを設定しないでください。

Windows コンテナー

1. PerfView — Kubernetes on Windows を含むほとんどの Windows コンテナーでは、デフォルトでプロセス分離が使用されます。ホストから /EnableEventsInContainers を指定してデータを収集します。収集後は、次の 2 つの方法があります。

   • コンテナーの実行中にローカルで分析する — PerfView はライブコンテナーにアクセスしてシンボルを解決できるため、ホストマシン上ですぐにトレースを開けます。
   • 別のマシンで分析する — コンテナーがシャットダウンする前に、.etl.zip をコンテナー内にコピーし、コンテナー内で PerfViewCollect merge /ImageIDsOnly を実行してシンボル情報を埋め込みます。その後、マージしたトレースをコンテナーの外にコピーします。このマージ手順を行わないと、コンテナー内のバイナリのシンボルをほかのマシンで解決できません。

   あまり一般的ではない Hyper-V コンテナーの場合は、コンテナー内で直接データを収集します。詳しいコマンドについては、references/perfview.md を参照してください。

2. dotnet-monitor、dotnet-trace — ツールがイメージにインストールされている場合は、コンテナー内で使用します。ダンプの場合は、dump-collect スキルを実行します。

Windows（.NET Framework）

1. PerfView — Windows 上の .NET Framework における主要な診断ツールです。管理者権限が必要です。
2. 長時間の再現テストでは、同じトリガーに関する指針に従います。/CircularMB + /BufferSizeMB とともに、症状の発生時にトリガーされる /StopOn トリガー（例：/StopOnPerfCounter、/StopOnGCEvent、/StopOnException）を使用します。
3. 管理者権限がない場合：PerfView には管理者権限が必要であり、.NET Framework 向けの代替トレースツールはありません。dump-collect スキルは .NET Framework をサポートしていないため、管理者権限がなくてもプロセスダンプを取得できることを説明し、ダンプコマンド（例：procdump -ma <PID> またはタスクマネージャー）を直接提示します。ダンプはハングやメモリリークの診断に役立ちます。ただし、CPU 使用率が高い場合、リクエストの処理が遅い場合、GC が過剰に発生する場合は、管理者権限なしでは .NET Framework 上で調査する方法がありません。管理者権限を取得するようユーザーに案内してください。

Linux（非コンテナー、.NET 10 以降）

1. dotnet-trace collect-linux（推奨）— perf_events を使用し、ネイティブ呼び出しスタックやカーネルイベントを含む、より詳細なトレースを取得します。既定ではマシン全体を対象とするため、PID は不要です。root 権限とカーネル 6.4 以降が必要です。
2. dotnet-trace — root 権限を利用できない場合、またはカーネル要件を満たしていない場合の代替手段です。マネージドスタックのみを取得します。

Linux（非コンテナー、.NET 10 より前）

1. dotnet-trace（推奨）— マネージドトレースを収集します。管理者権限は不要です。
2. perfcollect — ネイティブ呼び出しスタックが必要な場合に使用します（管理者/root 権限が必要です）。

Linux コンテナー / Kubernetes

ワークロードの実行環境内で作業している場合（つまり、コンテナーのコンソールにアクセスできる場合）は、コンソールベースのツールを優先してください。認証設定とサイドカーのデプロイが必要な dotnet-monitor よりも、セットアップが簡単です。

1. dotnet-trace collect-linux（root 権限を持つ .NET 10 以降）— ネイティブ呼び出しスタックやカーネルイベントを含む、最も詳細なトレースを生成します。
2. dotnet-trace — イメージにツールがインストールされている場合は、コンテナー内で実行します。ダンプについては、dump-collect スキルを呼び出してください。
3. perfcollect — .NET 10 より前の環境でネイティブスタックが必要な場合は、コンテナー内で実行します（SYS_ADMIN / --privileged が必要です）。

ワークロードの実行環境内で作業していない場合（コンソールにアクセスできない場合）、または dotnet-monitor がすでにデプロイされている場合：

1. dotnet-monitor — コンテナー向けに設計されており、サイドカーとして実行します。アプリコンテナーにツールをインストールする必要はありません。コンソールにアクセスできない場合に最も簡単な方法です。

メモリダンプ

ダンプが必要な場合（メモリリーク、ハングなど）、最新の .NET では、ダンプ収集コマンドを直接提示しないでください。代わりに、dump-collect スキルを呼び出してください。dump-collect スキルがサポートするのは最新の .NET（.NET Core 3.0 以降）のみです。.NET Framework の場合は、ダンプ収集の方法を直接案内してください（例：procdump -ma <PID> またはタスク マネージャー）。このスキルはトレース収集のみを対象としています。

メモリリーク

• メモリが増加している間に、ダンプを 2 つ取得してください（例：早い段階で 1 つ、十分に増加した後でもう 1 つ）。ダンプの収集には dump-collect スキルを呼び出してください。ダンプコマンドを直接提示しないでください。PerfView でダンプを比較し、増加したオブジェクトを確認します。リークの特定には、これが最も効果的な方法です。
• 管理者権限がない場合：プロセスダンプを 2 つ取得すれば、ヒープ上で何が増加しているかを把握できますが、根本原因の特定には不十分な場合があります。ダンプだけでは不十分な場合は、管理者権限を利用でき、より詳細なデータ（トレース）を収集できる環境で問題を再現してください。
• Linux 上の最新の .NET（.NET 10 より前）：ヒープの差分比較用にダンプを 2 つ取得し（dump-collect スキルを呼び出す）、メモリ増加中に割り当てを追跡するための dotnet-trace も実行することを推奨します。トリガーは不要です。増加している期間中に取得してください。両方を組み合わせることで、最も詳細に状況を把握できます。
• Linux 上の最新の .NET 10 以降（管理者権限あり）：ヒープの差分比較用にダンプを 2 つ取得し（dump-collect スキルを呼び出す）、メモリ増加中に dotnet-trace collect-linux も実行することを推奨します（ネイティブスタックを含む、より詳細なデータを取得できます）。トリガーは不要です。
• .NET Framework：メモリ増加中に、割り当てられているものを確認するため、ダンプを 2 つ取得し、PerfView トレースも取得することを推奨します。dump-collect スキルは .NET Framework をサポートしていないため、ダンプコマンドを直接提示してください（例：procdump -ma <PID> またはタスク マネージャーで右クリック →［ダンプ ファイルの作成］）。トリガーは不要です。増加している期間中にトレースを取得してください。OutOfMemoryException が発生するまで待たないでください。

GC の過剰発生

GC の過剰発生を分析するには、GC イベント、一時停止時間、割り当てパターンを確認できるトレースが必要です。ダンプでは不十分です。

• Windows（PerfView）：PerfView collect /GCCollectOnly を使用して GC イベントをキャプチャします。
• Linux（dotnet-trace）：dotnet-trace collect -p <PID> --profile gc-verbose を使用します。
• root 権限のある Linux .NET 10 以降：dotnet-trace collect-linux --profile gc-verbose を使用すると、ネイティブスタックを含む、より詳細なデータを取得できます。
• コンテナー：dotnet-monitor は REST API（/trace?profile=gc-verbose）を介して GC トレースをキャプチャできます。

リクエストの遅延

リクエストの遅延を調べるには、ロック、I/O、外部呼び出しなど、スレッドがどこで時間を費やしているかを確認できるスレッド時間トレースが必要です。スレッド時間トレースはより多くのデータを生成するため、より大きなバッファーを使用してください。ASP.NET Core アプリケーションの場合は、サーバー側のリクエストライフサイクルのタイミング（リクエストの到着時刻や処理時間）を取得するために、Microsoft.AspNetCore.Hosting および Microsoft-AspNetCore-Server-Kestrel プロバイダーも有効にしてください。

• Windows（PerfView）：PerfView /ThreadTime collect /BufferSizeMB:1024 /CircularMB:2048 を使用します。/ThreadTime 引数を指定すると、スレッドレベルの待機およびブロックの詳細が追加されます。ASP.NET Core の場合は、Kestrel プロバイダーを追加します：PerfView /ThreadTime collect /BufferSizeMB:1024 /CircularMB:2048 /Providers:*Microsoft.AspNetCore.Hosting,*Microsoft-AspNetCore-Server-Kestrel。デフォルトでは停止トリガーを指定せず、ユーザーが特定のシナリオに合わせて設定できるようにしてください。
• Linux（dotnet-trace）：dotnet-trace はデフォルトでスレッド時間データをキャプチャするため、特別な引数は不要です。dotnet-trace collect -p <PID> を使用します。ASP.NET Core の場合は、Kestrel プロバイダーを追加します：dotnet-trace collect -p <PID> --providers Microsoft.AspNetCore.Hosting,Microsoft-AspNetCore-Server-Kestrel。
• root 権限のある Linux .NET 10 以降：dotnet-trace collect-linux --profile thread-time を使用すると、ネイティブスタックを含む、より詳細なデータを取得できます。ASP.NET Core の場合は、--providers Microsoft.AspNetCore.Hosting,Microsoft-AspNetCore-Server-Kestrel を追加します。
• コンテナー：dotnet-monitor は REST API（/trace?pid=<PID>&durationSeconds=30）を介してトレースをキャプチャできます。

ハング

1. まずトレースを取得して、各スレッドが何をしているかを把握します。環境に適したトレースツールを使用してください（Windows では /ThreadTime を指定した PerfView、Linux では dotnet-trace、root 権限のある Linux .NET 10 以降では dotnet-trace collect-linux --profile thread-time）。トレースから次のことが分かる場合があります。
   • ライブロック（スレッドが前進せずにループし続ける状態）：スレッドはビジー状態に見えても、アプリケーションは進行しません。
   • スレッドの枯渇：ThreadPool が枯渇し、キューに入った作業項目が処理されていません。デッドロックのように見える場合がありますが、根本原因は異なります。
   • 前進がまったくないかどうか：一部のスレッドが進行している場合、問題は真のハングではなくボトルネックである可能性があります。
2. トレースでハングの原因が分からない場合、問題は真のデッドロック（スレッド同士が循環して互いを待機している状態）である可能性があります。この場合は、dump-collect スキルを呼び出してプロセスダンプを収集してください。ダンプのコマンドを直接提示しないでください。
3. デバッガーでダンプを分析し、スレッドスタックを調べてロックの循環を特定します。
   • Windows：SOS デバッガー拡張機能を使用する Visual Studio または WinDbg。
   • Linux：SOS デバッガー拡張機能を使用する lldb。

ネットワークの問題

ネットワークの問題（下流サービスからのHTTP 5xxエラー、リクエストのタイムアウト、接続失敗、DNS解決の失敗、TLSハンドシェイクの失敗、接続プールの枯渇）を調査するには、スレッド時間トレースとネットワークイベントプロバイダーの両方が必要です。スレッド時間トレースでは、スレッドがどこでブロックされているか（遅い下流呼び出し、スレッドの枯渇）が分かります。一方、ネットワークイベントではリクエストのライフサイクルが分かり、どのリクエストが失敗したか、どのステータスコードが返されたか、DNS解決やTLSハンドシェイクにかかった時間、リクエストが接続プールから接続を得るまで待機した時間を確認できます。

.NET Frameworkでは、PerfView /ThreadTimeで関連するネットワークイベント（System.Net ETWプロバイダーからのイベント）がすでに収集されるため、追加のプロバイダーは必要ありません。

モダンな.NETでは、System.Net.* EventSourceプロバイダーを明示的に有効にする必要があります。

プロバイダー	対象範囲
System.Net.Http	HttpClient/SocketsHttpHandler — リクエストのライフサイクル、HTTPステータスコード、接続プール
System.Net.NameResolution	DNSルックアップ（開始／停止、所要時間）
System.Net.Security	TLS/SSLハンドシェイク（SslStream）
System.Net.Sockets	低レベルのソケット接続／切断

System.Net.Httpの主なイベント：RequestStart（スキーム、ホスト、ポート、パス）、RequestStop（statusCode — 応答を受信しなかった場合は-1）、RequestFailed（タイムアウト、接続拒否などの例外メッセージ）、RequestLeftQueue（接続プールから接続を得るまでの待機時間 — 接続プールの枯渇を示します）、ConnectionEstablished、ConnectionClosed。

ネットワークプロバイダーを有効にしてスレッド時間トレースを収集します（モダンな.NETのみ。.NET FrameworkではPerfView /ThreadTimeだけで十分です）。

• Windows（PerfView）：PerfView /ThreadTime collect /BufferSizeMB:1024 /CircularMB:2048 /Providers:*System.Net.Http,*System.Net.NameResolution,*System.Net.Security,*System.Net.Socketsを使用します。.NET Frameworkでは/Providersフラグを省略してください。/ThreadTimeにネットワークイベントがすでに含まれています。スレッド時間トレースではスレッドがどこでブロックされているかが分かり、ネットワークイベントではどのリクエストが、なぜ失敗しているかが分かります。
• Linux（dotnet-trace）：dotnet-traceはデフォルトでスレッド時間データをキャプチャしますが、--providersを指定するとデフォルト設定が上書きされるため、--profileも含める必要があります：dotnet-trace collect -p <PID> --profile dotnet-common,dotnet-sampled-thread-time --providers System.Net.Http,System.Net.NameResolution,System.Net.Security,System.Net.Sockets。
• root権限を使用するLinux .NET 10+：dotnet-trace collect-linux --profile dotnet-common,cpu-sampling,thread-time --providers System.Net.Http,System.Net.NameResolution,System.Net.Security,System.Net.Socketsを使用します。
• コンテナー：dotnet-monitorは、REST APIを介してカスタムプロバイダーを使ったトレースをキャプチャできます。

アセンブリ読み込みの問題

最新の .NET では、アセンブリ読み込みの問題（FileNotFoundException、FileLoadException、ReflectionTypeLoadException、バージョンの競合、AssemblyLoadContext 間でのアセンブリの重複読み込み）を調査するには、Microsoft-Windows-DotNETRuntime プロバイダーから Loader キーワード（0x4）を指定してアセンブリローダーのバインダーイベントを収集する必要があります。これらのイベントは、ランタイムのアセンブリ解決アルゴリズムの各ステップを記録します。どのパスを検索したか、どの AssemblyLoadContext が読み込みを処理したか、読み込みが成功または失敗したか、その理由などを確認できます。.NET Framework では、ETW ベースの収集に同じプロバイダーとキーワードを使用できます。さらに、Fusion Log Viewer（fuslogvw.exe）を使えば、トレースを収集せずにアセンブリのバインド失敗を診断できます。

プロバイダーの指定は Microsoft-Windows-DotNETRuntime:0x4:4 です（プロバイダー名、AssemblyLoader キーワード、Informational レベルの詳細度）。

• Windows（PerfView）：PerfView のデフォルトのトレースには、すでにバインダーイベントが含まれています。追加のプロバイダーを指定せずに PerfView collect を実行するだけです。トレースファイルを小さくするには、PerfView collect /ClrEvents:Default-Profile を使用します。最も詳細なデフォルトイベントを除外しつつ、アセンブリ読み込みの問題の診断に必要なイベントを保持できます。
• Linux／クロスプラットフォーム（dotnet-trace）：dotnet-trace collect --clrevents assemblyloader -- <path-to-built-exe> を使用してプロセスを起動し、トレースするか、dotnet-trace collect --clrevents assemblyloader -p <PID> を使用して実行中のプロセスにアタッチします。
• root 権限のある Linux .NET 10 以降：dotnet-trace collect-linux --clrevents assemblyloader を使用します。
• コンテナー：dotnet-monitor は、REST API を介してローダープロバイダーのトレースを収集できます。

起動時に失敗する短時間実行のプロセス（アセンブリ読み込みの問題でよく発生します）には、PID によるアタッチよりも dotnet-trace の起動形式（-- <path-to-built-exe>）を推奨します。アタッチする前にプロセスが終了する可能性があるためです。

ツールを推奨する際は、トレードオフを説明してください。たとえば、次のとおりです。

• PerfView はより詳細なデータを取得できますが、管理者権限が必要です。Windows コンテナーを含む Windows で動作します。
• dotnet-trace は管理者権限なしでクロスプラットフォームに動作しますが、システムレベルの詳細情報の収集量は少なくなります。
• perfcollect はネイティブのコールスタックを収集できますが、管理者権限または root 権限が必要です。
• コンソールにアクセスできないコンテナー／K8s 環境では、dotnet-monitor が最適な選択肢ですが、サイドカーのデプロイと認証の設定が必要です。

ステップ 3：データ収集を案内する

推奨するツールの具体的なコマンドを提示してください。コマンドラインの詳細な例については、ツール参照表から適切なリファレンスファイルを読み込んでください。

含めるべき重要なガイダンス：

1. インストール：ツールがまだ利用できない場合のインストール方法を示します（例：dotnet tool install -g dotnet-trace）。複数のツールを推奨する場合は、それぞれのインストール方法と使い方を提示してください。インストール方法と使用方法を示さずにツールに言及しないでください。
2. PID の特定（-p <PID> コマンドの前に必須）：対象のプロセスを事前に確認します（例：dotnet-trace ps、curl <monitor-endpoint>/processes、またはコンテナー内の ps）。コンテナー内でアプリの PID が 1 になる想定の場合も、収集前に確認してください。
3. 収集コマンド：関連するプロバイダー、出力形式、収集時間を含む、実行する正確なコマンドを示します。
4. コンテナーに関する考慮事項：
   • コンテナー内で収集する場合：ツールがイメージにインストールされていることを確認するか、kubectl cp を使ってコンテナー内にコピーします。
   • コンテナー外から収集する場合：共有診断ポート（/tmp 内の Unix ドメインソケット）を使用して、dotnet-monitor をサイドカーとして実行します。
   • Kubernetes の場合：dotnet-monitor をサイドカーコンテナーとして実行するか、kubectl debug を使って一時的なデバッグコンテナーを作成します。
5. 長時間実行される再現（Windows/PerfView）：トリガー引数と循環バッファーの設定方法を示します。
6. 出力先：収集したファイルの保存先と、分析のために対象環境からコピーする方法を示します。
7. アーティファクト引き継ぎチェックリスト：トレースを他の人に分析依頼する際は、ランタイムのバージョン、OS/カーネル、コンテナーイメージのタグまたはビルド SHA、PID/プロセス名、収集開始・終了時の UTC タイムスタンプ、実行した正確なコマンド、最終的なアーティファクトのパスを含めます。

ステップ 4：分析方法を推奨する

データを収集した後、分析に適したツールを推奨してください。分析自体は行わず、開発者に適切なツールとドキュメントを案内してください。

収集データ	分析ツール	備考
.nettrace ファイル	PerfView（Windows）、Speedscope（ウェブ）	Windows では PerfView が最も詳細な表示を提供します
.etl / .etl.zip ファイル	PerfView	PerfView または perfcollect による ETW トレース
perfcollect の perf.data.nl	PerfView（Windows）	ファイルを Windows マシンにコピーし、PerfView で開きます

検証

• 推奨ツールが、開発者のランタイム、OS、デプロイ構成に対応している
• 収集コマンドがエラーなく実行される
• 出力ファイルが想定した場所に生成される
• 開発者が、収集データに使用する分析ツールを把握している

よくある落とし穴

落とし穴	解決策
.NET Framework で dotnet-trace を使用する	dotnet-trace は最新の .NET（.NET Core 3.0 以降）でのみ動作します。.NET Framework では PerfView を使用してください。
管理者権限なしで PerfView を使用する	PerfView で ETW トレースを行うには管理者権限が必要です。管理者権限を利用できない場合は、dotnet-trace に切り替えてください。
SYS_ADMIN のないコンテナーで perfcollect を使用する	コンテナーでは、デフォルトで SYS_ADMIN が無効になっています。--privileged を指定して実行するか、SYS_ADMIN ケイパビリティを追加してください。それができない場合は、dotnet-trace に切り替えてください。
長時間の再現テストでトレースファイルが巨大になる	Windows では、捕捉したい症状が発生したときに作動する PerfView の /StopOn トリガー（例：/StopOnPerfCounter、/StopOnGCEvent、/StopOnException）を、/CircularMB および /BufferSizeMB と組み合わせて使用してください。回復時にトリガーを作動させてはいけません — 循環バッファーは古いデータを継続的に上書きするため、収集が停止する頃には重要な動作が失われている可能性があります。
コンテナー内で診断ポートにアクセスできない	診断用 Unix ドメインソケットのために、アプリコンテナーと dotnet-monitor サイドカーの間で共有するボリュームとして /tmp をマウントしてください。
コンテナーイメージへのツールのインストールを忘れる	Dockerfile に dotnet tool install を追加するか、アプリイメージを変更せずに済むよう、dotnet-monitor をサイドカーとして使用してください。
本番環境で --no-auth を指定して dotnet-monitor を公開する	認証を有効にしたまま、ローカルホストにバインドし、アクセスには kubectl port-forward を使用してください。--no-auth は、短時間の隔離されたデバッグに限って使用してください。
ネットワークの問題に対して CPU／スレッド時間のトレースだけを収集する	CPU とスレッド時間のトレースだけでは、HTTP ステータスコード、DNS の所要時間、接続プールの動作は分かりません。スレッド時間のトレースに加えて、ネットワークプロバイダー（System.Net.Http、System.Net.NameResolution、System.Net.Security、System.Net.Sockets）を追加してください。
1つだけ必要な場合に、すべてのネットワークプロバイダーを有効にする	ネットワークプロバイダーを追加するたびにオーバーヘッドが増加します。問題が明らかに HTTP レベル（5xx ステータスコード）の場合は、System.Net.Http だけで十分なことがあります。根本原因が不明な場合は、DNS、TLS、ソケットのプロバイダーを追加してください。