> ## Documentation Index
> Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Log

> Leggi, copia e conserva i log di un deployment Kubernetes.

Ogni servizio all'interno del pod di Ayakaleaf Pro scrive il proprio file di log in `/var/log/overleaf/`; `kubectl logs` mostra solo l'output di avvio del container (script di inizializzazione, migrazioni). Il comando `bin/logs` del Toolkit legge gli stessi file, vedi [Log](https://ayakaleaf-pro.mintlify.site/it/on-premises/configuration/overleaf-toolkit/logging.md).

| Dove | Cosa |
| - | - |
| `kubectl -n overleaf logs <pod>` | avvio: controllo dei secret, migrazioni (`Finished migrations`), avvio dei servizi |
| `/var/log/overleaf/<service>.log` nel pod | `web.log`, `web-api.log`, `clsi.log`, `real-time.log`, `document-updater.log`, `docstore.log`, `filestore.log`, `history-v1.log`, `project-history.log`, `chat.log`, `notifications.log`, `linked-url-proxy.log`, e `third-party-datastore.log` con Dropbox attivo |
| `/var/log/nginx/` nel pod | `access.log`, `error.log` del nginx posto davanti ai servizi |
| `kubectl -n overleaf logs mongo-0`, `redis-0`, `git-bridge-0` | MongoDB, Redis e git-bridge, che vengono eseguiti nei propri pod |

### Leggere i log

| Toolkit | Kubernetes |
| - | - |
| `bin/logs web` | `kubectl -n overleaf exec deploy/overleaf -- tail -n 20 /var/log/overleaf/web.log` |
| `bin/logs -f web clsi` | `kubectl -n overleaf exec deploy/overleaf -- tail -f /var/log/overleaf/web.log /var/log/overleaf/clsi.log` |
| `bin/logs -n all web > web.log` | `kubectl -n overleaf cp overleaf/<pod>:/var/log/overleaf/web.log web.log` |
| `bin/logs mongo` | `kubectl -n overleaf logs mongo-0` |

Con [più repliche](https://ayakaleaf-pro.mintlify.site/it/on-premises/configuration/kubernetes/horizontal-scaling.md), ogni pod ha i propri file: usa il nome del pod (`overleaf-0`, `overleaf-1`, ...) invece di `deploy/overleaf`. L'header `X-Served-By` aggiunto da HAProxy indica quale replica ha risposto a una richiesta.

`LOG_LEVEL` nella ConfigMap (predefinito `info`, anche `debug`, `warn`, `error`) imposta in una sola volta il livello di tutti i servizi del pod.

### Conservare i log

I file risiedono nel container e vanno persi quando il pod viene sostituito. Per conservarli, monta un volume in `/var/log/overleaf`, ad esempio un `hostPath` sul nodo o un PersistentVolumeClaim, nel Deployment o nello StatefulSet:

```yaml theme={null}
          volumeMounts:
            # ...
            - name: logs
              mountPath: /var/log/overleaf
      volumes:
        # ...
        - name: logs
          hostPath:
            path: /srv/overleaf-logs
            type: DirectoryOrCreate
```

Il container ruota i file ogni giorno e ne conserva cinque, quindi il volume non cresce senza limiti. In alternativa, raccoglili da quel percorso con l'agente di log del tuo cluster.

### Testato su Kubernetes

Su Kubernetes 1.37 con tre repliche e un volume `hostPath` in `/var/log/overleaf` come sopra, la directory `/srv/overleaf-logs` di ogni nodo conteneva i dodici log dei servizi della sua replica, e i comandi della tabella hanno funzionato come indicato: `tail` tramite `kubectl exec`, `kubectl cp` di un file di log, `kubectl logs` del pod di Overleaf (avvio e migrazioni) e di `mongo-0`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.