logging - starter - ¿Cómo enviar registros en una arquitectura de microservicio con acoplador?

spring boot admin tutorial (1)

Heroku describe los registros en su manifiesto de la aplicación Twelve-Factor como simples secuencias de eventos:

Los registros son la secuencia de eventos agregados ordenados por tiempo recopilados de las secuencias de salida de todos los procesos en ejecución y servicios de respaldo. Los registros en su forma cruda suelen ser un formato de texto con un evento por línea (aunque las trazas de las excepciones pueden abarcar varias líneas). Los registros no tienen un comienzo o un final fijos, sino que fluyen continuamente mientras la aplicación está funcionando.

Además, las aplicaciones simplemente deben escribir registros en stdout , dejando la tarea al "entorno".

Una aplicación de doce factores nunca se preocupa por el enrutamiento o el almacenamiento de su flujo de salida. No debe intentar escribir o administrar archivos de registro. En cambio, cada proceso en ejecución escribe su secuencia de eventos, sin búfer, en stdout. Durante el desarrollo local, el desarrollador verá esta secuencia en el primer plano de su terminal para observar el comportamiento de la aplicación.
En implementaciones de producción o etapas, el flujo de ejecución de cada proceso se capturará en el entorno de ejecución, se recopilará junto con todas las demás secuencias de la aplicación y se enrutará a uno o más destinos finales para su visualización y archivo a largo plazo. Estos destinos de archivo no son visibles ni configurables por la aplicación y, en su lugar, están completamente gestionados por el entorno de ejecución. Los enrutadores de registro de código abierto (como Logplex y Fluent) están disponibles para este propósito.

Entonces, ¿cuál es la mejor manera de lograr esto en un entorno de docker en términos de confiabilidad, eficiencia y facilidad de uso? Creo que me vienen a la mente las siguientes preguntas:

¿Es seguro confiar en el propio recurso de registro de Docker ( docker logs )?
¿Es seguro ejecutar Docker undetached y considerar su salida como la secuencia de registro?
¿Se puede redireccionar a stdout a un archivo directamente (espacio en disco)?
Si está utilizando un archivo, ¿debería estar dentro de la imagen de la docker run --volume=[] acoplable o un volumen encuadernado ( docker run --volume=[] )?
¿Se requiere logrotation?
¿Es seguro redirigir stdout directamente a un logshipper (y qué logshipper)?
¿Es una tubería con nombre (también conocido como FIFO) una opción?
(¿más preguntas?)

Docker 1.6 introduced la noción de controladores de registro para ofrecer más control sobre la salida de registro. El --log-driver configura dónde deben dirigirse stdout y stderr del proceso que se ejecuta en un contenedor. Consulte también Configurar controladores de registro .

Varios controladores están disponibles. Tenga en cuenta que todos estos, excepto json-file desactivan el uso de los docker logs de docker logs para recopilar registros de contenedores.

ninguno - deshabilita los registros del contenedor.
json-file - Se comporta como lo hacía anteriormente, con stdout formateado json disponible en /var/lib/docker/containers/<containerid>/<containerid>-json.log
syslog: escribe mensajes en syslog. También acepta --log-opt para dirigir los mensajes de registro a un syslog específico a través de un socket de dominio TCP, UDP o Unix. También deshabilita los docker logs
journald: escribe en el diario systemd.
* gelf - Formato de registro extendido de Graylog (GELF). Escribe mensajes de registro en un punto final GELF como Graylog o Logstash
* fluentd: envía registros de contenedores a fluentd . Acepta algunas opciones para personalizar la dirección del fluentd y enviar etiquetas con mensajes de registro.
** awslogs: escribe mensajes de registro en AWS CloudWatch Logs

* Nuevo en Docker 1.8

** Nuevo en Docker 1.9

Por ejemplo:

docker run --log-driver=syslog --log-opt syslog-address=tcp://10.0.0.10:1514 ...

Esta es la solución recomendada por Docker para el software que escribe sus mensajes de registro en stdout y stderr . Sin embargo, algunos programas no escriben mensajes de registro en stdout/stderr . En su lugar, escriben en archivos de registro o en syslog, por ejemplo. En esos casos, algunos de los detalles de la respuesta original a continuación todavía se aplican. Recordar:

Si la aplicación escribe en un archivo de registro local, monte un volumen desde el host (o use un contenedor de solo datos en el contenedor y escriba mensajes de registro en esa ubicación.

Si la aplicación escribe en syslog, hay varias opciones:

Envíe al /dev/log del sistema principal del host montando el socket syslog del servidor ( /dev/log ) en el contenedor usando -v /dev/log:/dev/log .
Si la aplicación acepta un punto final syslog en su configuración, configure el daemon syslog del servidor para escuchar a través de TCP y / o UDP en la red del puente Docker, y use ese punto final. O simplemente envíe a un host syslog remoto.
Ejecute un daemon syslog en un contenedor y use enlaces Docker para acceder a él desde otros contenedores en ejecución.
Use logspout para logspout automáticamente registros de contenedores a un registro de sistema remoto a través de UDP

No olvide que cualquier registro dentro de un contenedor debe girarse como lo haría en un sistema operativo host.

Respuesta original para Docker pre-1.6

¿Es seguro confiar en el propio recurso de registro de Docker (registros de docker)?

docker logs imprimen toda la secuencia cada vez, no solo los registros nuevos, por lo que no es apropiado. docker logs --follow le darán la funcionalidad tail -f -like, pero luego tiene un comando CLI del docker ejecutándose todo el tiempo. Por lo tanto, si bien es seguro ejecutar los docker logs , no es óptimo.

¿Es seguro ejecutar Docker undetached y considerar su salida como la secuencia de registro?

Puede iniciar contenedores con systemd y no daemonize, capturando así toda la stdout en el diario systemd que luego puede ser administrado por el host de la forma que desee.

¿Se puede redireccionar a stdout a un archivo directamente (espacio en disco)?

Puede hacer esto con docker run ... > logfile por supuesto, pero se siente frágil y más difícil de automatizar y administrar.

Si está utilizando un archivo, ¿debería estar dentro de la imagen de la ventana acoplable o un volumen encuadernado (ejecutar docker --volume = [])?

Si escribe dentro del contenedor, entonces necesita ejecutar logrotate o algo en el contenedor para administrar los archivos de registro. Es mejor montar un volumen desde el host y controlarlo usando el daemon de rotación de registros del host.

¿Se requiere logrotation?

Claro, si la aplicación escribe registros, debe rotarlos como en un entorno de sistema operativo nativo. Pero es más difícil si escribe dentro del contenedor ya que la ubicación del archivo de registro no es tan predecible. Si gira en el host, el archivo de registro viviría debajo, por ejemplo con devicemapper como el controlador de almacenamiento, /var/lib/docker/devicemapper/mnt/<containerid>/rootfs/... Se necesitaría una envoltura fea para que logrotate encuentre los registros bajo esa ruta.

¿Es seguro redirigir stdout directamente a un logshipper (y qué logshipper)?

Es mejor utilizar syslog y dejar que el recopilador de logs se ocupe de syslog.

¿Es una tubería con nombre (también conocido como FIFO) una opción?

Una tubería con nombre no es ideal porque si el extremo de lectura de la tubería muere, el escritor (el contenedor) obtendrá una tubería rota. Incluso si la aplicación gestiona ese evento, se bloqueará hasta que vuelva a haber un lector. Además, evita los docker logs .

Ver también esta publicación en fluentd con docker .

Consulte el registro de herramientas de Jeff Lindsay que recopila los registros de los contenedores en ejecución y los dirige como desee.

Finalmente, tenga en cuenta que stdout del contenedor se registra en un archivo en el host en /var/lib/docker/containers/<containerid>/<containerid>-json.log .