Cómo monitorizar microservicios con Spring-Boot-Admin.

La mayoría de vosotros ya habréis oído hablar de Spring Boot (y los que no deberíais plantearos seriamente por qué no lo habéis hecho aún). Muchos ya habréis desplegado también alguna que otra aplicación hecha con el mismo en producción. Cualquier proyecto que tengamos en producción deberá tener una monitorización para conocer el estado de nuestra aplicación, los recursos que consume…

En este post hablaremos de Spring-boot-actuator **y S**pring-boot-admin, que nos proporcionarán una amplia cantidad de funcionalidades de cara a gestionar y monitorizar nuestras aplicaciones Spring-boot.

Spring Boot Actuator

Según su propia definición en la documentación de Spring se trata de “una serie de características adicionales que te ayudan a monitorizar y gestionar tu aplicación cuando es desplegada en producción”. En esencia spring-boot-actuator nos proporciona por defecto una serie de endpoints en los que poder consultar información relativa a nuestra aplicación.

Así, por ejemplo, tenemos endpoints para consultar las métricas de nuestra aplicación a través del path /metrics:

O para consultar las propiedades de nuestra aplicación a través de /env

Entre otros, dispone de endpoints para poder consultar el listado de beans definidos en nuestra aplicación, listar los beans de autoconfiguración que tengamos, listar las rutas que hayamos definido, realizar un thread dump, mostrar información de nuestra aplicación, mostrar el estado de nuestra aplicación… Podéis ver aquí un detalle completo de qué endpoints existen y qué información proporcionan.

Los paths de estos endpoints se pueden modificar, así como deshabilitar o securizar a través de propiedades (para securizarlos será necesario añadir también spring-security).

Por ejemplo el endpoint /shutdown que nos permite apagar nuestra aplicación por defecto está deshabilitado, si quisiéramos por ejemplo activarlo, securizarlo y cambiarlo a la URL /apagar tendríamos que incluir las siguientes propiedades:

endpoints.shutdown.enabled=true

endpoints.shutdown.sensitive=true

endpoinst.shutdown.id=apagar

El patrón de propiedades para configurar los diferentes endpoints es: endpoints.[endpoint-name].[enabled | sensitive | id]

Así por ejemplo si quisiéramos deshabilitar el endpoint beans, sería: endpoints.beans.enabled=false

Hay que tener en cuenta que en cuanto incluyamos spring-security en el contexto y lo habilitemos se securizará toda la aplicación, entonces, en lo que respecta a endpoints, si queremos volver a desecurizarlos tendremos que indicar explícitamente la propiedad sensitive de todos los endpoints a false.

La siguiente configuración habilita spring-security, establece que todos los endpoints sean abiertos y luego edita la configuración del endpoint shutdown para cambiarle el path, habilitarlo y securizarlo como comentamos previamente:

Aquí podemos ver el mensaje devuelto por nuestro servidor cuando utilizamos el endpoint shutdown:

A continuación comentaremos más a fondo los endpoints más importantes.

Endpoint de estado

Spring Boot Actuator realiza el control del estado a través del endpoint health. A nivel de implementación Spring nos proporciona unos cuantos HealthIndicator por defecto que serán autoconfigurados según las dependencias de nuestro proyecto. Así tenemos HealthIndicators para dataSources, disco, colas… además de la posibilidad de implementar el nuestro propio y añadirlo a los demás.
Otro de los efectos colaterales de incluir la dependencia de spring-security en nuestro proyecto es la información devuelta por el endpoint de estado. Incluso desecurizando el endpoint se evitará devolver información sensible sobre los elementos que componen el estado de nuestra aplicación.

En estas dos capturas podemos ver la diferencia. Incluso en el caso de una aplicación sencilla donde el único HealthIndicator que tengamos sea el que comprueba el estado de disco, al incluir spring-security dicha información no se incluirá en el endpoint. Es más, incluso el estado se cacheará para prevenir ataques Denial of Service.

Endpoint de métricas

La siguiente captura nos permite ver algunas de las métricas proporcionadas por la librería:

Entre estas métricas podemos ver las referentes a la memoria de nuestra aplicación (mem, mem.free), el java heap (_heap.), el garbage collector (gc.) e incluso el número de estados HTTP que hemos devuelto para cada endpoint (counter.status.200.</em> en este caso solo estados 200).

En nuestro caso se trata de una aplicación sencilla que no accede a ninguna base de datos pero, en caso de hacerlo, también se incluyen métricas del DataSource así como de acceso a caché.

Como os podéis imaginar esto nos permite también otras posibilidades como usar dicho endpoint para recolectar métricas de forma continua para almacenarlas y mantener un histórico de la información de nuestra aplicación. Por suerte no tenemos que implementar dicha funcionalidad ya que Spring ya se encarga de ello. En su documentación explican diversas posibilidades a la hora de exportar estas métricas como Redis, JMX…, pero siempre tenemos la posibilidad de implementar la que nosotros consideremos.

Para finalizar con spring-boot-actuator mencionar que también nos permite muchas más posibilidades entre las cuales se incluyen definir la configuración CORS a través de propiedades, incluir metadatos sobre a qué commit y rama de Git pertenece la construcción de nuestro artefacto o conectarnos de forma remota a nuestra aplicación.

Spring Boot Admin

Estaréis pensando que toda esta información proporcionada por spring-boot-actuator está muy bien, pero que lo que realmente sería interesante es que pudiésemos acceder a toda esa información de forma visual, para eso está spring-boot-admin.

Spring Boot Admin es una herramienta para la monitorización de nuestras aplicaciones Spring Boot. Para los que estéis familiarizados con la arquitectura de microservicios de spring-cloud-netflix añadirla a nuestra arquitectura es algo similar en complejidad a añadir un servidor Eureka, un cloud-config o un Turbine, lo que viene siendo tarea de menos de media hora (y tirando para arriba).

Básicamente la aplicación nos proporciona una interfaz gráfica desarrollada en Angular.js para monitorizar aplicaciones Spring-Boot aprovechando la información proporcionada por los endpoints de spring-boot-actuator.

Para crear nuestro servidor lo único que tendremos que hacer es incluir las dos siguientes dependencias en nuestro build.gradle (o pom.xml según gustos):

compile 'de.codecentric:spring-boot-admin-server-ui:1.3.2'

compile 'de.codecentric:spring-boot-admin-server:1.3.2'

Y anotar nuestra clase Main con @EnableAdminServer. Con esto ya tendremos nuestro servidor de administración, como ya comentamos muy similar a configurar un servidor Eureka, Turbine o un Cloud-Config. Ahora será necesario que nuestras aplicaciones Spring-Boot se registren en él y para ello existen las dos siguientes opciones:

• Incluir la dependencia del cliente: (de.codecentric:spring-boot-admin-starter-client:1.3.2) en nuestra aplicación e indicar en la propiedad spring.boot.admin.url donde se encuentra nuestro servidor o
• Si disponemos de un servidor Eureka aprovechar la funcionalidad de descubrimiento del mismo para consultar de él el listado de aplicaciones. Para ello solo deberemos, una vez más, anotar nuestra clase Main con @EnableDiscoveryClient y establecer la propiedad eureka.client.serviceUrl.defaultZone apuntando a nuestro servidor Eureka. Con esto Spring-Boot-Admin recuperará el listado de aplicaciones de Eureka. Debemos no olvidar incluir también la dependencia de org.springframework.cloud:spring-cloud-starter-eureka.

En nuestro caso, como estamos tratando con arquitecturas de microservicios, utilizaremos esta última aproximación al tener disponible el servidor Eureka.

Pero podemos ir más allá. Si ya tenéis una arquitectura de microservicios podéis pensar “ya tengo dos eureka, un cloud-config, un turbine, un zuul y eso sin contar con los microservicios funcionales ¿De verdad necesito añadir otro microservicios más a mi arquitectura?” Pues no os preocupéis porque spring-boot-admin puede ser incluido en tu servidor Eureka.

Lo único que tendréis que hacer adicionalmente a lo comentado para configurar el servidor es cambiar el path donde se ejecutará (básicamente para que no colisione con la funcionalidad de Eureka) y eso lo podéis hacer con la propiedad spring.boot.admin.context-path. Así ya tendréis la funcionalidad de Eureka y se spring-boot-admin en un mismo servidor.

Es más, las dos aplicaciones tienen un funcionamiento y carga similar, ya que las dos se ejecutan de forma periódica (Eureka cada 30 segundos al recibir los Heartbeat de las aplicaciones y spring-boot-admin preguntando a cada microservicio por su estado e información). Son aplicaciones que aumentan su carga, no por que se realicen más peticiones a tu ecosistema de microservicios, sino por el número de microservicios que tengas desplegados.

Una vez que haya arrancado y haya consultado a Eureka el listado de microservicios nos encontraremos con un Dashboard como el siguiente:

La versión de nuestra aplicación se establece a través de la propiedad info.version y en este caso hemos decidido añadir una descripcion para la sección Info, añadiendo la propiedad info.Description. Si desplegamos en el botón “Details” podremos acceder a las siguientes secciones para cada una de nuestras aplicaciones:

Details

Como su nombre indica son los detalles de la aplicación y ahí podremos encontrar estado, consumo de memoria y heap, estadísticas del garbage collector...

Environment

En la pantalla de Environment podemos ver el perfil con el que se ejecuta la aplicación, las variables de sistema y propiedades, así como modificarlas.

Logging

En esta pantalla podemos ver el nivel de log de las diferentes clases y librerías que componen nuestra aplicación, así como cambiar su nivel de log en caliente. Para ello es necesario añadir la dependencia de jolokia:

compile 'org.jolokia:jolokia-core:1.3.3'

También hay que añadir la siguiente línea en nuestro fichero de configuración de logback:

IMPORTANTE: esta funcionalidad solo es compatible actualmente con logback, no funcionará con otras librerías de log.

JMX

Beans JMX de tu aplicación:

Threads

En esta sección podremos hacer un dump de todos los threads de nuestra aplicación así como ver sus detalles:

Trace

En la pantalla Trace podremos trazar todas las peticiones realizadas a nuestra aplicación, así como información detallada de las mismas:

Para terminar, comentar otras de las posibilidades que nos da como las siguientes:

• Podemos configurar spring-boot-admin como cluster utilizando Hazelcast. Una vez más la configuración es muy sencilla gracias a la autoconfiguración.
• Podemos configurar el envío de notificaciones por correo cuando el estado de alguna aplicación cambie.

Conclusión

Actualmente existen un montón de soluciones para monitorizar aplicaciones, algunas de pago, algunas gratuitas, pero lo que está claro es que cualquier aplicación un poco seria que se despliegue en un entorno de producción debe ser monitorizada.

Spring-boot-actuator, en conjunto con Spring-boot-admin, nos proporcionan una potente solución para, no solo monitorizar, sino también gestionar nuestras aplicaciones Spring-boot. Lo realmente sencillas de añadir y configurar que son y la cantidad de información y funcionalidad útil que aportan, los convierte en una solución imprescindible a añadir para monitorizar tus aplicaciones con spring-boot ya tengas una arquitectura de microservicios o no, incluso aunque dispongas de otras soluciones de monitorización.