.NET Trace Collect

このスキルは、開発者が本番環境のパフォーマンス問題を診断できるよう、環境に適した診断ツールを推奨し、データ収集をガイドし、分析アプローチを提案します。コードのアンチパターン分析や分析自体は実施しません。

使用時期

• 開発者が本番環境のパフォーマンス問題（高 CPU、メモリリーク、遅いリクエスト、過度な GC、ネットワークエラーなど）を調査する必要がある
• 特定のランタイム、OS、またはデプロイメントトポロジーに適した診断ツールを選択する
• データ収集用の診断ツールコマンドのセットアップと実行
• 利用可能なツール間のトレードオフを理解する（例：PerfView 対 dotnet-trace）
• コンテナ化またはKubernetesワークロードから診断情報を収集する

使用しない時期

• パフォーマンスアンチパターンのソースコードレビュー（コードレビュースキルを使用）
• 開発中のベンチマーク（例：BenchmarkDotNet セットアップ）
• 収集したトレースまたはダンプファイルの分析（このスキルは分析ツールを推奨しますが、分析自体は実施しません）

入力

入力	必須	説明
Symptom	はい	開発者が観察している内容（高 CPU、メモリ成長、遅いリクエスト、ハング、過度な GC、HTTP 5xx エラー、ネットワークタイムアウト、接続失敗、アセンブリロード失敗など）
Runtime	はい	.NET Framework または最新の .NET（特に .NET 10 以降かどうかを含むバージョン）
OS	はい	Windows または Linux
Deployment	はい	非コンテナ、コンテナ、または Kubernetes
Admin privileges	推奨	ターゲットマシンでの管理者/ルートアクセス権限があるかどうか
Repro characteristics	推奨	問題が再現しやすいか、長時間かけて顕在化するかどうか

ワークフロー

ステップ1：環境を理解する

次の内容を確認または開発者に明確化するよう求めてください：

1. Symptom: 観察している内容（高 CPU、メモリリーク、遅いリクエスト、ハング、過度な GC、HTTP 5xx エラー、ネットワークタイムアウト、接続失敗、アセンブリロード失敗など）
2. Runtime: .NET Framework それとも最新の .NET？最新の .NET の場合、どのバージョン？（特に .NET 10 以降かどうか）
3. OS: Windows それとも Linux？
4. Deployment: ホスト上で直接実行、コンテナ内、または Kubernetes内？
5. Admin privileges: ターゲットマシンまたはコンテナでの管理者/ルートアクセス権限があるか？
6. Repro characteristics: 問題がすぐに再現するか、長時間かけて顕在化するか？
7. Workload context: ワークロードのコンテキスト内で実行しているかどうかを確認または質問してください（つまり、問題が発生している同じマシン上、または同じ環境に接続しているか）。そうである場合は、診断コマンドを直接実行できます。そうでない場合は、ユーザーが自分で実行するためのガイダンスとしてコマンドを提供します。

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

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

以下の優先ルールを使用して環境に基づいてツールを選択してください。ツールが選択されたら、詳細なコマンドライン使用方法のための対応する参照ファイルを読み込んでください。

ツール参照ルックアップ

環境	参照ファイル
Windows + 最新の .NET + 管理者	references/perfview.md
Windows + 最新の .NET、管理者なし	references/dotnet-trace-collect.md
Windows + .NET Framework	references/perfview.md
Linux + .NET 10+ + ルート	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+ + ルート	dotnet-trace collect-linux	ルートまたはカーネル前提条件が満たされていない場合は dotnet-trace を使用
Linux + .NET 10 前	dotnet-trace	ネイティブスタックが必要な場合は perfcollect を追加（ルートが必要）
Linux コンテナ/Kubernetes	ワークロードコンテキスト内の場合はコンソールツール。コンソールアクセスなしの場合は dotnet-monitor	Linux コンテナ/Kubernetes セクションを参照

Windows（非コンテナ、最新の .NET）

1. PerfView（推奨）— より豊富な ETW ベースのデータを生成します。管理者権限が必要です。遅いリクエストの場合、スレッドレベルの待機とブロック詳細をキャプチャするために /ThreadTime を追加してください。
2. dotnet-trace — 管理者権限が利用できない場合のフォールバック。
3. 長時間実行される再現の場合：/StopOn トリガーを備えた PerfView を使用して、キャプチャしたい症状で発火する（例：/StopOnPerfCounter、/StopOnGCEvent、/StopOnException）ようにし、循環バッファー（/CircularMB + /BufferSizeMB）を使用してください。重要：停止トリガーは復旧ではなく、関心のあるイベントで発火する必要があります。 循環バッファーは継続的に古いデータを上書きするため、復旧で発火させると、コレクションが停止するまでに関心のある動作が上書きされているかもしれません。開始イベントが停止イベントの前に発生することが既知の場合のみ /StartOn を追加してください。遅いリクエストの場合、デフォルトでは停止トリガーを含めないでください — ユーザーが特定のシナリオに基づいて設計できるようにしてください。

Windows コンテナ

1. PerfView — ほとんどの Windows コンテナ（Windows 上の Kubernetes を含む）はデフォルトでプロセス分離を使用します。ホストから /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. 長い再現での同じトリガーガイダンス：症状で発火する /StopOn トリガー（例：/StopOnPerfCounter、/StopOnGCEvent、/StopOnException）を /CircularMB + /BufferSizeMB と共に使用してください。
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 は不要）。ルートが必要で、カーネル >= 6.4。
2. dotnet-trace — ルート権限が利用できない場合またはカーネル要件が満たされていない場合のフォールバック。マネージスタックのみ。

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

1. dotnet-trace（推奨）— マネージトレース収集。管理者は不要。
2. perfcollect — ネイティブコールスタックが必要な場合（管理者/ルートが必要）。

Linux コンテナ/Kubernetes

ワークロードのコンテキスト内で実行している場合（つまり、コンテナへのコンソールアクセスがある場合）、コンソールベースのツールを優先してください。これらは dotnet-monitor よりセットアップが簡単です。dotnet-monitor には認証構成とサイドカーデプロイメントが必要です：

1. dotnet-trace collect-linux（.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 でダンプを diff して、どのオブジェクトが増加したかを確認してください — これはリークしているものを特定する最も効果的な方法です。
• 管理者権限なし：2 つのプロセスダンプはヒープで何が成長しているかについて概要を提供できますが、根本原因を特定するには不十分かもしれません。ダンプが十分でない場合は、より豊富なデータ（トレース）を収集できるように管理者権限が利用可能な環境で問題を再現してください。
• Linux 上の最新の .NET（.NET 10 前）：メモリが成長している間、2 つのダンプキャプチャ（dump-collect スキル呼び出し）をヒープ diff に推奨し、dotnet-trace を推奨してください（割り当て追跡用）。トリガーは不要 — 成長期間中にキャプチャしてください。両者は最良の概要を提供します。
• Linux 上の最新の .NET 10+ 管理者付き：メモリが成長している間、2 つのダンプキャプチャ（dump-collect スキル呼び出し）をヒープ diff に推奨し、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 を使用してください。
• 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。
• 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、.NET 10+ Linux ルート付きは dotnet-trace collect-linux --profile thread-time）。トレースは以下を明らかにできます：
   • ライブロック（スレッドが回転していても前進なし）— スレッドはビジーに見えますが、アプリケーションは進捗しません。
   • スレッド飢餓 — ThreadPool が消耗し、キューに入ったワークアイテムが処理されていません。これはデッドロックのように見えますが、異なる根本原因があります。
   • いかなる前進があるかどうか — 一部のスレッドが前進している場合、問題は真のハングではなくボトルネックかもしれません。
2. トレースがハングを説明しない場合、問題は真のデッドロック（スレッドがサイクル内で相互に待機）かもしれません。この場合、dump-collect スキルを呼び出してプロセスダンプを収集してください — ダンプコマンドを直接提供しないでください。
3. デバッガーでダンプを分析して スレッドスタックを検査し、ロックサイクルを特定してください：
   • Windows：Visual Studio または SOS デバッガー拡張機能付き 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。
• 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 全体での重複アセンブリロード）には、Loader キーワード（0x4）を備えた Microsoft-Windows-DotNETRuntime プロバイダーからアセンブリローダーバインダーイベントを収集する必要があります。これらのイベントはランタイムのアセンブリ解決アルゴリズムのすべてのステップをトレースします — どのパスがプローブされたか、どの AssemblyLoadContext がロードを処理したか、ロードが成功したか失敗したか、そしてなぜかをトレースします。.NET Framework の場合、同じプロバイダーとキーワードは ETW ベースの収集に機能します。さらに、Fusion Log Viewer（fuslogvw.exe）はトレースを必要とせずにアセンブリバインディング失敗を診断できます。

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

• 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> を使用して実行中のプロセスにアタッチしてください。
• 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 はネイティブコールスタックをキャプチャしますが、管理者/ルートが必要です。
• dotnet-monitor はコンソールアクセスが利用できない場合のコンテナ/K8s の最良のオプションですが、サイドカーデプロイメントと認証構成が必要です。

ステップ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 を使用してコピーしてください。
   • コンテナ外から収集：サイドカーとして dotnet-monitor を使用し、/tmp の Unix ドメインソケットの共有診断ポートを使用してください。
   • Kubernetes：サイドカーコンテナとしての dotnet-monitor、またはエフェメラルデバッグコンテナのための kubectl debug。
5. 長時間実行される再現（Windows/PerfView）：トリガー引数と循環バッファー設定の使用方法を表示してください。
6. 出力場所：収集されたファイルが保存される場所と、分析用にターゲットからコピーする方法。
7. アーティファクトハンドオフチェックリスト：トレースを分析のため他の人に引き渡す際に、ランタイムバージョン、OS/カーネル、コンテナイメージタグまたはビルド SHA、PID/プロセス名、UTC コレクション開始/終了タイムスタンプ、使用された正確なコマンド、および最終的なアーティファクトパスを含めてください。

ステップ4：分析アプローチを推奨する

データが収集された後、分析用の適切なツールを推奨してください。分析を実行しないでください — 開発者を正しいツールとドキュメントに向けるだけです。

収集されたデータ	分析ツール	注記
.nettrace ファイル	PerfView（Windows）、Speedscope（ウェブ）	PerfView は Windows で最も豊富なビューを提供します
.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 と共に使用してください。復旧で発火させないでください — 循環バッファーは継続的に古いデータを上書きするため、停止時に関心のある動作が失われているかもしれません。
コンテナで診断ポートにアクセスできない	アプリコンテナと dotnet-monitor サイドカー間で /tmp を共有ボリュームとしてマウントして、診断 Unix ドメインソケットを使用してください。
コンテナイメージへのツールのインストール忘却	Dockerfile に dotnet tool install を追加するか、アプリイメージを修正するのを避けるためにサイドカーとして dotnet-monitor を使用してください。
本番環境での --no-auth を使用した dotnet-monitor の公開	認証を有効にしたまま、localhost にバインドし、アクセスのために kubectl port-forward を使用してください。--no-auth は短時間のいた離されたデバッグ用にのみ使用してください。
ネットワーク問題の CPU/スレッド時間トレースのみ収集	CPU とスレッド時間トレースだけは HTTP ステータスコード、DNS タイミング、または接続プール動作を示しません。ネットワーキングプロバイダー（System.Net.Http、System.Net.NameResolution、System.Net.Security、System.Net.Sockets）をスレッド時間トレースと一緒に追加してください。
必要な場合のみのネットワーキングプロバイダーをすべて有効にする	各ネットワーキングプロバイダーはオーバーヘッドを追加します。問題が明らかに HTTP レベル（5xx ステータスコード）の場合、System.Net.Http だけで十分かもしれません。根本原因が不明な場合は DNS、TLS、ソケットプロバイダーを追加してください。