Dentro de Paradigma Clinic tenemos el firme propósito de recopilar un conjunto de herramientas que permitan monitorizar el estado de una aplicación. Como ya comenté en mi post sobre Sonar, hay tres variables que son relativamente dejadas de lado en el desarrollo de software de aplicaciones: análisis de la calidad del código, profiling de la aplicación en busca de cuellos de botella y memory leaks, y pruebas de carga y estrés que permitan estudiar la escalabilidad que presenta la aplicación. Una vez presentado Sonar como herramienta para el análisis de la calidad del código, a continuación presento las bases de la última tecnología de Spring dentro del ámbito de monitorización de las aplicaciones: Spring Insight.

Resultado de imagen de spring insight

Formas de monitorización tradicionales

Las herramientas de profiling nos permiten, en un entorno de desarrollo, aislar parte del código para estudiar posibles problemas de rendimiento y de memoria en la ejecución de nuestras aplicaciones Java. Para ello se usa herramientas llamadas profilers, que consisten básicamente en la instrumentación del bytecode de la aplicación, incluyendo código extra que permite la monitorización del tiempo de ejecución y uso de memoria del código Java.

Estos procesos normalmente requieren de unas altas prestaciones en la máquina donde se realiza el profiling, para poder soportar todo el “extra” que imponen dicho proceso de profiling.

JMeter, como herramienta de referencia para las pruebas de carga/estrés, te permite disponer de la infraestructura necesaria para proporcionar entornos de peticiones simultáneas masivas y distribuidas, permitiendo obtener información de tiempos de respuesta y throughput que soporta una aplicación Java.

Si unimos esta tecnología con herramientas del estilo JConsole, nos permite asociar las pruebas de carga y estrés con los patrones de uso de CPU y memoria, detectando así patrones que permiten garantizar si un sistema es escalable o no. El problema de este tipo de herramientas radica en que las pruebas realizadas son de caja negra (end-to-end), puesto que al final esta tecnología no permite analizar el comportamiento de los distintos componentes de la arquitectura de ejecución de la aplicación.

Por tanto, ante un determinado cuello de botella o memory leak, es necesario complementar nuestro análisis con las herramientas de profiling arriba mencionadas que permiten descubrir los verdaderos motivos del potencial problema.

Monitorización caja blanca

¿Dónde me ayuda Spring Insight? Precisamente en este punto. La plataforma Spring Insight nos permite disponer de información acerca de cómo los distintos componentes de la arquitectura se están comportando en un escenario de prueba de carga y estrés.

Así por ejemplo, con esta tecnología puedo saber cuánto tiempo del procesamiento de una petición se ha destinado en la capa de persistencia (sentencias JDBC contra la base de datos), cuánto tiempo de la petición total se ha destinado a la capa de aplicación o de control (controladores de Spring MVC/Struts/Grails), cuánto tiempo se ha destinado en la capa de servicio, en resolver la vista, en renderizar la vista, etc.

En definitiva me permite, de un simple vistazo, analizar el comportamiento de los distintos elementos de la arquitectura y permitir descubrir, de una manera más eficaz, cuál es el elemento activo que provoca un cuello de botella o una falta de rendimiento en la aplicación:

Vayamos de izquierda a derecha y de arriba abajo. En la sección “Resources” podemos ver las distintas aplicaciones desplegadas en el servidor de monitorización. Cada una de las aplicaciones presenta un conjunto de endpoints (según la terminología Spring Insight) que no dejan de ser peticiones semánticamente relacionadas.

Así, en el caso de una aplicación con Spring MVC, estos endpoints se corresponden con los distintos métodos de una acción de Spring MVC (controlador). Esto nos permite agrupar las distintas peticiones que llegan al servidor en función de los diferentes métodos de control que ofrece la capa de aplicación.

Como se puede ver en la imagen, Insight ofrece una gama de colores que permite evidenciar si los tiempos de respuesta de los distintos endpoints son adecuados o no.

A la izquierda de la imagen nos encontramos un gráfico del timeline con los tiempos de respuesta asociados al endpoint y dentro de éste todas las peticiones (trazas en terminología Insight) de dicho endpoint agrupadas. Así, por ejemplo en el caso de la imagen, los tiempos de respuesta están asociados al método finder del controlador encargado de buscar la entidad “Curso” por el atributo “nombreCurso” usando el operador like (findCursoesByNombreCursoLike) para realizar la búsqueda.

Como se puede, pasamos de una traza con tiempos de respuesta entre 500 y 750 ms a otra que se mueve en el intervalo de 0-50 ms. Adicionalmente, se puede ver una gráfica con el número de peticiones (trazas) por minuto que se producen asociadas con el endpoint. Esta gráfica nos da información del número de peticiones simultáneas que se producen en un determinado intervalo de tiempo.

A continuación, podemos ver una gráfica con la “salud” asociada al endpoint (en definitiva, es una barra con colores asociados a los tiempos de respuesta de las distintas ejecuciones). Como se puede ver, de las 14 peticiones tan solo una se ha mantenido con color amarillo (tiempo de respuesta tolerable (comentar que estos márgenes son configurables en la herramienta). Finalmente se nos ofrece unas estadísticas asociadas con los tiempos de respuesta: media, desviación típica, percentil 99% (peor de los casos).

Como apoyo a esta información, la herramienta presenta un histograma de tiempos de respuesta, donde se puede ver, en un simple vistazo, cómo se comporta los tiempos de respuesta para un determinado endpoint.

En la parte inferior de la gráfica, se puede observar las distintas trazas de ejecución asociadas al endpoint, así como una sección destinada al detalle de la traza. Es en esta sección, se puede observar el tiempo que ha destinado la petición en el componente controlador, qué tiempo ha destinado en la ejecución de sentencias SQL (JDBC), qué tiempo en resolver la vista, en la renderización de la vista, etc.

En definitiva, me da una radiografía de grano “fino” con un diagnóstico de cómo se comportan en ejecución los distintos componentes intervinientes de la arquitectura. La herramienta permite, dentro de un elemento de la traza, obtener información asociada a la misma; así, en el caso de una sentencia JDBC, se puede observar la sentencia SQL y los parámetros asociados a la misma.

Algunas preguntas

Conclusión

Espero no equivocarme, pero aunque Spring Insight es una tecnología incipiente, las posibilidades y bases tecnológicas sobre las que se soporta permitirá que sea una herramienta con mucho potencial. Vaticino que va a haber en el futuro numerosos proyectos Open Source que permitirán desarrollar un conjunto de plugins específicos para los distintos productos de referencia en las arquitecturas J2EE: Struts2, Hibernate, Ibatis, JSF, etc. y lo que es más importante, nos ofrece al mundo del desarrollo una herramienta que, combinadas con otras -profiling, herramientas de estrés, calidad del código, etc- nos permite descubrir qué pasa por nuestras aplicaciones de una manera más transparente que en el pasado.

Aplicaciones como Insight me hacen reflexionar que el ecosistema Spring es una apuesta de éxito. Todavía no conozco una solución ofrecida por SpringSource que me haya decepcionado y que el tiempo la haya sacado del primer panorama del estado del arte en tecnología Java. Siento mucho decir esto, pero cada vez me decanto más por la tecnología abierta, y menos por los estándares que va marcando el lado más formal de la plataforma Java.

That’s all folks.

Cuéntanos qué te parece.

Enviar.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.