Monitorizar una aplicación GeneXus .NET con APM: NewRelic vs Dynatrace

No hay duda que cuando uno quiere monitorizar una aplicación, para analizar y mejorar la performance, ya sea en ambientes de testing o de producción, los APM (Application Performance Management) facilitan muchísimo la tarea, dando una consola única con toda la información disponible en forma ordenada, navegable, integrada. En este post quiero resumir mi experiencia para un tipo de aplicación particular, veremos cómo monitorizar una aplicación GeneXus, y en particular generando .NET.

Luego de probar varias herramientas, finalmente mi conclusión fue que Dynatrace me permitió acceder a la información que necesitaba, mientras que con NewRelic tuve bastantes problemas y no me sirvió para lo que quería. Ojo, no es una evaluación genérica, insisto en que esto está enfocado para aplicaciones GeneXus generando .NET.

Antes de ir a la comparación, tal vez mejor comentar un poco más de la necesidad particular. Quisiera poder identificar los programas GeneXus que tienen problemas de performance. En Java típicamente usamos JMX para esto, ya que GeneXus provee de MBeans específicos que brindan información muy buena, pudiendo ver cuáles fueron las peores SQL y de ahí llegar a qué programas las ejecutaron. En .NET esta información no está disponible por WMI (por más que la documentación de GeneXus indica que sí está, no pudimos encontrarla ni hacerla funcionar). De ahí fue que buscamos otras alternativas, y en particular un APM  ya de paso nos da muchísima más información para analizar.

En la comparación a continuación, me centro en las versiones gratuitas de ambas herramientas, y lo hice pensando en encontrar problemas al ejecutar pruebas de performance (recomiendo leer sobre cómo planificar una prueba de performance, y de cómo el tester en su rol de QE debería ir tomando conocimiento de todas estas herramientas y metodologías).

Instalación

En ambos casos hay que crearse una cuenta en el sitio del APM:

• NewRelic (gratis solo por 14 días y además, está limitado en tiempo de retención de datos y en funcionalidades, tiene productos separados para monitorización de servidores y monitorización de aplicación, con lo cual habría que instalar distintos agentes y registrarse a distintas trials para cada producto).
• Dynatrace Personal License (permite tener hasta 5 servidores gratis de por vida, sin límites en funcionalidad ni en retención de datos, limitado a 100k visitas).

En ambos casos, luego del registro, se instala un agente en el servidor donde está la aplicación que se desea monitorear, en este caso, donde está el Internet Information Services (IIS).

En el caso de Dynatrace el proceso de instalación fue más simple y funcionó sin problemas. En NewRelic fue necesario ajustar algunas cosas en el archivo de configuración del agente. En ambos casos fue necesario reiniciar el IIS donde estaba la aplicación.

Comentarios sobre NewRelic

La versión gratis de NewRelic está muy recortada, para cualquier cosa que se desee ver en detalle, generalmente pide pasarse a la versión Essential o Professional. Al acceder se puede ver un pantallazo que resume el estado de la aplicación:

Algo muy interesante es el concepto de “transactions”, donde muestra fácilmente cuáles son las URLs más lentas, y de ahí se puede acceder a ver todas las SQLs ejecutadas.

 

 

Lo más importante, NewRelic no instrumenta a nivel de código .NET generado por GeneXus, lo cual no logré determinar si es por alguna tecnología utilizada por GeneXus o por qué. Como se puede ver en la siguiente imagen, puedo acceder al detalle de la traza de una URL que se identificó como lenta (29,5 segundos) y veo todas las SQLs ejecutadas, pero el código me indica “Application Code (in Transaction)”. Típicamente NewRelic en este lugar debería mostrar el call stack, incluyendo tiempos de ejecución de cada método, pero en este caso me dice que no tiene información suficiente.

 

El impacto que tiene esta limitante en el análisis, es más que nada en los casos que un objeto llama a otros (eso se da en la mayoría de los casos, supongo). Por ejemplo, en una aplicación GeneXus que utilice GXflow, no me alcanza con ver la URL que respondió lento, ya que ese objeto por ejemplo será el workflowclient. Este objeto seguramente llamará a otros de mi lógica, y esos son los que quiero analizar. Entonces, solo mirando la URL no tengo más información que el objeto raíz al que está invocando el usuario, y no puedo ver cómo otros objetos influyen en el tiempo de respuesta del resultado.

Tampoco puedo darme cuenta fácilmente mirando la SQL, porque no siempre es tan directo identificar el programa GeneXus que ejecuta cada SQL, y menos sobre tablas del Workflow (tal vez esto se deba a mi poca experiencia programando GeneXus, se aceptan comentarios).

Para que NewRelic pueda instrumentar el código .NET que no instrumenta automáticamente, hay que explicitarlo en un XML con un mecanismo de custom instrumentation. En una aplicación GeneXus esto no es muy práctico, porque uno de primera mano no sabe cuáles son los métodos generados que son interesantes de monitorizar e instrumentar. Esto es algo que es necesario que sea automático, y no lo pude ver en NewRelic (estuvimos intentando bastante, e incluso trabajando con gente de soporte de NewRelic y no lo logramos).

Por otra parte, NewRelic tiene la posibilidad de hacer Thread profiling, lo cual se debe activar por un tiempo limitado ya que consume recursos excesivamente (como todo profiler). La limitante también se ve acá, ya que el thread profiler me muestra algo que no agrega valor en absoluto como se ve a continuación:

 

Comentarios sobre Dynatrace

Quedé fascinado a los 5 minutos. Automáticamente detectó todo lo que hay en el servidor donde instalé el agente, y comenzó a registrar información a distintos niveles: sistema operativo, red, base de datos, código, incluso métricas a nivel de usuario, viendo cuánto tarda en cargarse la página (¿¡cómo hizo esto sin que yo configurara nada!?).  La siguiente imagen muestra el dashboard inicial (lo instalé en un servidor de pruebas donde tenemos el AjaxSample, ¡gracias Andrei por instalarlo!):

 

 

Lo más positivo es que sin ninguna configuración ni ningún problema, me detecta cuáles son las URLs más lentas, y me muestra el desglose del tiempo, cuánto se lo llevó el IIS, cuánto el código (y puedo ver qué métodos demoraron cuánto), las SQLs ejecutadas, etc. También muestra cuánto CPU fue utilizado por cada método, las dependencias entre los distintos elementos y mucho más.

 

 

 

 

 

 

 

 

Y ahora la parte más interesante, poder ver de un request en qué se va el tiempo de respuesta:

 

 

En esa imagen se ve que parte se fue en la base de datos, parte en el servidor de aplicaciones, e incluso puedo ver que parte se fue en obtener una conexión a la base de datos. Si miro más abajo para ver el detalle, puedo ver el call stack:

 

 

Además de esto, también permite ver detalles del IIS muy interesantes, como el CPU consumido, la memoria en los distintos heaps, el tiempo de Garbage Collection, las threads, etc. También deja accesibles los distintos logs para poder descargarlos o verlos en la web.

 

 

 

Con toda esta información deberíamos ser capaces de obtener suficientes pistas como para encontrar los problemas y solucionarlos.

El problema que le vi, es que la navegabilidad es un poco más complicada. A veces uno se pierde, y le cuesta volver a encontrar esa vista, esa gráfica donde se veía tal y cual cosa, de ajustar el filtro… pero es cuestión de habituarse a la herramienta.

 

Conclusión y futuro

Si van a monitorizar una aplicación GeneXus generando en .NET, vayan por Dynatrace y no por NewRelic. Me falta probar qué pasa en Java, ya que en otros casos NewRelic nos ha dado buena información para ese tipo de entornos.

Me falta ver también qué tal se comporta esto en ambientes de producción y no de testing, cuando hay problemas de verdad y uno quiere encontrar rápidamente los problemas entre muchísimos datos.

¿Tenés alguna experiencia para compartir?