次の方法で共有

Linux コンテナーで診断を収集する

他のシナリオで .NET の問題を診断するのに役立つのと同じ診断ツールは、コンテナーでも機能します。 ツールは、ターゲット プロセスと同じコンテナー、ホスト、またはサイドカー コンテナーから実行できます。

コンテナーで .NET CLI ツールを使用する

これらのツールの適用対象: ✔️ .NET Core 3.1 SDK 以降のバージョン

すべての dotnet-* CLI 診断ツールは、検査しているアプリケーションと同じコンテナー内で実行すると機能しますが、次の潜在的な問題に注意してください。

  • コンテナー内で実行されるツールには、コンテナー リソースの制限が適用されます。 リソースの制限が低すぎると、ツールの実行速度が遅くなったり、失敗したりする可能性があります。 ほとんどのツールには適度な要件がありますが、 dotnet-dump と dotnet-gcdump では、メモリ占有領域が大きいプロセスをターゲットにするときに、かなりのメモリとディスク領域を使用できます。 dotnet-trace また、大量のトレース イベントまたはメトリック時系列データをキャプチャするように構成されている場合、 dotnet-counters は大きなファイルを作成する場合もあります。
  • dotnet-dump は、ptrace アクセス許可を必要とするヘルパー プロセスを実行します。 Linux には多数のセキュリティ構成オプションがあり、これが成功したかどうかに影響を与える可能性があるため、場合によってはコンテナーのセキュリティ構成を調整する必要があります。 セキュリティ特権の診断に関する詳細なガイダンスについては、ダンプに関する FAQ を参照してください。
  • コンテナー内でツールを実行する場合は、コンテナーのビルド時に事前にツールをインストールするか、オンデマンドでダウンロードすることができます。 事前にインストールすると、必要なときに簡単にインストールできますが、コンテナーのサイズが大きくなり、悪意のあるアクターが悪用しようとする可能性のある攻撃面が大きくなります。

サイドカー コンテナーまたはホストから .NET CLI ツールを使用する

dotnet-* CLI 診断ツールでは、ホストまたはサイドカー コンテナーでの実行もサポートされています。 これにより、同じコンテナーでの実行のサイズ、セキュリティ、およびリソースの制限が大幅に回避されますが、ツールが正常に通信するための追加要件がいくつかあります。

--process-idまたは--name ツールのコマンド ライン引数を使用して検査するターゲット プロセスを特定する場合は、次のものが必要です。

  1. サイドカー コンテナー内のツールがターゲット コンテナー内のプロセスにアクセスできるように、コンテナーはプロセス 名前空間を共有 する必要があります。
  2. ツールは、.NET ランタイムが /tmp ディレクトリに書き込む診断ポート Unix ドメイン ソケットにアクセスする必要があるため、ボリューム マウントを介してターゲットコンテナーとサイドカー コンテナー間で /tmp ディレクトリを共有する必要があります。 これは、たとえば、コンテナーで共通のボリュームまたは Kubernetes emptyDir ボリュームを共有することにより、行うことができます。 /tmp ディレクトリを共有せずにサイドカー コンテナーから診断ツールを使用しようとすると、"互換性のある .NET ランタイムが実行されていません" プロセスに関するエラーが表示されます。

プロセス名前空間と /tmp ディレクトリを共有したくない場合、多くのツールでは、より高度な --diagnostic-port コマンド ライン オプションもサポートされます。 これにより、ホストまたはサイドカーのファイルシステム内のターゲット プロセスの 診断ポート へのパスを直接指定できます。 このパスが存在するためには、ターゲット コンテナーの /tmp ディレクトリをどこかにマップする必要がありますが、ホストまたはサイドカー /tmp と共有する必要はありません。

注

ホストまたはサイドカーから診断ツールを実行する場合でも、ターゲット プロセスに対して、ターゲット コンテナー内のリソース使用量を増やす作業を要求される場合があります。 私たちは、dotnet-dump を実行すると、ダンプを収集する際にターゲットプロセスがかなりの量の仮想メモリをページインする可能性があることを目にしてきました。 他のツールは影響が小さい可能性がありますが、実際にはこれらが問題を引き起こすことは見られていません。 たとえば、 dotnet-trace はターゲット プロセスにイベント バッファーの割り当てを要求し、 dotnet-counters はメトリック データが集計される小さなメモリ領域を要求します。 メモリ制限がきつすぎてツールの実行時にOSがコンテナーを終了しないようにテストすることをお勧めします。

注

dotnet-dumpがダンプ ファイルをディスクに書き込むと、出力パスは、ファイル システムのターゲット プロセスビューのコンテキストで解釈されます。 これは、ホストまたはサイドカー コンテナーとは異なる場合があります。

コンテナーで PerfCollect を使用する

このツールの適用対象: ✔️ .NET Core 2.1 以降のバージョン

PerfCollect スクリプトは、CPU サンプルやコンテキスト スイッチなどのカーネル イベントを含むパフォーマンス トレースを収集するのに役立ちます。 コンテナーで PerfCollect を使用する場合は、次の要件を考慮してください。

  • PerfCollect には、perf ツールを実行するための追加機能が必要です。 必要な最小限の機能セットは、PERFMON と SYS_PTRACE です。 一部の環境では、SYS_ADMIN が必要になります。 必ず必要な機能とともにコンテナーを起動してください。 最小限のセットでうまくいかない場合は、完全なセットで試してみてください。

  • PerfCollect は、開始プロファイリングの対象となるアプリより前に、いくつかの環境変数が設定されていることを必要とします。 これらは、Dockerfile で、またはコンテナーを開始するときに、設定できます。 これらの変数は通常の運用環境では設定されないので、プロファイリング対象のコンテナーを開始するときにだけ追加するのが一般的です。 PerfCollect で必要になる 2 つの変数は次のとおりです。

    • DOTNET_PerfMapEnabled=1
    • DOTNET_EnableEventLog=1

注

.NET 7 でアプリを実行するとき、前述の環境変数に加え、DOTNET_EnableWriteXorExecute=0 も設定する必要があります。

注

.NET 6 では、.NET の実行時の動作を構成する環境変数のプレフィックスが、DOTNET_ ではなく COMPlus_ に標準化されています。 ただし、プレフィックス COMPlus_ は引き続き機能します。 以前のバージョンの .NET ランタイムを使用している場合は、環境変数に COMPlus_ プレフィックスをまだ使用する必要があります。

サイドカー コンテナーで PerfCollect を使用する

1つのコンテナーで PerfCollect を実行し 、別のコンテナーで .NET プロセスをプロファイリングする場合、エクスペリエンスはほぼ同じです。 相違点は以下のとおりです。

  • 前述の環境変数 (DOTNET_PerfMapEnabled と DOTNET_EnableEventLog) は、(PerfCollect を実行しているものではなく) ターゲット コンテナーに設定する必要があります。
  • (ターゲット コンテナーではなく) PerfCollect を実行するコンテナーに、SYS_ADMIN 機能が必要です。
  • 2 つのコンテナーは、プロセスの名前空間を共有している必要があります。