私は、ほとんどすべてがSQLデータベースを使用して、いくつかのアプリケーションとサービスで構成されるシステムを扱っています。パフォーマンスカウンターを使用してWindowsサービスを追跡する
Windowsサービスは、異なる時に異なることを行い、それらを追跡したいと思います。つまり、デプロイされたシステムによっては、マシンがCPU上で稼働していることがわかりますが、SQLプロセスは高水準になっていますが、どのサービスがそのプロセスを担当しているかはわかりません。
パフォーマンスカウンタがこのジョブに適しているのだろうかと思います。
基本的に私はある瞬間にサービスが起きて何かを処理しているのを見ることができるようにしたいと思います。
私には、何かしている場合に表示されるサービスごとに0または1の値しか持たないperfcounterがありますが、これはperfcountersの通常の使用のようには見えません。
パフォーマンスカウンターは適切ですか？
これを別の方法で追跡する必要があると思いますか？
あなたの監視フレームワーク/アプローチがパフォーマンスカウンタの監視を既に中心にしている場合、これは実現可能なアプローチです。
個人的には、私のサービスで何が起きているのかを実際に理解するために必要な、より詳細な計器があります（私のサービスの性質と関係しているかもしれませんが）。
私はシンプルで、ログファイル、イベントログ、TCPソケットなどの複数のターゲットに書き込むことができるので便利です（各アプリケーションサーバーのロギングソケットを監視し、何が起こっているか）。
パフォーマンスカウンタは実際には軽量であるため魅力的ですが、あなたが言うように、数値を取得することしかできません。確かに、平均、デルタ、合計など、記録できる値の種類はたくさんありますが、数値でなければなりません。
これ以上の情報が必要な場合は、他の種類の計測に頼らなくてはなりません。あなたの場合、あなたの必要性がその方向にもっと進むように聞こえます。
サービスが頻繁に起きていない場合は、カスタムイベントログへの通知メッセージのように聞こえる場合があります。アプリケーションのカスタムイベントログを作成して、通常のアプリケーションイベントログをあふれさせないようにします。
.NET Trace APIは、計測器で通常のイベントログのデータが非常に多く生成されることが予想される場合は、より良いオプションになります。 app/web.configに基づいてトレースするかどうかを設定することができますが、変更するにはアプリを再起動する必要があります。これは、トラブルシューティングのために計測器を使用する場合にのみ適していますが、それ以外の場合はデータが非常に多く生成されたり、トレース自体がパフォーマンスを大きく低下させたりする場合に適しています。トレースAPIのもう一つの利点は、複数のレベルでトレースすることができることです。トレースを非常に冗長に記述したとしても、詳細なトレースを有効にするとそのトレースデータだけが表示されます。これは、トレースされているものだけをよりよく制御します。
エリックJは良い点があります。私はあなたが本当に "タイミング"のパフォーマンスを捕まえたいなら、あなたはいくつかの他の種類のログを使用し、開始時刻と終了時刻のログを使用しなければならないと思います。私は個人的にはlog4netが好きですが、最初に設定するのは苦痛かもしれません
Log4Netを使用して、トレースとエラーログに使用しているので、タイミングを維持します。 – pauloya