5

私は、いくつかのアプリケーションとサービスで構成されるシステムを使用しており、ほとんどすべてが SQL データベースを使用しています。

Windows サービスは、さまざまなタイミングでさまざまなことを行うので、それらを追跡したいと思います。つまり、展開された一部のシステムでは、マシンの CPU 使用率が高く、SQL プロセスの使用率が高いことがわかりますが、どのサービスが原因であるかはわかりません。

この仕事にはパフォーマンス カウンターが適しているのだろうか。

基本的に、特定の瞬間にどのサービスが起動して何かを処理しているかを確認できるようにしたいと考えています。

perfcounter各サービスが何かを行っているかどうかを示すために、各サービスの値が 0 または 1 しかないを最終的に持つことができるように思えますが、これは の通常の使用法とは思えませんperfcounters

パフォーマンス カウンターは適していますか?

これを別の方法で追跡する必要があると思いますか?

4

3 に答える 3

4

監視フレームワーク/アプローチが既にパフォーマンス カウンターの監視を中心としている場合、これは実行可能なアプローチです。

個人的には、自分のサービスで何が起こっているのかを本当に理解するには、より詳細な計測が必要だと思います (ただし、それは自分のサービスの性質に関係している可能性があります)。

私は.NET Logging Frameworkを使用しています。これはシンプルで、ログ ファイル、イベント ログ、TCP ソケットなどの複数のターゲットに書き込むことができるためです (各アプリ サーバーのログ ソケットをリッスンし、リアルタイムで表示する単純なモニターがあります)。何が起こっていますか)。

于 2009-09-13T20:42:41.083 に答える
1

パフォーマンス カウンターは非常に軽量なため魅力的ですが、おっしゃる通り数値しか取得できません。確かに、平均、デルタ、合計など、記録できるさまざまな種類の値がたくさんありますが、それらは数値でなければなりません。

それ以上の情報が必要な場合は、他のタイプの計測器を使用する必要があります。あなたの場合、あなたのニーズはその方向に進んでいるようです。

サービスが頻繁に起動したり停止したりしない場合は、カスタム イベント ログに情報メッセージを送信することをお勧めします。通常のアプリケーション イベント ログがあふれないように、かなりの量のイベント ログが予想される場合は、アプリケーションのカスタム イベント ログを作成します。

インストルメンテーションが通常のイベント ログに対して大量のデータを生成することが予想される場合は、.NET Trace API を使用することをお勧めします。app/web.config に基づいてトレースするように、またはベースにしないようにアプリケーションを構成できますが、変更するにはアプリの再起動が必要になります。これは、インストルメンテーションをトラブルシューティングにのみ使用する場合に適したオプションですが、生成されるデータが多すぎる場合や、トレース自体によってパフォーマンスが大幅に低下する場合に適しています。トレース API のもう 1 つの利点は、複数のレベルでトレースできることです。そのため、非常に詳細にトレースするコードを記述した場合でも、詳細なトレースを有効にすると、その詳細なトレース データのみが表示されます。これにより、トレース対象をより適切に制御できます。

于 2009-09-13T20:45:25.417 に答える
1

エリック J には良い点があります。「タイミング」のパフォーマンスを本当にキャプチャしたい場合は、他の種類のログを使用し、開始時間と停止時間のログを使用する必要があると思います。初めて設定するのは面倒かもしれませんが、個人的にはlog4netが好きです

于 2009-09-13T20:56:03.437 に答える