Skip to main content
Cada servicio dentro del pod de Ayakaleaf Pro escribe su propio archivo de registro en /var/log/overleaf/; kubectl logs solo muestra la salida de arranque del contenedor (scripts de inicialización, migraciones). El bin/logs del Toolkit lee los mismos archivos; consulta Registros.

Leer los registros

Con varias réplicas, cada pod tiene sus propios archivos: usa el nombre del pod (overleaf-0, overleaf-1, …) en lugar de deploy/overleaf. La cabecera X-Served-By que añade HAProxy indica qué réplica respondió a una petición. LOG_LEVEL en el ConfigMap (por defecto info; también debug, warn, error) establece a la vez el nivel de todos los servicios del pod.

Conservar los registros

Los archivos residen en el contenedor y se pierden cuando se reemplaza el pod. Para conservarlos, monta un volumen en /var/log/overleaf, por ejemplo un hostPath en el nodo o un PersistentVolumeClaim, en el Deployment o el StatefulSet:
El contenedor rota los archivos a diario y conserva cinco, por lo que el volumen no crece sin límite. También puedes recogerlos desde esa ruta con el agente de registros de tu clúster.

Probado en Kubernetes

En Kubernetes 1.37 con tres réplicas y un volumen hostPath en /var/log/overleaf como el anterior, el /srv/overleaf-logs de cada nodo contenía los doce registros de servicio de su réplica, y los comandos de la tabla funcionaron como se muestra: tail mediante kubectl exec, kubectl cp de un archivo de registro, kubectl logs del pod de Overleaf (arranque y migraciones) y de mongo-0.
Última modificación el 2 de noviembre de 2026