2019年10月のMicorosoft Docsの更新内容を見ていて.NET Core Diagnostics CLI Toolというものがあることに気が付きました。
それぞれdotnet-counters, dotnet-dump, dotnet-traceなるものっぽいです。
それぞれちょっとずつ試してみました。
dotnet-counters
.NET CoreなアプリのCPU使用率やヒープサイズ, 世代毎GCカウントなどをCLI上でモニタリングするPerformance Counterのようです。
下記コマンドでインストールできます。
dotnet tool install --global dotnet-counters
使用する際は監視対象アプリのPIDが必要です。
dotnet-countersには.NET Coreで動いてるアプリのPIDを調べる機能が最初から備わっているので、そのコマンドでPIDを調べます。
Blazorを動かしている状態でdotnet-counters psしてみます。
PIDは12960ですね。
dotnet-countersでモニタリングしてみましょう。
dotnet-counters monitor -p {PID}
こんな感じの画面になりました。
取得するDLLを絞ったり、データ項目を限定することもできるようです。
dotnet-counters monitor -p {PID} System.Runtime[cpu-usage,gc-heap-size]
ほーん。
dotnet-dump
所謂メモリダンプでしょうか。
いくつか注意する点があるようです。Microsoft Docsから引用します。
dotnet-dump グローバル ツールを使用すると、Linux の lldb などの任意のネイティブ デバッガーを使用せずに、Windows と Linux のダンプを収集して分析できます。 このツールは、lldb が完全に動作しない Alpine Linux などのプラットフォームで重要です。 dotnet-dump ツールでは、SOS コマンドを実行してクラッシュとガベージ コレクター (GC) を分析できますが、これはネイティブのデバッガーではないため、ネイティブ スタック フレームの表示などの操作はサポートされていません。
下記コマンドでインストールできます。
※Macは非対応の機能のようです。
dotnet tool install -g dotnet-dump
さっそくDump取ってみましょう。
dotnet-dump collect -p {PID}
Dumpを取り終わった後はdotnet-dump analyzeでDump結果を分析できるようです。
dotnet-dump analyze {dumpファイル名}
対話型セッションに移りました。
clrstackでアセンブリに関すマネージド コードのみのスタック トレースを表示します。
ほーん。
dotnet-trace
Traceログを採取できるようです。
下記コマンドでインストールできます。
dotnet tool install --global dotnet-trace
Traceログを採取します。
dotnet-trace collect -p {PID}
デフォルトだとCPU-Samplingになるっぽいですね。
他にもgc-verboseやgc-collectもあるっぽい。
出力されたtrace.nettraceをPerfViewで見てみましょう。
ちゃんと開けました。
おわり
いずれも.NET Core 3.0以降を対象としたツールだそうです。
Macではdotnet-dumpが使えない点にも注意ですね。