Solução de problemas#

Se você encontrar um problema técnico e não conseguir encontrar uma solução em outras seções, faça uma pergunta no fórum da comunidade ou no canal do Telegram.

Suporte técnico para clientes:

  • https://support.angie.software

Log de debug#

O log de debug deve ser habilitado antes de realizar autodiagnósticos ou conforme recomendado pelo suporte técnico.

Para fazer isso, execute o Angie usando o executável com suporte a debug:

Nos pacotes pré-compilados para Linux, o arquivo angie-debug é compilado com suporte a debug:

$ ls -l /usr/sbin/ | grep angie

   lrwxrwxrwx 1 root root      13 Sep 21 18:58 angie -> angie-nodebug
   -rwxr-xr-x 1 root root 1561224 Sep 21 18:58 angie-debug
   -rwxr-xr-x 1 root root 1426056 Sep 21 18:58 angie-nodebug

Configure a execução do angie-debug:

$ sudo ln -fs angie-debug /usr/sbin/angie
$ sudo angie -t && sudo service angie upgrade

Isso iniciará uma atualização de executável ao vivo.

Para reverter ao executável regular após a depuração:

$ sudo ln -fs angie-nodebug /usr/sbin/angie
$ sudo angie -t && sudo service angie upgrade

Nota

Usar o executável com suporte a debug pode reduzir ligeiramente a performance; habilitar o log de debug pode reduzi-la significativamente e aumentar o uso de espaço em disco.

Para habilitar o log de debug, defina o nível debug na configuração usando a diretiva error_log (as imagens Docker com template usam uma variável de ambiente em vez disso, como mostra a aba Docker abaixo):

error_log /path/to/log debug;

Em seguida, aplique a alteração:

$ sudo angie -t && sudo service angie reload

Se você alternar para o executável sem suporte a debug mas deixar o nível debug na diretiva error_log, o Angie registrará entradas no nível info.

Localização da diretiva#

A localização da diretiva error_log afeta a completude das informações de debug coletadas.

Uma diretiva especificada em um nível de configuração mais baixo (por exemplo, dentro de um bloco server ou location) sobrescreve as configurações de log especificadas em um nível mais alto (por exemplo, no nível de configuração principal ou dentro de um bloco http).

Log de debug desabilitado para um servidor específico

Se o log de debug estiver habilitado globalmente mas error_log for especificado para um servidor individual sem o nível debug, as informações de debug não serão coletadas para esse servidor.

error_log /var/log/angie/error.log debug; # Log de debug global

http {

    server {

        listen 80;
        server_name example.com;

        error_log /var/log/angie/example.com.error.log;
        # Log de debug para example.com está desabilitado, arquivo contém nível error

        # ...
    }

    server {

        listen 80;
        server_name another.com;

        # Este servidor usará o log de debug global
        # ...
    }
}

Preservando o log de debug no nível do servidor

Para preservar a coleta de informações de debug para um servidor específico, remova a sobrescrita de error_log desse servidor; para direcionar essas informações a um arquivo diferente, especifique também o nível debug na sobrescrita:

error_log /var/log/angie/error.log debug; # Log de debug global

http {

    server {

        listen 80;
        server_name example.com;

        error_log /var/log/angie/example.com.error.log debug;
        # Log de debug para example.com está habilitado mas escrito em arquivo separado

        # ...
    }
}

Log de endereços específicos#

Você pode habilitar o log de debug apenas para endereços de cliente especificados:

error_log /path/to/log;

events {
  debug_connection 192.168.1.1;
  debug_connection 192.168.10.0/24;
}

Buffer de memória cíclico#

O log de debug pode ser escrito em um buffer de memória cíclico:

error_log memory:32m debug;

Escrever no buffer de memória no nível debug não impactará significativamente a performance mesmo sob alta carga. Neste caso, o log pode ser extraído usando um script GDB, por exemplo:

set $log = ngx_cycle->log

while $log->writer != ngx_log_memory_writer
  set $log = $log->next
end

set $buf = (ngx_log_memory_buf_t *) $log->wdata
dump binary memory debug_log.txt $buf->start $buf->end

Core Dumps#

Core dumps ajudam a investigar crashes. Inclua-os ao entrar em contato com o suporte. Para builds dos nossos repositórios, fornecemos símbolos de debug em pacotes especiais. Eles têm os mesmos nomes dos pacotes originais com o sufixo -dbg adicionado, por exemplo angie-dbg.

Nota

Esta seção assume que você está executando o Angie como usuário root (recomendado).

Linux: systemd#

Para habilitar o salvamento de core dump ao executar o Angie como um serviço systemd (por exemplo, quando instalado a partir de pacotes), modifique as configurações do serviço no arquivo /lib/systemd/system/angie.service:

[Service]
...
LimitCORE=infinity
LimitNOFILE=65535

Ou atualize as configurações globais no arquivo /etc/systemd/system.conf:

[Manager]
...
DefaultLimitCORE=infinity
DefaultLimitNOFILE=65535

Em seguida, recarregue a configuração do serviço e reinicie o Angie para reproduzir as condições de crash:

$ sudo systemctl daemon-reload
$ sudo systemctl restart angie.service

Após o crash, encontre o arquivo de core dump:

$ sudo coredumpctl -1 # opcional

   TIME                           PID   UID   GID SIG COREFILE  EXE
   --- 2026-10-16 11:05:40 GMT   1157     0     0  11 present   /usr/sbin/angie

$ sudo ls -al /var/lib/systemd/coredump/  # padrão, veja também /etc/systemd/coredump.conf e /etc/systemd/coredump.conf.d/*.conf

  ...
  -rw-r----- 1 root root 177662 Jul 27 11:05 core.angie.0.6135489c850b4fb4a74795ebbc1e382a.1157.1590577472000000.lz4

Linux: Configuração manual#

Esta seção aborda o Angie iniciado sem o systemd, como uma compilação a partir do código-fonte, e assume que o Angie dessa instalação está em execução; os comandos usam os caminhos padrão de uma compilação desse tipo em /usr/local/angie.

O local onde o kernel coloca um arquivo de core dump depende de /proc/sys/kernel/core_pattern. Se o padrão começar com |, o kernel passa o dump ao programa cujo nome vem a seguir, como o systemd-coredump, mesmo para o Angie iniciado sem o systemd; nesse caso, encontre o arquivo de core dump conforme descrito em Linux: systemd e pule os passos abaixo relativos ao diretório de trabalho. Se o padrão for um nome simples, como core, o kernel grava o arquivo de core dump no diretório de trabalho do processo que sofreu o crash; para os processos worker, esse diretório é, por padrão, aquele a partir do qual o Angie foi iniciado.

Os processos worker são executados sob a conta definida pela diretiva user (nobody em uma compilação padrão a partir do código-fonte); se essa conta não puder gravar no diretório de trabalho, o crash não deixa arquivo de core dump, então crie um diretório para arquivos de core dump:

$ sudo mkdir -p /var/tmp/angie-cores
$ sudo chown nobody /var/tmp/angie-cores

Defina-o com a diretiva working_directory no contexto main de /usr/local/angie/conf/angie.conf:

working_directory /var/tmp/angie-cores;

Em seguida, aumente o limite de tamanho do core dump. Para aumentá-lo apenas para os processos worker e evitar uma reinicialização, adicione também a diretiva worker_rlimit_core, que recebe um tamanho em vez de unlimited, e recarregue a configuração:

worker_rlimit_core 1g;

$ sudo /usr/local/angie/sbin/angie -s reload

Para aumentar o limite também para o processo mestre, reinicie o Angie em vez disso. Por padrão, o sudo inicia os comandos com um limite de tamanho de core dump igual a 0, e o ulimit altera o limite apenas para o shell que o executa e para os comandos que esse shell inicia. Pare o Angie em execução, aguarde até que o processo mestre dele encerre, depois aumente o limite e inicie o Angie em um único shell de root:

$ sudo /usr/local/angie/sbin/angie -s quit
$ while [ -e /usr/local/angie/logs/angie.pid ]; do sleep 1; done
$ sudo sh -c 'ulimit -c unlimited && exec /usr/local/angie/sbin/angie'

Uma compilação a partir do código-fonte configurada com --with-debug tem suporte a debug no próprio /usr/local/angie/sbin/angie; ela não tem um executável angie-debug separado.

Verifique o limite de um processo worker; após a reinicialização, os dois valores são unlimited e, com a diretiva worker_rlimit_core, mostram o tamanho que ela define, em bytes:

$ grep 'core file' /proc/$(pgrep -n -f 'angie: worker process')/limits
Max core file size        unlimited            unlimited            bytes

Em seguida, reproduza o crash. Se o crash deixou um arquivo de core dump, o log de erro (/usr/local/angie/logs/error.log por padrão) mostra worker process pid exited on signal number (core dumped); a mesma mensagem sem (core dumped) significa que o limite ou o diretório de trabalho impediu a criação do arquivo de core dump. Encontre o arquivo de core dump:

$ sudo ls -al /var/tmp/angie-cores
  ...
  -rw------- 1 nobody nogroup 177662 Jul 27 11:05 core.1157

FreeBSD#

Verifique as configurações de core dump no arquivo /etc/sysctl.conf, modifique-as se necessário:

kern.coredump=1                             # deve ser 1
kern.corefile=/caminho/para/arquivos/core/%N.core   # precisa do caminho correto

Ou atualize as configurações em tempo de execução:

$ sudo sysctl kern.coredump=1
$ sudo sysctl kern.corefile=/caminho/para/arquivos/core/%N.core

Em ambos os casos, o diretório em kern.corefile deve ser gravável pela conta definida pela diretiva user: os processos worker são executados sob essa conta e gravam ali seus arquivos de core dump.

Em seguida, reinicie o Angie para reproduzir as condições de crash. Se o Angie estiver instalado como um serviço:

$ sudo service angie restart

Se o Angie estiver instalado manualmente, pare-o, aguarde até que o processo mestre dele encerre e, em seguida, aumente o limite de tamanho do core dump e inicie o Angie em um único shell de root, como no Linux:

$ sudo <caminho para o diretório de instalação do Angie>/sbin/angie -s quit
$ while [ -e <caminho para o diretório de instalação do Angie>/logs/angie.pid ]; do sleep 1; done
$ sudo sh -c 'ulimit -c unlimited && exec <caminho para o diretório de instalação do Angie>/sbin/angie'

Após o crash, encontre o arquivo de core dump:

$ sudo ls -al <caminho para os arquivos de core dump>

  ...
  -rw------- 1 nobody nobody 9912320 Jul 27 11:05 angie.core