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:

LinuxFreeBSDDockerCompilação a partir do Código Fonte

Nos pacotes pré-compilados para Linux, o arquivo angie-debug é compilado com log de debug habilitado:

$ 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:

error_log /path/to/log debug;

E recarregue a configuração:

$ sudo angie -t && sudo service angie reload

Nas imagens Docker com template com log de debug habilitado, você também pode usar a variável de ambiente ANGIE_ERROR_LOG_SEVERITY:

$ docker run -it --rm -e ANGIE_BINARY="angie-debug" \
-e ANGIE_ERROR_LOG_SEVERITY="debug" \
docker.angie.software/angie:templated

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.

Sobrescrever error_log na configuração sem especificar o nível debug desabilita o log de debug. Aqui, sobrescrever o log no nível server desabilita o log de debug para um servidor individual:

error_log /path/to/log debug;

http {
   server {
     error_log /path/to/log;
    # ...

Para evitar isso, remova a linha que sobrescreve error_log, ou defina o nível debug nela:

error_log /path/to/log debug;

http {
   server {
     error_log /path/to/log debug;
   #  ...

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 info

        # ...
    }

    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 mas direcioná-las para um arquivo diferente, você também deve especificar o nível debug:

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

        # ...
    }
}

Portanto, para habilitar o log de debug globalmente mas sobrescrever o arquivo de log para blocos individuais, também especifique o nível debug nessas sobrescrições. Caso contrário, se nenhum nível de log for especificado na diretiva error_log, o nível error será usado por padrão e as informações de debug para esses blocos serão perdidas.

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
   --- 2025-08-21 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

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

root soft core 0          # por padrão desabilita core dumps
root hard core unlimited  # permite aumentar o limite de tamanho

Em seguida, aumente o limite de tamanho do core dump usando ulimit, depois reinicie o Angie para reproduzir as condições de crash:

$ sudo ulimit -c unlimited
$ sudo cd <caminho para o diretório de instalação do Angie>
$ sudo sbin/angie  # ou sbin/angie-debug

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

$ sudo ls -al <caminho para o diretório de trabalho do Angie>  # padrão, veja /proc/sys/kernel/core_pattern
  ...
  -rw-r----- 1 root root 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=/path/to/core/files/%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=/path/to/core/files/%N.core

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:

$ sudo cd <caminho para o diretório de instalação do Angie>
$ sudo sbin/angie

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

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

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