log do rabbit lota o /

[wgnann]

Na realidade isso tem a ver com o issue #31 do achados-e-pedidos-site. Teoricamente deve ter um workaround, mas precisa ver como fazer isso no rabbitmq. Se bem que, como se trata de uma instância efêmera, o log sequer deveria existir num disco subordinado ao /. Ou ele vai para um lugar que faz sentido, tipo um logstash da vida, ou ele deveria ir para o /dev/null.

[studiocuboweb]

@marcelo-jrkiko

Além de mudar o local de armazenamento dos logs, podemos dar uma olhada nas configurações.

Nesse link aqui https://www.rabbitmq.com/logging.html tem um tópico sobre Periodic Rotation e tb podemos refinar os registros para gravar apenas erros. Talvez esteja em modo debug e armazenando warnings, infos etc

[studiocuboweb]

@wgnann (copiando @marcelo-jrkiko) Como você monta esse stack do app do importador?

creio que existe um entry point (init.sh) que inicia o serviço do rabbit..

existe alguma espécie de docker-compose.yml que você usa para rodar comandos que serão executados durante o deploy (por exemplo) ou inicialização do serviço?

Para mim não ficou muito claro como configurar o rotate do log conforme esse link: https://www.rabbitmq.com/logging.html#log-rotation

consegue ajudar?

[wgnann]

É isso mesmo. Tem um script que roda na inicialização do container que provê as dependências.

#! /bin/bash
apt -yqq install gcc rabbitmq-server
service rabbitmq-server start

cd /home/site/wwwroot
pip install -r requirements.txt

celery multi start w1 -A achadosepedidos -l info

#gunicorn --bind=0.0.0.0 --timeout 600 achadosepedidos.wsgi
gunicorn --workers 4 --threads 2 --bind=0.0.0.0 --timeout 600 --access-logfile '/tmp/django-access.log' --error-logfile '/tmp/django-error.log' achadosepedidos.wsgi

[marcelo-jrkiko]

Legal, analisando as opções, eu acredito que o melhor caminho seja alterar a variavel de ambiente RABBITMQ_CONFIG_FILE e apontar o arquivo de configuração do RabbitMQ para um arquivo no root do importador, assim fica disponível no git.

Entao os passos são os seguintes:

1. Recuperar o conteudo atual do arquivo de configuracao RabbitMQ
2. Criar o Arquivo no Git e colocar as cofnigurações de rotação de logs
3. Colocar no Init.sh ou no proprio aplicativo da azure a variavel com o novo caminho do arquivo de configuração

[studiocuboweb]

@wgnann Você consegue acessar o app e tocar esses itens? Eu posso criar o arquivo no git depois

[wgnann]

O conteúdo do rabbitmq-server é o vanilla do pacote: todo comentado com zero linhas relevantes além das configurações default.

Teoricamente o rabbitmq também está com logrotate:

/var/log/rabbitmq/*.log {
        weekly
        missingok
        rotate 20
        compress
        delaycompress
        notifempty
        sharedscripts
        postrotate
            /etc/init.d/rabbitmq-server rotate-logs > /dev/null
        endscript
}

Isso significa que ele vai guardar 20 arquivos, comprimidos a menos do mais recente e o que está em produção. Além disso, fará a rotação de semana em semana. Parece uma configuração razoável e, inclusive, acho que é a mesma que se encontra no servidor que está em produção.

O que precisa descobrir é o que fez o log explodir porque, qualquer que seja a política de rotação, se o log explodir ela não funcionará. Pode ser algum problema em como o celery cria as coisas ou alguma coisa no servidor que deixou o rabbit apitando.

Dito isso, talvez seja interessante versionar o init.sh.

[marcelo-jrkiko]

O conteúdo do rabbitmq-server é o vanilla do pacote: todo comentado com zero linhas relevantes além das configurações default.

Teoricamente o rabbitmq também está com logrotate:

/var/log/rabbitmq/*.log {
        weekly
        missingok
        rotate 20
        compress
        delaycompress
        notifempty
        sharedscripts
        postrotate
            /etc/init.d/rabbitmq-server rotate-logs > /dev/null
        endscript
}

Isso significa que ele vai guardar 20 arquivos, comprimidos a menos do mais recente e o que está em produção. Além disso, fará a rotação de semana em semana. Parece uma configuração razoável e, inclusive, acho que é a mesma que se encontra no servidor que está em produção.

O que precisa descobrir é o que fez o log explodir porque, qualquer que seja a política de rotação, se o log explodir ela não funcionará. Pode ser algum problema em como o celery cria as coisas ou alguma coisa no servidor que deixou o rabbit apitando.

Dito isso, talvez seja interessante versionar o init.sh.

Oi @wgnann , Concordo que temos que anasisar, ainda tem os últimos logs para que possa analisar? Mas seria bom adicionar nesta configuração um limite de tamanho por log (size) e limitar o nivel de logs. Não existe a necessidade de criar logs de níveis menores que "warning" em produção e o parâmetro size, deve força a rotação caso os arquivos comecem a ficar bem grandes.
Logs podem ser bem "grandes" e na configuração atual, ele vai manter 20 arquivos de histórico sem limite de tamanho por uma semana, até a rotação rodar novamente, e no nivel padrão do rabbitmq (info), pode-se gerar bastante log.

o ideal , por hora seria:

 /var/log/rabbitmq/*.log {
         weekly
         missingok
         size 4096
         rotate 20
         level warning
         compress
         delaycompress
         notifempty
         sharedscripts
         postrotate
             /etc/init.d/rabbitmq-server rotate-logs > /dev/null
         endscript
 }

[studiocuboweb]

@wgnann Consegue apontar o caminho da configuração do rabbiqmq para dentro do root do importador dessa forma conseguimos versioná-lo e fazermos os ajustes necessários na configuração do log.

Em tempo: entrei nos logs do rabbit dentro da pasta /var/log/rabbitmq e, como não manteve um histórico, só peguei o registro mais atual de 19/nov e o que vi foi mais log de INFO. Ou seja. deve estar lotando porque qualquer vírgula que o rabbit faz é registrado nos logs. O ideal seria configurar o log conforme orientação do Marcelo a começar por warnings e errors mesmo...

Creio que vc mudando o caminho para o root da aplicação, eu e o Marcelo conseguimos colocá-lo no git e fazer os ajustes necessários. Dessa forma o disco não vai lotar e creio que vai resolver por tabela os problemas de lock do SQLITE e de criação de sessões que impedem o login nos admins do achados e pedidos e transparência.

Consegue nos ajudar com isso?

Obrigado

[wgnann]

Parte 1: do modelo Essencialmente, existem duas possibilidades de trabalhar com as coisas na Azure. A primeira delas é usar as stacks pré-prontas com algum setup que a Azure fornece (se não me engano, trata-se de uma imagem de docker baseada num debian com alguns pacotes a mais). A segunda é criar seu próprio docker, adequá-lo ao que a Azure pede e usar. A abordagem é determinada no momento onde se cria o webapp.

Ao menos para a instância atual, usamos uma stack pronta da Azure. Ela permite, essencialmente, escolher qual a linguagem, qual a versão (dentre algumas delas) e determinar um script de inicialização. A Azure tem um script próprio de inicialização, onde roda o que quer que seja de setup antes de, enfim, chamar o servidor web. No caso do PHP, por exemplo, ela usa o Apache como servidor web, no caso do Python, o Gunicorn.

Naturalmente a stack fornecida não contava nem com as bibliotecas, nem com os serviços necessários de tal sorte que foi montado um script de inicialização que coloca as coisas necessárias. A título de curiosidade, o gcc faz parte dos requisitos porque a biblioteca de MySQL utilizada chama primitivas que dependem de bibliotecas em C de tal sorte que elas precisam ser compiladas. É por isso que a instância demora: o pip precisa compilar as dependências do mysqlclient.

Os arquivos que ficam no /home de um webapp da Azure são persistentes, em particular, residem num compartilhamento do tipo SMB. É por isso que o sqlite deu problema: ele espera um sistema de arquivos que consiga implementar operação de lock e o compartilhamento de arquivos via SMB não foi construído pensando nesse tipo de funcionalidade.

Os arquivos que são utilizados em produção devem ficar no diretório /home/site/wwwroot.

Deixei o init.sh no /home justamente por causa disso.

Parte 2: como alterar o init.sh? Basta acessar o webapp a partir do portal.azure.com. Uma vez no webapp, clicar em Configuration, depois em General settings. O campo onde fica o inicializador é o Startup Command. Acho que é suficiente deixar o init.sh no repositório e referenciá-lo, por exemplo, via /home/site/wwwroot/init.sh.

Minha sugestão é, primeiro, fazer um commit dele lá, confirmar que ele foi parar no diretório correto e, por fim, trocar a configuração na Azure.

Dito isso, se o init.sh falhar, aí a instância não sobe e o Azure ficará tentando fazê-la subir para sempre. Nesse caso, não adianta meramente remover o init.sh da configuração, pois a falta de dependências vai matar a build (não vai ter nem o rabbitmq, nem o gcc para compilar o mysqlclient) e, por conseguinte, a instância não vai conseguir subir. Nesse caso será necessário acessar a instância a partir do painel dela. Em vez de ser seu-webapp.azurewebsites.net vira seu-webapp.scm.azurewebsites.net. Lá haverá jeito de consertar o init.sh.

Acho que outra forma é meramente atualizar o repositório com alguma versão do init.sh. De qualquer maneira, talvez seja interessante ter uma versão de homologação do importador para garantir que ele não vá quebrar no commit, pois é meio chatinho de reaver as coisas.

Parte 3: do log Não mantém histórico, pois o /var fica fora do /home, que é persistente. Ele não lota somente porque guarda coisas do tipo INFO, ele lota porque acontece alguma coisa com a aplicação que a faz escrever logs de forma maluca. Vale ressaltar que o arquivo de configuração é o mesmo da versão que roda na Google, isto é, o padrão do Debian. O segundo ponto que precisa reforçar é que a sugestão de configuração do Marcelo não versa sobre o rabbitmq, versa sobre o logrotate, sistema roda o log para guardar as n versões mais recentes, compactadas etc.

Os problemas de lock do sqlite não serão resolvidos a menos que ele fique fora do /home.