Spring Insight: Aplicaciones Java en tiempo real.

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.

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

• ¿Qué es necesario para que mi aplicación sea monitorizada por Insight? La respuesta es nada. Insight corre bajo un Apache Tomcat “modificado”, el cual mediante técnicas de programación orientada a aspectos, permite disponer de un ClassLoader especial que se encarga de instrumentar el código en tiempo de ejecución. Por tanto, el único requisito es que tu aplicación sea 100% estándar con la especificación de Servlets oportuna.
• ¿Es necesario que mi aplicación esté realizada con Spring? No, aunque sí es cierto que la mayoría de plugins que incorpora la plataforma están pensados para aplicaciones con arquitectura Spring. De hecho, nuestro ejemplo funciona con endpoints asociados a la tecnología Spring MVC. Ahora bien, y aquí reside la magia de la plataforma, Insight viene con un kit para desarrolladores que te permite construir de una manera relativamente sencilla tus propios plugins; por tanto, si tu aplicación está desarrollada con otras tecnologías, por qué no contribuir al proyecto con plugins que permitan monitorizar, como por ejemplo Struts2.
• ¿Con qué plugins viene la plataforma por defecto? Actualmente viene con los siguientes:
  • Gestor de endpoints con SpringMVC. Permite organizar las peticiones por los distintos métodos de un controller de SpringMVC.
  • Gestor de endpoints con Servlets. Igual pero para peticiones directamente gestionadas por un servlet.
  • Grails. Permite monitorizar una aplicación desarrollada con Grails.
  • GWT. Permite monitorizar comportamiento de componentes desarrollados con GWT.
  • JDBC. Permite monitorizar las sentencias JDBC lanzadas sobre una BBDD.
  • Spring- Core. Monitorización de clases anotadas con la anotación @Service (capa de servicio), @Repository (Capa de acceso a datos).
  • Spring-Tx. Permite monitorizar los componentes encargados de ofrecer la gestión de la transaccionalidad de nuestra aplicación.
  • Más información, en la sección de plugins del manual de referencia.
• ¿Qué conocimientos son necesarios para desarrollar plugins con Insight? Los siguientes:
  • Conocimientos de AspectJ. Dentro de los distintos componentes necesarios para desarrollar un plugin, es necesario definir aspectos, los cuales se encargan de definir la lógica de intercepción de los métodos de la aplicación. Así, por ejemplo, si queremos realizar un plugin que trace las sentencias JDBC, deberemos crear los endpoints necesarios para definir qué métodos son los que finalmente ejecutan las sentencias JDBC y por tanto, quiero monitorizar.
  • Conocimientos de la arquitectura de Spring Insight. En definitiva, saber qué es un endpoint, qué es un frame, un trace. Con este conocimiento, podrás implementar EndPointAnalyzer encargados de gestionar los endpoints de Insight, en base a trazas semánticamente relacionadas (básicamente en una aplicación web, la capa controladora). En la integración con un sistema externo, la invocación de los distintos métodos de la capa de servicio que ofrece dicho sistema externo, etc… Conocer cómo el aspecto encargado de interceptar llamadas debe crear operaciones (Operation – artefacto básico de la arquitectura Insight) que permitan trazar la información de ejecución (SQL ejecutada), parámetros asociados; en definitiva la información de ejecución de la traza.
  • Conocimientos básicos de Freemarker. La información que reside en un componente Operation permite renderizar la información asociada dentro de la herramienta.
  • El resto de lógica: instrumentación, monitorización de tiempos de respuesta, etc.. son ofrecidas directamente por la plataforma, ocultando toda esta complejidad al desarrollador de plugins.

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.