Spring Boot y el sistema de logging

Logo Spring

Resumen del funcionamiento del sistema de logging en Spring Boot 1.4.0.RELEASE

Principales características

  • Spring Boot utiliza internamente Commons Logging
  • Existe configuraciones para Java Util Logging, Log4J2 y Logback
  • Por defecto se utiliza la Consola para mostrar los logs. Opcionalmente podemos escribir en fichero
  • Logback es el sistema de log utilizado si utilizamos los Spring Boot Starters (spring-boot-starter-parent, etc)
  • Logback tiene niveles ERROR, WARN, INFO, DEBUG o TRACE pero no tiene FATAL
  • Se permite extender el comportamiento de logback mediante extensiones
  • Por defecto se muestran los niveles ERROR, WARN e INFO

Activación del nivel DEBUG

Como cualquier aplicación de Spring Boot podemos activar el nivel de DEBUG como cualquier configuración más. Eso significa que podemos indicarselo como argumento al arrancar la aplicación, como variable de entorno, en el application.properties o application.yml, etc

Es importante mencionar que la activacion del nivel de DEBUG solo afecta internamente a Spring Boot, no a los logs de nuestra aplicación, los cuales los tenemos que configurar mediante otro mecanismo.

Por ejemplo,

En el arranque de la aplicación

$ java -jar my-application.jar --debug

En el fichero application.properties o application.yml

...
debug=true
...
debug: true

Escribir logs a fichero

Por defecto Spring Boot escribe por consola pero opcionalmente le podemos decir que escriba a fichero.

Al igual que la activación del nivel a DEBUG la configuración para activar el fichero de log sigue el mismo principo de configuración de Spring Boot.

Los ficheros rotan por defecto cada 10Mb.

Las propiedades para indicar el fichero donde escribir los logs son:

  • logging.file
  • logging.path

Modificar los niveles de logs de nuestra aplicación o de librerías de terceros

Siguiendo los mismos principios de configuración de Spring Boot la modificación de los nieves de log de nuestra aplicación o de librerías de terceros es bastante fácil.

Por ejemplo,

En el arranque de la aplicación

java -jar my-application.jar --logging.level.org.myapp=DEBUG

En el fichero de configuración application.properties o application.yml

logging.level.org.myapp=DEBUG
...
logging:
   level:
     org:
       myapp: DEBUG

Activar otros sistemas de log

Se acivan por defecto al incluirlos en el classpath.

Podemos forzar a Spring Boot a utilzar un sistema de logging diferente al por defecto, configurando la propiedad de sistema:

org.springframework.boot.logging.LoggingSystem=Nombre completo de la clase que implementa el sistema de logging

o bien desactivar por completo el sistema de logging

org.springframework.boot.logging.LoggingSystem=none

Configuración de estos sistemas de logging

Una vez hemos cambiado el sistema de logging, Spring Boot se encargaría de leer lo ficheros de configuración de esos sistemas, aunque se recomienda que se utilicen la versión para Spring Boot.

Es decir, para los sistemas de logging como

  • log4j2 el fichero de configuración es log4j2.xml
  • Para Java Util Logging el fichero de configuración es logging.properties

pero Spring boot recomienda que utilicemos la versión para Spring Boot que serían respectivamente:

  • log4j2-spring.xml
  • logging-spring.properties
Anuncios

Docker cookbook. Subir una imagen a nuestro Docker Registry privado

Docker Logo

La versión de docker utilizada para ejecutar los comandos de este artículo ha sido docker 1.12.0 en un sistema Ubuntu 16.04.1 LTS

Cuando empezamos a trabajar con Docker una de las primeras cosas que utilizaremos es el Docker Resgitry proporcionado por la gente de Docker y publicado en Docker Hub.

Como sabemos es la imagen utilizada para crear un contenedor donde subiremos nuestras imágenes de nuestros proyectos de forma privada. Eso si, con algunas limitaciones en cuanto a seguridad etc.

Como toda imagen subida a Docker Hub podemos disponer de ella y arrancar nuestro contenedor con un simple comando:

$ docker run -d -p 5000:5000 --name registry registry:2

Los pasos a seguir una vez tenemos nuestra imagen son muy sencillos. Basta con etiquetarla indicando el host del Docker Registry donde tiene que subir:

$ docker tag 5f7ca7e96e33 my-registry:5000/my-image:0.0.1-SNAPSHOT
$ docker push my-registry:5000/my-image:0.0.1-SNAPSHOT
The push refers to a repository [my-registry.com:5000/my-image]
Get https://my-registry.com:5000/v1/_ping:http: server gave HTTP response to HTTPS client

En este momento es cuando nos encontramos con la primera limitación de este Registry. No soporta la seguridad por SSL, y por lo tanto debemos decir a nuestro docker daemon que debe poder comunicarse con my-registry.com de forma no segura.

La configuración que debemos hacer es muy sencilla. Indicar el host de nuestro Registry, reiniciar el daemon y volver a subir la imagen

$ echo '{ "insecure-registries":["my-registry.com:5000"] }' > /etc/docker/daemon.json
$ sudo systemctl restart docker
$ docker push  my-registry.com:5000/my-image:0.0.1-SNAPSHOT
The push refers to a repository [my-registry.com:5000/my-image]
0d84ae38f138: Pushed
c18156f94ccc: Pushed
...
...
0.0.1-SNAPSHOT: digest: sha256:fceb6ceb9277761036ec670c1e23f30a3667441f98c54b4253c94737abb0b418 size: 4482

Montar un entorno con Zookeeper, Kafka y Yahoo Kafka Manager utilizando Docker

Docker Logo

Construir la imagen de “kafka manager docker” para kafka 0.9

Los pasos son los siguiente:

Clonar el repositorio

git clone https://github.com/DockerKafka/kafka-manager-docker.git

Crear un nuevo branch a partir del tag 1.2.7

git checkout -b 1.2.7.mylocal 1.2.7

Modificar el Dockerfile para utilizar los fuentes de Yahoo Kafka Manager con soporte a Kafka 0.9

Editamos el fichero Dockerfile y modificamos

KM_VERSION=1.2.7

por

KM_VERSION=1.3.1.6

Construimos la imagen

docker build -t my-kafka-manager .

Levantar Zookeeper, Kafka y Kafka Manager

docker run -d --name kafkadocker_zookeeper_1  dockerkafka/zookeeper
docker run -d --name kafkadocker_kafka_1 --link kafkadocker_zookeeper_1:zookeeper dockerkafka/kafka
docker run -it --rm --link kafkadocker_zookeeper_1:zookeeper --link kafkadocker_kafka_1:kafka -p 9000:9000 -e ZK_HOSTS=zookeeper:2181 my-kafka-manager

Acceder a Kafka Manager y dar de alta los cluster que queremos gestionar

Accedemos a la interface web en http://host:9000 y damos de alta el cluster que queremos gestionar.

Para ello debemos saber el host y puerto del Zookeeper que estamso utilizando. Si nos hemos fijado en los pasos anteriores el zookeeper es:

Host:puerto = zookeeper:2181

Yahoo Kafka Manager

Urls

Agregaciones y búsquedas en elasticsearch

Elasticsearch

Sabemos que todas las agregaciones se ejecutan en el contexto de una búsqueda y además si queremos podemos utilizar la misma query de agregaciones para devolver una muestra de documentos utilizados para calcular dicha agregación.

Este comportamiento lo podemos modificar. Vamos a ver como.

Devolver los documentos de una query y sobre ellos aplicar una serie de agregaciones.

Esto devuelve una respuesta con:

  • documentos que cumplen la query
  • las agregaciones aplicadas a los documentos resultado de la query

Por ejemplo

GET .../_search
{
    "size" : 10,
    "query" : {
        ...
    },
    "aggs" : {
        "nombre_agg": {
            ...
        }
    }
}

Devolver los documentos de una query y aplicar un filtrado a los documentos antes de aplicar las agregaciones

Esto devuelve una respuesta con:

  • documentos que cumplen la query
  • las agregaciones aplicadas a los documentos filtrados sobre el resultado de la query

Por ejemplo

GET .../_search
{
   "size" : 10,
   "query":{
      ...
   },
   "aggs":{
      "filtro": {
         "filter": { 
            ...
         },
         "aggs": {
            "nombre_agg":{
               ...
            }
         }
      }
   }
}

Devolver los documentos de una query y aplicar a esos documentos un filtro, pero generar las agregaciones sobre los documentos devueltos por la query

Esto devuelve una respuesta con:

  • documentos filtrados que han cumplido la query
  • las agregaciones aplicadas sobre los documentos devueltos por la query

Por ejemplo

GET .../_search
{
    "size" : 10,
    "query": {
        ...
    },
    "post_filter": {    
        "term" : {
        ...
        }
    },
    "aggs" : {
        "nombre_agg": {
            ...
        }
    }
}

docker Cookbook, la resolución de nombres de dominio DNS en la red por defecto bridge

Docker Logo

Como ya sabemos en el fichero /etc/resolv.conf de nuestra máquina tenemos la configuración de los DNS de nuestra organización o empresa, y es lo que nos permite poder resolver los nombres de dominio y máquinas tanto de internet como de nuestra intranet.

Cuando trabajamos con contenedores docker se encarga de configurar estos ficheros en nuestros contenedores.

Comportamiento por defecto

Lo que hace por defecto si no le decimos nada es copiar el fichero /etc/resolv.conf de nuestra máquina en el nuevo contenedor, pero filtrando o eliminando todas las IPs locales.

Una vez realizado el filtrado de todas las IPs locales (es decir, ips como 127.0.1.1), si no queda ninguna entrada de un DNS válido, crea el fichero /etc/resolv.conf con las IPs de los DNS públicos de Google.

Por lo tanto seremos capaces de resolver cualquier nombre de dominio de internet, pero nunca seremos capaces de resolver los nombres de dominio de las máquinas de nuestra intranet.

Así pues si nos encontramos en esta situación, para poder resolver los nombres de dominio o nombres de máquinas de nuestra intranet dentro de un contenedor de docker debemos revisar que exista una IP válida de un DNS de nuestra organización.

Por ejemplo, si tenemos el siguiente /etc/resolv.conf

Sigue leyendo

docker Cookbook, añadir un nombre de dominio o nombre máquina en el fichero /etc/hosts de un contenedor docker

Docker Logo

La opción –add-host

Existen ocasiones donde el nombre de una máquina o el nombre de un dominio no se encuentra en nuestros DNS. En estos casos lo normal es añadir una entrada en nuestro fichero /etc/hosts del sistema operativo.

Cuando trabajamos con contenedores esto lo realizaremos con la opción –add-host al ejecutar el contenedor.

Por ejemplo:

$ sudo docker run -it --name prueba --add-host my-domain.com:127.0.0.1 ubuntu bash
root@9840971d73ef:/# ping my-domain.com
PING my-domain.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.033 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.038 ms
...

docker Cookbook, borrar todas las imagenes en estado dangling

Docker Logo

Cuando utilizamos docker terminaremos viendo imágenes que no están siendo utilizadas y que terminan ocupando espacio.

Al principio no tendremos este tipo de imágenes, pero según vayamos utilizando imágenes de docker o creando imágenes propias terminaremos viéndolas. Estas imágenes las identificaremos por el nombre del repositorio y del tag, que serán

<none>:<none>

y que las veremos lanzando el comando docker images.

$ docker images
REPOSITORY                                         TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
...
<none>                                             <none>              47a4e50d9b35        18 hours ago        669.6 MB
<none>                                             <none>              8e2393b52fd9        18 hours ago        669.6 MB
<none>                                             <none>              8fb173d5c23c        18 hours ago        669.6 MB
<none>                                             <none>              19cb9c21f160        21 hours ago        669.5 MB
<none>                                             <none>              9cf1c0068503        21 hours ago        669.5 MB
<none>                                             <none>              27c02a9fda80        21 hours ago        669.5 MB
<none>                                             <none>              b2d384eb6f23        6 days ago          669.5 MB
<none>                                             <none>              ae0dbc713400        6 days ago          669.5 MB
...

Como vemos por el nombre del repository y del tag tenemos imágenes en estado dangling.

Listado de todas la imágenes en estado dangling

Si queremos ver solamente las imágenes en estado danglin lo podemos hacer con un simple comando.

$ docker images -f "dangling=true"

Borrar todas las imágenes en estado dangling

Y para liberar y recuperar el espacio ocupado por esta imágenes lo haremos igualmente con un comando de docker.

$ docker rmi $(docker images -f "dangling=true" -q)

Referencia

Este artículo lo hemos basado en What are Docker : images?