Monitoreo de rendimiento continuo de aplicaciones .NET en producción?

Question

Dado un sistema .NET 4 relativamente típico en un entorno SOA (es decir, Windows Server 2008 R2, servicios web RESTful en IIS 7, servicios de Windows para mensajería NServiceBus, SQL Server 2008 R2, etc.) ¿cuáles son las mejores prácticas o soluciones de facto (sin etiqueta de precio de la empresa) para realizar un monitoreo de rendimiento 24x7 en producción?

No necesariamente la cantidad de CPU/Memoria/Disco IO que consume, sino más bien cuántas llamadas CreateAccount() se hicieron por minuto, cuál es el tiempo promedio que toma el método generateResponse() y detecta picos delta inusuales entre, por ejemplo, generateResponseStarted y generateResponseComplete (se invocó el método (que a su vez puede llamar a un tercero) y la respuesta está lista para ser devuelta, respectivamente).

Después de buscar en Google, parece que las opciones son para perfiladores de bajo nivel (como dotTrace) e implementar Contadores de rendimiento y consumir aquellos con PerfMon u otro producto de tipo OpManager.

¿Qué recomendarías? ¿La implementación de contadores de rendimiento para una aplicación en tiempo real degradaría significativamente el rendimiento en el sistema de producción? Si no, ¿hay algunas buenas bibliotecas que simplifiquen la implementación en .NET? En caso afirmativo, ¿cómo monitorean las personas el rendimiento de sus aplicaciones que no sea memory-disk-cpu?

---

@Ryan Hayes

Gracias, estoy buscando una manera de ver una inusual ralentización o picos en los sistemas de producción. Por ejemplo, todo fue bueno durante la prueba de estrés, pero por alguna razón, la tercera parte en la que confiamos está teniendo problemas o DB se está desacelerando debido al bloqueo de subprocesos, o la SAN está cediendo, o cualquier otro escenario inesperado. Los perfiles de bajo nivel son demasiados gastos indirectos mientras se encienden los contadores solo cuando hay un problema demasiado tarde en ese punto. Además, nos faltarán datos históricos para compararlo (necesitaría algún tipo de sistema de alerta para cuando el delta está fuera de un umbral aceptable). Me pregunto cómo la gente supervisa el rendimiento de sus sistemas de producción y, en su experiencia, cuál sería el mejor enfoque para el tipo de monitoreo que no es de memoria/cpu/servidor.

Answer 1

La pregunta aquí es realmente ¿qué estás tratando de aprender de la supervisión del rendimiento?

• ¿Quieres hacer su código más rápido? Luego sugeriría usar las herramientas de creación de perfiles en un entorno de prueba para averiguar dónde puede mejorar su código.

• ¿Desea conocer la máxima potencia que su sistema puede manejar? Entonces sugeriría realizar pruebas de carga en un entorno de prueba. Si sabe exactamente cuánto puede empujar su sistema sin destruirlo, entonces no necesitará poner el monitoreo en producción.

Para la producción, es probable que desee maximizar el rendimiento. Para hacer esto, es común impulsar un entorno de prueba y obtener mediciones sólidas para que no tenga que implementar monitores de rendimiento en la producción. Para la producción, solo quieres saber cuándo alcanzas ese pico y luego degradar con gracia o lo que sea que consideres adecuado. En general, un buen registro es la mejor manera de supervisar el rendimiento del sistema (además del hardware) y mantener un registro de excepcionales caprichos de rendimiento.

Sin embargo, cada sistema es diferente y su kilometraje puede variar.Tómese esto como una sugerencia en lugar de hacerlo de la manera en que TODOS lo hacen, porque siempre hay casos excepcionales en los que puede tener que tener perfiles en ejecución.

Answer 2

Puede intentar AlertGrid. Parece que esto puede ser una solución para tus problemas.

Puede enviar varios parámetros a AlertGrid desde su aplicación (nuevo nombre de cuenta, tiempo de ejecución de una parte importante de la lógica, etc.). El servicio AlertGrid puede hacer un par de cosas con sus datos. En primer lugar, puede procesar algunas reglas de notificación creadas con los parámetros que ha enviado (como si fuera el momento de hacer algo importante> X segundos -> enviar sms a la persona a cargo).

En dos semanas, AlertGrid tendrá muchas funciones nuevas. Parece que lo más importante para usted será la posibilidad de trazar parámetros recibidos de su sistema.

Tenga en cuenta que AlertGrid no puede detectar los parámetros de sus sistemas; en su lugar, debe enviarlos. Esto podría parecer una tarea adicional, pero creemos que es comparable al tiempo requerido para instalar y configurar algunas herramientas especializadas. Por otro lado, gracias a este enfoque, AlertGrid supera algunas limitaciones (se puede integrar con cualquier cosa que pueda enviar solicitudes http).

Creo que será mucho más fácil de entender cuando cree una cuenta en AlertGrid y pase su tutorial interactivo.

Como habrá notado que soy un desarrollador de AlertGrid equipo :)

Negación

: Al momment de la escritura sabemos que los precios de AlertGrid van a reducirse en un futuro próximo, por lo que no lo hacen míralos ahora, puedes contactar nuestra línea de soporte para más información sobre precios. La cuenta gratuita está disponible y debería ser suficiente para el comienzo.

Answer 3

Utilizamos Nagios para la supervisión local (CPU, espacio en disco, etc.) y AlertFox para la supervisión de transacciones web ("vista exterior"). Por supuesto, lo último solo tiene sentido si su sitio web (?) Es público.

¿La implementación de contadores de rendimiento para una aplicación en tiempo real degradaría significativamente el rendimiento en el sistema de producción?

Tenemos instalados los plugins de Nagios Win y no vemos problemas de rendimiento con ellos.