Cómo tener múltiples secuencias de registro en Docker

Tenemos una aplicación que escribe tres tipos de registros en tres archivos separados: registros de acceso, registros de aplicaciones genéricas y registros del sistema. El formato (y el propósito) de estos registros son muy diferentes. Y tenemos reenviadores de registros separados que los envían por separado a nuestro sistema de registro centralizado.

Basado en el principio de registros de tratamiento como secuencias de eventos , estamos pensando en pasar del uso de archivos a stdout. Si bien conocemos algunos de los beneficios de este enfoque, esto también significaría que obtendríamos una secuencia fusionada de los registros con un formato diferente, que tendríamos que dividir nuevamente antes de poder enviarlos a nuestro sistema central (Kibana / Splunk / etc.), o dentro de allí.

Nos preguntamos si hay herramientas o recomendaciones sobre cómo debemos abordar esta situación.

docker logging

— SztupY
fuente

No creo que valga la pena. ¿Por qué trabajar más duro para fusionar y luego dividir las secuencias de registro, solo por algún "principio"? Los archivos son buenos. Los archivos funcionan. Esto suena excesivamente diseñado. Diría que tal vez canalice todos los registros en syslog, con diferentes etiquetas, etc., pero debo decir que si alguien en mi equipo sugiriera esto ... estaría ... decepcionado.

— Assaf Lavie

Porque el uso de archivos tiene otros tipos de pesadillas de administración, especialmente si se generan desde el interior de un contenedor acoplable. Por ahora, parece que las desventajas de cambiar a stdout superan los beneficios para nuestro caso de uso, pero ya estamos teniendo problemas con nuestro enfoque basado en archivos

— SztupY

No sé sobre "pesadillas". Sé que así es como se ha hecho durante un tiempo, y hay mucho software por ahí que te ayuda a hacer esto. Los archivos de registro se rotan, se leen con puntos de control; un archivo es una gran abstracción para esto. No compraría un principio que me venda nuevas pesadillas por temor a patrones viejos y familiares. Sus registros de anotaciones se escriben en un archivo o se manejan en la memoria (al menos mientras se muevan en el contenedor). Buena suerte al lograr la confiabilidad de los archivos de registro con divisores y fusiones de flujo en memoria.

— Assaf Lavie

@AssafLavie Debería escribirlo en una respuesta que pueda ser votada. En mi humilde opinión es un punto de vista perfectamente válido.

— Dan Cornilescu

Vine aquí con la misma pregunta. El hecho simple es que la funcionalidad de registro incorporada de Docker depende de que todo vaya a stdout / stderr, por lo tanto, el controlador de registro y el ecosistema de herramientas de terceros que se acumulan a su alrededor también lo hacen. Estoy tentado a volcar todos mis registros en un volumen de host también, pero sé que voy a tener que seguir y administrar eso cuando mis contenedores se muevan a k8s o openshift o gke o lo que sea, mientras que si sigo el docker El enfoque estándar será mucho más suave. Mientras tanto, seguiré buscando una respuesta a esta pregunta legítima

— Ruibarbo

Respuestas:

Todavía estoy buscando un enfoque de fusión / división, pero mientras tanto este enfoque recomendado por la documentación de Kubernetes parece una buena solución: use un contenedor de sidecar para cada uno de sus registros separados .

Un "sidecar" es cualquier contenedor acoplable que use junto con otro contenedor acoplable para trabajar de alguna manera. En este caso, para cada uno de sus tres registros, tendría un contenedor separado que escanea o sigue los registros y las salidas a stdout.

De esta manera, cada uno de sus contenedores de registro lateral tiene su propio registro de acoplador de su propio stdout. Al estar separado de esta manera, puede usar las prácticas estándar de acoplador (y kubernetes, etc.) para separar o agregar. Esto es lo que la página de Kubernetes tiene que decir:

Este enfoque le permite separar varias secuencias de registro de diferentes partes de su aplicación, algunas de las cuales pueden carecer de soporte para escribir en stdout o stderr. La lógica detrás de la redirección de registros es mínima, por lo que no es una sobrecarga significativa. Además, dado que stdout y stderr son manejados por el kubelet, puede usar herramientas integradas como los registros de kubectl.

Las "secuencias de registro separadas" provienen del etiquetado incorporado que la ventana acoplable aplica a registros de diferentes contenedores, descritos en la documentación de la ventana acoplable aquí:

La opción de registro de etiquetas especifica cómo formatear una etiqueta que identifica los mensajes de registro del contenedor. Por defecto, el sistema usa los primeros 12 caracteres de la identificación del contenedor. Para anular este comportamiento, especifique una opción de etiqueta

— Ruibarbo
fuente

Vale la pena mencionar la desventaja de este enfoque de log-sidecar-container, cita: "Tenga en cuenta que, a pesar del bajo uso de CPU y memoria, escribir registros en un archivo y luego transmitirlos a stdout puede duplicar el uso del disco". Me pregunto si alguien intenta este enfoque en la práctica.

— Yusong

La idea de fusionarlos en una secuencia solo para dividirlos más tarde suena dolorosa. No he tenido una razón para hacerlo yo mismo, pero aquí es donde comenzaría:

Cuando ejecute el contenedor acoplable, cree un volumen de modo que sea fácil ver / enviar registros desde el host.
Use algo como remote_syslog2 para enviar los registros a su recopilador de registros

Se siente un poco menos que elegante tener que configurar algo en el host también, pero si usa algo como ansible donde puede ejecutar un libro de jugadas y configurarlo durante su implementación en la caja, no debería ser demasiado malo.

— bradym
fuente

Esta solución se puede combinar con tuberías con nombre, el único problema con las tuberías con nombre es que no funcionan en todos los sistemas en este momento. No funcionan en Mac

— Jens