¿Cómo evitar que los registros de Docker llenen la unidad de arranque del equipo anfitrión?
Detén el productor de registros inmediato, identifica el destino de registros activo, aplica una rotación con límites y corrige el error o el bucle de reinicios que está generando la avalancha.
En un NAS o servidor doméstico basado en Docker, la unidad de arranque puede llenarse aunque los archivos multimedia y las bases de datos estén en otro conjunto de almacenamiento, porque la salida estándar y de error de los contenedores, los datos del registro de systemd y los archivos nativos de las aplicaciones pueden seguir almacenándose en el sistema de archivos del sistema. La secuencia segura consiste en conservar suficientes pruebas recientes, detener el crecimiento descontrolado, determinar qué capa de registro ocupa el espacio, configurar la retención para los servicios existentes y futuros, y verificar que la aplicación subyacente ya no genere el mismo volumen.
Localiza el almacén de registros que realmente está creciendo
Comprueba el espacio libre del sistema de archivos de arranque y compara el tamaño de la raíz de datos de Docker, los archivos de registro de cada contenedor, el registro del sistema y los directorios de registros de las aplicaciones montados desde el host. Registra las rutas más grandes antes de eliminar o truncar cualquier elemento.
Un caso de falta de espacio en disco de Docker reveló que los resúmenes normales de Docker no mostraban el principal consumidor porque el archivo de registro predeterminado crecía por separado. La evidencia decisiva fue un registro de contenedor que crecía continuamente en la ruta de almacenamiento local de Docker.
Inspecciona el controlador de registros y la ruta de registro configurados para cada contenedor en ejecución, y relaciona el archivo más grande con el nombre del contenedor y los mensajes recientes. Si ningún registro de contenedor explica el uso, continúa con journald y las carpetas nativas de la aplicación en lugar de asumir que todo problema de disco relacionado con Docker pertenece a json-file.
Detén el contenedor ruidoso antes de realizar una limpieza de emergencia
Cuando la unidad de arranque esté casi llena, pausa o detén el contenedor que produzca el crecimiento más rápido. Guarda una cantidad limitada de las últimas líneas del registro, su contador de reinicios, estado de salida, versión de la imagen, entorno, montajes y el primer error repetido antes de recuperar espacio.
Los administradores suelen descubrir que los registros JSON de los contenedores pueden consumir el espacio restante del disco cuando no hay un límite de tamaño configurado. Una extensa discusión de Stack Overflow identifica el crecimiento ilimitado de los registros JSON como un riesgo de capacidad independiente de los datos de imágenes y volúmenes.
No elimines un archivo de registro activo a ciegas mientras Docker aún lo tenga abierto y nunca borres directorios arbitrarios del árbol de metadatos de Docker. Utiliza el procedimiento de rotación o truncado compatible con la plataforma solo después de detener el productor y confirma que los bloques recuperados sean visibles antes de reiniciar cualquier servicio afectado.
Aplica una rotación con límites a cada servicio de larga duración
Establece un controlador de registros explícito y límites de rotación finitos en el servicio de Compose o en la configuración del contenedor. Para el controlador JSON habitual, los controles importantes son un tamaño máximo de archivo y un número limitado de archivos conservados.
Un hilo de la comunidad de Docker explica que opciones como max-size y max-file limitan la cantidad de historial local que conserva cada contenedor. El requisito operativo es una política de rotación finita, no un único archivo que crezca indefinidamente.
Elige los límites según la rapidez con la que deba diagnosticarse un incidente y la cantidad de espacio de la unidad de arranque que el host pueda reservar de forma segura. Recrea el servicio para que el contenedor en ejecución reciba la nueva configuración de registros, inspecciona sus ajustes efectivos y realiza una pequeña prueba controlada para demostrar que los archivos rotan como se espera.
Establece valores predeterminados para futuros contenedores sin asumir que cambiarán los existentes
Configura un valor predeterminado de nivel de daemon o plataforma para los contenedores nuevos, de modo que una configuración de servicio omitida no vuelva silenciosamente al registro local ilimitado. Permite que los servicios críticos utilicen una configuración más restrictiva cuando sus necesidades de diagnóstico sean diferentes.
Cambiar el valor predeterminado de registro de Docker no reescribe de forma retroactiva la configuración de cada contenedor existente en el host. La misma recomendación de la comunidad distingue entre los valores predeterminados del daemon y la configuración aplicada al crear cada contenedor, por lo que los servicios antiguos deben inspeccionarse y recrearse deliberadamente.
Aplica el cambio primero a un servicio no crítico. Confirma que la consulta de registros, la supervisión, las alertas y los flujos de trabajo de soporte sigan funcionando; después, recrea los servicios restantes en lotes controlados sin eliminar sus volúmenes persistentes.
Corrige el evento que produce la avalancha de registros
Los límites de rotación reducen los daños, pero no reparan un contenedor que se reinicia cada pocos segundos, reintenta conectarse a una base de datos inaccesible, registra cada comprobación de estado, recibe un ataque o una avalancha de solicitudes, o quedó en modo de depuración después de solucionar un problema.
Un usuario de Docker atribuyó un registro JSON de aproximadamente 80 GB a una salida de depuración excesiva, lo que ilustra cómo la salida de nivel de depuración puede saturar una unidad de arranque incluso cuando la rotación es la protección inmediata.
Agrupa los mensajes repetidos por frecuencia y primera marca de tiempo y, después, corrige el error raíz más antiguo. La guía de ZimaSpace para encontrar la dependencia que causa un bucle de reinicios es el siguiente paso de diagnóstico cuando los fallos de conexión, montaje, secretos o disponibilidad generan la avalancha de registros.
Controla por separado los registros de Docker, journald y las aplicaciones
Un contenedor puede enviar la salida estándar a Docker y, al mismo tiempo, escribir sus propios archivos en un montaje enlazado; además, el servicio de Docker puede enviar eventos del daemon a journald. Cada destino tiene un responsable de retención diferente y puede llenar el mismo sistema de archivos de arranque de forma independiente.
Los operadores de servidores domésticos han informado de que los directorios de registros de las aplicaciones crecen pese a esperar que la rotación de nivel de Docker los contuviera. Un caso de la comunidad de TrueNAS destaca la necesidad de identificar qué capa de registro controla la retención antes de ajustar los límites.
Registra una referencia posterior a la corrección del uso del disco de arranque, los archivos de registro más grandes, el tamaño del journal, los contadores de reinicios de los contenedores y el crecimiento diario. La reparación solo estará completa cuando cada destino activo tenga una política con límites, el servicio ruidoso permanezca estable con su carga de trabajo normal y un reinicio deliberado no vuelva a crear archivos ilimitados.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
