Onde o Solaris guarda seus logs e como usar fmadm/fmdump para falhas de hardware e software

O que é

O Solaris guarda a maior parte das mensagens de log de todo o sistema em /var/adm/messages; o dmesg exibe as últimas 200 entradas do syslog desse arquivo e de suas cópias rotacionadas, em ordem cronológica. À parte disso, a saída stdout/stderr do método de início de cada instância de serviço SMF vai para um arquivo de log próprio, por instância, em /var/svc/log/; o caminho exato é o que svcs -l <fmri> informa. Há ainda um terceiro mecanismo, independente dos outros: a Fault Management Architecture (FMA), formada pelo fmd e pelas ferramentas de administração fmadm e fmdump, que diagnostica falhas de hardware e algumas de software e transforma a telemetria bruta em uma falha diagnosticada, com UUID, lista de suspeitos e ação sugerida.

Por que importa

A FMA existe porque um único evento de hardware (uma DIMM com defeito, um disco que começa a relatar erros) pode gerar muitos relatórios de erro brutos. Os mecanismos de diagnóstico da FMA os correlacionam em um único registro de falha, em vez de deixar o administrador ler várias linhas de log e tentar adivinhar a causa. É um modelo mental diferente do Linux, onde logs do kernel e ferramentas separadas de fornecedores costumam ser usados de forma fragmentada para o mesmo fim.

Como aplicar

• Listar os componentes com falha no momento: fmadm faulty mostra os componentes que a FMA diagnosticou como falhos, defeituosos ou sinalizados de outra forma, com o UUID do diagnóstico para referência cruzada. Exige a autorização solaris.fm.read (perfil de direitos "Fault Information" ou "Fault Management", ou o papel root); serviços SMF que entraram em maintenance também podem aparecer aqui.
• Ver o histórico completo de diagnósticos, e não só as falhas atuais: fmdump sem argumentos imprime o log de falhas (uma linha por evento de diagnóstico, incluindo os logs rotacionados); acrescente -v para obter detalhes de cada evento. fmdump -e mostra, em vez disso, a telemetria de erro bruta (ereports), que está em formato privado e não deve ser analisada em scripts. Ler esses logs normalmente exige o papel root.
• Consultar um evento pelo UUID: fmdump -u <uuid> -v imprime o diagnóstico completo daquele evento, o que é útil quando um serviço ou um alerta de monitoramento já forneceu um UUID.
• Para uma falha de serviço SMF, comece por svcs -x (veja o artigo sobre SMF desta série), que informa o caminho do log; leia esse arquivo em /var/svc/log/ para ver a saída de erro do próprio serviço, separada de qualquer coisa diagnosticada pela FMA.
• Para verificar rapidamente as mensagens do kernel e do sistema em geral, use dmesg; leia /var/adm/messages diretamente quando precisar de mais do que as últimas 200 entradas ou de entradas que o dmesg já deixou para trás por causa da rotação.

Armadilhas

• Procurar uma falha de serviço apenas em /var/adm/messages: a saída do método de início do serviço está no arquivo dedicado em /var/svc/log/, não no log de mensagens do sistema.
• Tratar fmadm faulty como o histórico completo de falhas: ele mostra as falhas atuais, não as resolvidas; use fmdump para ver a linha do tempo completa, incluindo falhas que já foram reparadas ou cujo componente foi substituído.
• Supor que todo problema de hardware gera uma falha na FMA: algumas condições ainda aparecem apenas como mensagens brutas em /var/adm/messages, sobretudo em hardware sem suporte ou virtualizado, onde faltam os módulos de diagnóstico específicos da plataforma.