Supervisión/métricas de rendimiento en la aplicación .NET

Question

Queremos recopilar datos de rendimiento sobre nuestra aplicación (digamos 80% WinApp), tanto internamente en desarrollo como en sitios de clientes. Nuestros objetivos son los siguientes:

• Debe ser muy rápido
• Debe ser ligero
• Se debe permitir el seguimiento/& tiempo contando muchos tipos diferentes de eventos a través de nuestras aplicaciones.
• Debe ser capaz de reunir (eficientemente) una buena cantidad de datos tales como dominio, nombre de computadora, usuario, sistema operativo, memoria, etc.
• Todos los datos recopilados deben ser analizables (una vez que se ha transmitido a nuestro Base de datos de BI) en todas las dimensiones mencionadas anteriormente.

Sería también, idealmente, ser relativamente configurable en un nivel de todo el sitio o usuario por usuario controlar:

• Si estos parámetros de rendimiento siquiera se cobran
• Cómo informa extensamente para recopilar ellos
• si notifican los resultados de nuevo a nosotros

Hemos estado planeando escribir esencialmente nuestro propio sistema para hacer la mayor parte del XX es. Luego, observamos varios modelos de "persistencia" diferentes, incluido el formato binario de "paquetes de rendimiento", XmlSerialization y la funcionalidad de registro de seguimiento que ya forma parte del framework .NET, solo por nombrar algunos.

Antes de ocuparme de esto, quería verificar para ver qué recomendaciones sugiere "la multitud". He descrito lo que estamos tratando de hacer, y esencialmente nuestro plan de acción actual, pero estoy buscando cualquiera y todas las sugerencias acerca de cómo resolver mejor el problema en cuestión.

Gracias de antemano.

Answer 1

Ir con su plan Me gustaría tener este enfoque:

1. Vas a escribir todos los datos de rendimiento para un archivo de registro. Utilice una de las rápidas bibliotecas de registro C# como log4net o nlog. Estos marcos admiten apéndices binarios si es necesario.
2. Cuando se inicia la aplicación, escriba la RAM disponible, CPU, etc.
3. Utilice un inyector de aspecto como PostSharp para agregar automáticamente un temporizador a cada método (no en línea) en su aplicación. La clase Cronómetro no hará un golpe de rendimiento significativo. Para que este configurable tenga el inyector de aspecto, cambie el nivel de registro de acuerdo con la prioridad estimada del método (o use sus propios atributos para especificar eso).
4. Solicite al usuario que salga (o inicie) para enviar los datos de rendimiento grabados a su servidor web.
5. Comprima los datos en el camino de salida.

También es posible que desee considerar la posibilidad de escribir su propia clase de bloqueo. En lugar de utilizar lock(blah) o Monitor.Enter(blah), cierre Monitor.Ingrese/Salga en su propia clase desechable que registra cuánto tiempo tuvo que esperar para ingresar al bloqueo.

Answer 2

Comenzaría probando si using the EventLog resolvería mi problema. Los mensajes de EventLog contienen mucha información y usted puede agregar la suya.

Para algunos diagnósticos eche un vistazo a (custom) Performance Counters. Mi apuesta es que es difícil crear algo que supere el rendimiento de los Contadores de rendimiento de Windows.

Escribir esto una vez más podría no valer la pena.

Podría ser necesario para crear filtros especiales en el visor de eventos para obtener la salida que busca o para recabar el caso en todos los equipos (que incluso podría escribir su propio visor)

Answer 3

Tenga una mirada en Metrics.NET, una proyecto relativamente nuevo que debería cubrir la mayoría de estas necesidades. Es un proyecto de 'métricas' del puerto de Java.

(Agregado en marzo de 2016 :) El proyecto Metrics.NET se ha transferido a nuevas personas después de un largo período sin actualizaciones.

Answer 4

Se puede echar un vistazo a la construcción de algo en la parte superior de StatsD:

https://github.com/etsy/statsd/

Hay un paquete de .NET para la que se puede encontrar aquí:

https://github.com/robbihun/NStatsD.Client

Es ligero como Básicamente se trata simplemente de disparar un paquete UDP a un servidor remoto. Ese servidor remoto luego lo agrega y lo almacena en Graphite, que es bueno para tomar estos datos y convertirlos en gráficos y gestionar cosas como la retención de datos para usted. Para el análisis, Graphite también le permite generar los datos como JSON (que básicamente convierte sus métricas en una matriz de dobles) y tiene muchas funciones y filtros que puede aplicar a las métricas grabadas que luego puede ingresar a sus otros sistemas.

Vea aquí algunos ejemplos de lo que es posible con grafito:

http://matt.aimonetti.net/posts/2013/06/26/practical-guide-to-graphite-monitoring

No cumple sin embargo todos sus requisitos, tales como ser capaz de registrar datos sobre el cliente como nombres de equipo. Pero probablemente pueda alcanzar ese objetivo al usar el espacio de nombres en sus nombres de indicadores; entonces registraría su métrica con una clave como "client567.orders.loadtime" y "client567" sería una entrada en alguna otra base de datos que almacena ese cliente567 usa IE11 en Windows 7, por ejemplo.

Así que no es una solución lista para usar, pero creo que es una buena base.

Otra opción es utilizar una plataforma comercial como NewRelic:

http://newrelic.com/

Viene con la supervisión del rendimiento de una gran cantidad de tecnologías (desde ASP.NET a SQL Server para Solr). Sin embargo, requiere un proceso de agente (un servicio en Windows) ejecutándose en segundo plano que maneje la supervisión por usted, lo que podría ser o no una opción para usted. Está más o menos destinado a servidores web y probablemente no sea muy adecuado para supervisar una aplicación WPF del lado del cliente.