Uso de contadores de rendimiento para rastrear servicios de Windows

Question

Estoy trabajando con un sistema que consta de varias aplicaciones y servicios, casi todos usan una base de datos SQL.

Los servicios de Windows hacen cosas diferentes en diferentes momentos, y me gustaría rastrearlos. Lo que significa que en algunos sistemas implementados vemos que la máquina tiene un alto nivel de CPU, vemos que el proceso de sql se está ejecutando alto, pero no podemos estar seguros de qué servicio es responsable de ello.

Me pregunto si los contadores de rendimiento son buenos para este trabajo.

Básicamente me gustaría poder ver en determinado momento qué servicio se ha despertado y está procesando algo.

Me parece que puedo terminar teniendo un perfcounter que solo tiene el valor 0 o 1 para cada servicio para mostrar si está haciendo algo, pero esto no parece un uso normal para perfcounters.

¿Los contadores de rendimiento son adecuados?

¿Crees que debería rastrear esto de una manera diferente?

Answer 1

Si su marco/enfoque de supervisión ya se centra en monitorear los contadores de rendimiento, este es un enfoque viable.

Personalmente encuentro que se necesita una instrumentación más detallada para entender realmente lo que está sucediendo en mis servicios (aunque tal vez eso tenga que ver con la naturaleza de mis servicios).

Uso .NET Logging Framework porque es simple y puedo escribir en varios destinos, incluidos los archivos de registro, el registro de eventos y un socket TCP (tengo un monitor simple que escucha en el socket de registro para cada servidor de aplicaciones y me muestra en tiempo lo que está pasando).

Answer 2

Los contadores de rendimiento son atractivos porque son muy livianos, pero como dices, solo te permiten capturar valores numéricos. Claro, hay una gran cantidad de diferentes tipos de valores que puede registrar, como promedios, deltas y totales, pero tienen que ser números.

Si necesita más información que eso, debe recurrir a algún otro tipo de instrumentación. En su caso, parece que su necesidad va más en esa dirección.

Si sus servicios no se despiertan y se suspenden demasiado a menudo, podría parecer una buena idea enviar un mensaje informativo a un registro de eventos personalizado. Cree un registro de eventos personalizado para la aplicación si espera una buena cantidad de estos para no inundar el registro de eventos de la aplicación habitual.

La .NET Trace API será una mejor opción si espera que la instrumentación genere demasiados datos para el registro de eventos normal. Puede configurar su (s) aplicación (es) para rastrear o no según la aplicación/web.config, aunque un cambio requerirá un reinicio de la aplicación. Esta es una buena opción si solo desea utilizar la instrumentación para solucionar problemas, pero de lo contrario genera demasiados datos o si el rastreo en sí mismo degrada el rendimiento demasiado. Otra cosa buena de la API de seguimiento es que puede rastrear en múltiples niveles, por lo que incluso si ha escrito código para Trazar de forma muy detallada, solo verá los datos de seguimiento detallado si habilita el seguimiento detallado. Eso le da un mejor control de lo que se rastrea.

Answer 3

Eric J tiene un buen punto. Creo que si realmente quieres capturar el rendimiento del "timing" deberás usar algún otro tipo de logging y usar los registros de tiempo de inicio y finalización.Personalmente, me gusta log4net, aunque puede ser complicado configurar la primera vez en