O kdump é um recurso essencial na maioria das distribuições Linux modernas, projetado para capturar informações quando o sistema sofre um "kernel panic". Ele utiliza o mecanismo kexec para carregar e executar um segundo kernel (o kernel de captura) sem a necessidade de passar pelo processo de boot do hardware. Isso permite que o estado da memória do kernel que falhou seja preservado e gravado em um arquivo de despejo (dump).

Por padrão, os registros de falhas são armazenados localmente. Em sistemas baseados em RHEL ou CentOS, o diretório padrão é:

/var/crash/

O arquivo gerado, geralmente chamado de vmcore, contém uma imagem da memória física do sistema no momento do erro. Para otimizar o espaço em disco e o tempo de gravação, o utilitário makedumpfile costuma usar o nível de compressão 31 (-d 31), que extrai apenas as páginas de memória do espaço do kernel, ignorando dados do espaço do usuário.

Preparação para Análise do vmcore

Para interpretar um arquivo vmcore, é obrigatório possuir os símbolos de depuração correspondentes à versão exata do kernel que estava em execução. Isso é feito através do pacote debuginfo. A análise pode ser realizada diretamente no servidor afetado ou em uma estação de trabalho separada.

Estratégias de Coleta

1. Local: Instalar os pacotes crash e kernel-debuginfo no próprio servidor. É mais rápido para diagnósticos pontuais, mas altera o estado do sistema em produção.
2. Remota: Transferir o vmcore para um servidor de aálise centralizado. Esta abordagem é preferível para manter a integridade do ambiente de produção e centralizar o histórico de falhas.

Para gerenciar múltiplos kernels sem instalar todos os pacotes RPM, você pode extrair os arquivos de símbolos manualmente:

# Exemplo de extração manual de símbolos de depuração
mkdir -p /analise/kernel-debug-v3.10
cd /analise/kernel-debug-v3.10
rpm2cpio /repositorio/kernel-debuginfo-3.10.0-1160.el7.x86_64.rpm | cpio -idmv

Utilizando a Ferramenta Crash

A ferramenta crash é o padrão para investigar falhas no kernel. Ela exige o arquivo de símbolos (vmlinux) e o dump de memória (vmcore).

# Iniciando a análise
crash /caminho/para/vmlinux /var/crash/127.0.0.1-data/vmcore

# Exemplo de saída do utilitário
      KERNEL: /usr/lib/debug/lib/modules/3.10.0-1160.el7.x86_64/vmlinux
    DUMPFILE: vmcore  [PARTIAL DUMP]
        CPUS: 16
        DATE: Mon Oct 23 14:20:01 2023
       PANIC: "BUG: unable to handle kernel NULL pointer dereference at 0000000000000010"
         PID: 4521
     COMMAND: "httpd"
        TASK: ffff880214c78000  [THREAD_INFO: ffff880214c78000]
         CPU: 4
       STATE: TASK_RUNNING (PANIC)

Dentro do ambiente do crash, o comando bt (backtrace) é o mais utilizado para identificar a sequência de funções que levou ao erro:

crash> bt
PID: 4521   TASK: ffff880214c78000  CPU: 4   COMMAND: "httpd"
 #0 [ffff880214c7bc38] machine_kexec at ffffffff8105d5eb
 #1 [ffff880214c7bc98] crash_kexec at ffffffff81105792
 #2 [ffff880214c7bd68] oops_end at ffffffff8169e4c8
 #3 [ffff880214c7bd90] no_context at ffffffff8168e238
 #4 [ffff880214c7bde0] __bad_area_nosemaphore at ffffffff8168e2be
 #5 [ffff880214c7be28] bad_area_nosemaphore at ffffffff8168e428
 #6 [ffff880214c7be38] __do_page_fault at ffffffff816a125e
 #7 [ffff880214c7be98] do_page_fault at ffffffff816a13f3
 #8 [ffff880214c7bec0] page_fault at ffffffff8169d648

Configuração Avançada do Kdump

Em ambientes com alta denisdade de servidores, é recomendável enviar os dumps via rede para evitar o consumo de disco local e agilizar a recuperação. No arquivo /etc/kdump.conf, pode-se configurar o destino via SSH:

# Configuração de destino remoto via SSH
path /remote/storage/crash
ssh user-analyzer@storage-server
default dump_to_rootfs
core_collector makedumpfile -l --message-level 1 -d 31 -F

Ao utilizar o protocolo SSH, o makedumpfile usa a opção -F para gerar um formato "flattened". Para converter esse arquivo de volta ao formato padrão no servidor de destino, utilize:

makedumpfile -R vmcore_output < vmcore.flat

Boas Práticas de Resposta a Incidentes

Ao lidar com falhas críticas de kernel, a eficiência no diagnóstico depende de um fluxo estruturado:

• Triagem Rápida: Verifique o arquivo vmcore-dmesg.txt. Ele contém as últimas mensagens do log do kernel antes do travamento e pode revelar o culpado imediatamente (ex: erro de hardware ou falha de driver).
• Isolamento de Causa: Compare o backtrace (bt) com problemas conhecidos em bases de conhecimento (KB) do fornecedor da distribuição Linux.
• Gestão de Símbolos: Mantenha uma biblioteca de vmlinux organizada por versão de kernel para evitar atrasos no download de pacotes debuginfo volumosos durante uma crise.
• Monitoramento de Rede: Certifique-se de que a largura de banda entre o servidor e o storage de dumps seja suficiente, pois falhas na transmissão podem atrasar o reinício automático do servidor.