Skip to main content

TL;DR - O QUE FAZER SE O DISCO ESTIVER CHEIO

Conectar via SSH no servidor e executar:

/root/docker/scripts/disk_cleanup.sh

Vai fazer uma limpeza geral "relativamente segura" (alguns logs são apagados, cuidado) e printar em tela o resultado.

EXPLICAÇÃO GERAL

Talvez o problema mais comum (e grave) dos servidores é "uso de disco". Recebemos alertas por e-mail quando o uso do HD excede 80%, e é possível ver essa métrica através do Ozone também. Se o HD encher... pára tudo. Isso deve ser acompanhado com muito cuidado. A boa notícia é que o uso sempre cresce de forma relativamente lenta: um "alerta de 80% de uso" com certeza nos dá alguns dias (provavelmente semanas ou talvez até meses) pra pensar no que fazer.

O QUE FAZ USO DE DISCO

Só a instalação do sistema operacional e pacotes básico já usa um espaço considerável do HD (servidor "zerado"). A partir daí, temos os seguintes vilões (não necessariamente na ordem):

  • imagens Docker;
  • logs (Docker, journalctl, Accelero...);
  • Accelero - fotos
  • Accelero - banco de dados
  • Accelero - aplicação (git)
  • coisas que a gente mesmo "largou sem deletar"

Em geral, basta administrar essas coisas e tudo deve ficar bem.

Pra dar uma geral no uso do disco, usar (e provavelmente buscar pelo /dev/vda1):

df -h

Pra olhar melhor um diretório/path específico:

du /path/to/directory -h --max-depth=1

Imagens Docker​

Pode acontecer, entre uma versão e outra do Accelero, de haver alteração nas imagens dos containers (update de uma versão do PHP, por exemplo). Daí, conforme os deploys vão sendo atualizados, podem ficar imagens sem uso que podem ser excluídas. O jeito mais rápido de excluir essas imagens (e outras coisas que estão penduradas sem utilidade) é executar o seguinte comando COM TODOS OS SISTEMAS NO AR, RODANDO NORMALMENTE:

docker system prune --all

Isso vai excluir imagens, containers, networks e tudo mais que não estejam em uso.

Logs​

Diversas coisas geram logs, e a não ser que estejamos procurando ativamente por algum problema, esses logs podem ser excluídos. Existe um logrotate no servidor que é executado diariamente e rotaciona os principais arquivos de logs, mas pode não ser suficiente. Alguns comandos que podem ser úteis pra "ajudar o servidor":

#EXCLUIR LOGS DO journalctl DEIXANDO APENAS OS ÚLTIMOS 50MB
journalctl --vacuum-size 50M

#EXCLUIR TODOS OS LOGS DO ACCELERO - APLICAÇÃO
clearAllLogs

#CHECAR ARQUIVOS DE LOG GRANDES DO DOCKER
find /var/lib/docker/containers/ -name "*.log" -size +50M -exec ls -alh {} \;

Se for excluir logs manualmente, NÃO REMOVA O ARQUIVO DE LOG --- ESCREVA "VAZIO" NELE SENÃO VOCÊ PODE TER PROBLEMAS (echo -n "" > /path/to/logfile.log).

Accelero - fotos​

Provavelmente o maior vilão. O cliente vai guardando fotos no sistema e vai enchendo o HD. A licença de uso do Accelero vendida/alugada pro cliente prevê um determinado espaço de storage de fotos, mas é um soft limit (não há bloqueio). O limite atual pode ser visto na tela de monitoramento de licenças do Ozone. Para ver a quantidade de storage desse tipo em uso por cliente: du -h --max-depth=4 | grep "client/public/user_pics"

Se o cliente estiver usando "mais do que contratou", as ações são:

  • instruir o cliente a fazer uma limpeza (existem ferramentas no Accelero pra isso);
  • vender uma licença adicional pro cliente.

Independente disso, se o HD do servidor estiver batendo na trave, a solução é a Iongrade contratar espaço adicional para o servidor (attachar um novo HD). Nesse caso, como é um HD novo, o melhor é:

  • ver qual o cliente que está mais "gastando espaço";
  • parar o deploy dele;
  • mover a pasta de fotos dele (/root/docker/cliente.accelerobr.com.br/client/public/user_pics) para o HD novo;
  • criar um link simbólico da pasta de fotos dele apontando para o novo HD (ln -s /path/to/hd_novo/cliente.accelerobr.com.br/client/public/user_pics /root/docker/cliente.accelerobr.com.br/client/public/user_pics);
  • reiniciar os serviços.

NÃO MOVA O DIRETÓRIO INTEIRO DO CLIENTE PARA O HD NOVO, porque vários serviços do servidor esperam encontrar o deploy naquele path original. Se ainda assim você estiver com a péssima ideia de fazer isso, crie um link simbólico.

Accelero - banco de dados​

Outro grande vilão. Nesse caso, também é vendida uma licença controlado o "espaço de DB", mas de forma indireta: controlamos apenas a quantidade de logs armazenados (basicamente, a quantidade de linhas das tabelas logalgumacoisa).

O caminho pra monitorar e resolver "uso indevido" é o mesmo das fotos. É possível, inclusive, mover o banco do cliente para um HD novo.

Em algumas situações raras (cliente fez a limpeza do banco, mas os arquivos em disco referentes às tabelas continuam muito grandes apesar de estarem com poucas linhas), pode valer a pena fazer uma manutenção no DB ou até uma "recriação/reimportação". Não faça isso se não tiver certeza absoluta do que está fazendo. Não faça isso sem testar o procedimento offline antes. Não faça isso se não tiver backups em mãos. Não faça isso se não tiver bastante tempo pra resolver qualquer problema imprevisto.

Accelero - git​

Cada deploy do Accelero faz um git clone do source completo. Isso pode acabar ficando um pouco grande. Vale a pena reavaliar periodicamente a possibilidade de se fazer um shallow clone (git clone --depth=1 <VERSAO>).

Outras coisas​

De vez em quando fazemos alguma operação no servidor e "largamos coisas pra trás". Por exemplo, antes de ajudar o cliente a fazer uma "limpeza de fotos", podemos fazer um backup completo do diretório de fotos "porque vai que, né" (isso é boa prática)... e geralmente não podemos excluir esse backup logo após a operação, porque um problema pode demorar um pouquinho pra aparecer. E esse diretório fica lá pra sempre, esquecido...

A sugestão é que quando for necessário fazer esse tipo de coisa, o nome dos arquivos/diretórios de backup seja da seguinte forma (exemplo): _BACKUP_FOTOS_DELETE_AFTER_20231231

Depois, quando necessário podemos fazer uma busca por esse "DELETE_AFTER_" pra achar essas coisas que ficaram penduradas:

find / -name "*DELETE_AFTER*"