> ## 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.

# Logs

> Leia, copie e mantenha os logs de uma implantação no Kubernetes.

Cada serviço dentro do pod do Ayakaleaf Pro grava seu próprio arquivo de log em `/var/log/overleaf/`; `kubectl logs` mostra apenas a saída de inicialização do contêiner (scripts de inicialização, migrações). O `bin/logs` do Toolkit lê os mesmos arquivos, veja [Logs](https://ayakaleaf-pro.mintlify.site/pt/on-premises/configuration/overleaf-toolkit/logging.md).

| Onde | O quê |
| - | - |
| `kubectl -n overleaf logs <pod>` | inicialização: verificação dos segredos, migrações (`Finished migrations`), início dos serviços |
| `/var/log/overleaf/<service>.log` no 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` com o Dropbox ativado |
| `/var/log/nginx/` no pod | `access.log`, `error.log` do nginx à frente dos serviços |
| `kubectl -n overleaf logs mongo-0`, `redis-0`, `git-bridge-0` | MongoDB, Redis e git-bridge, que são executados em seus próprios pods |

### Lendo os logs

| 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` |

Com [várias réplicas](https://ayakaleaf-pro.mintlify.site/pt/on-premises/configuration/kubernetes/horizontal-scaling.md), cada pod tem seus próprios arquivos: use o nome do pod (`overleaf-0`, `overleaf-1`, ...) em vez de `deploy/overleaf`. O cabeçalho `X-Served-By` que o HAProxy adiciona indica qual réplica respondeu a uma requisição.

`LOG_LEVEL` no ConfigMap (padrão `info`, também `debug`, `warn`, `error`) define o nível de todos os serviços do pod de uma só vez.

### Mantendo os logs

Os arquivos ficam no contêiner e são perdidos quando o pod é substituído. Para mantê-los, monte um volume em `/var/log/overleaf`, por exemplo um `hostPath` no nó ou um PersistentVolumeClaim, no Deployment ou no StatefulSet:

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

O contêiner rotaciona os arquivos diariamente e mantém cinco, então o volume não cresce indefinidamente. Ou colete-os a partir desse caminho com o agente de logs do seu cluster.

### Testado no Kubernetes

No Kubernetes 1.37 com três réplicas e um volume `hostPath` em `/var/log/overleaf` como acima, o `/srv/overleaf-logs` de cada nó continha os doze logs de serviço da sua réplica, e os comandos da tabela funcionaram como mostrado: `tail` via `kubectl exec`, `kubectl cp` de um arquivo de log, `kubectl logs` do pod do Overleaf (inicialização e migrações) e de `mongo-0`.


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