Parte fundamental das tarefas de um SysAdmin é manter o funcionamento da plataforma, assim compreender quando, como e, porque as coisas dão errado é indispensável. Hoje será abordado System Logs no Linux.
O que é o System Logs ?
System Logs são determinados programas que rodam em segundo plano(normalmente chamados de daemons ou serviços) lidam com a maioria das tarefas no Linux, tais como sincronizar seu relógio com o relógio atômico para gerenciar sua rede, logo meu caro júnior se pretende manter a vaga, continue conosco.
Saiba como ler registros do System Logs
Existem muitos log’s diferentes em sistemas Linux. Normalmente, são armazenados no diretório /var/log no formato plain text. Muito poucos ainda são e você pode lê-los facilmente com menos dores de cabeça.
Para cunho de exemplo iremos utilizar o openSUSE, onde os registros importantes (log’s) são armazenados pelo systemd init system. Este é o sistema responsável pela execução de daemons e serviços que irão manter seu sistema funcionando.
Os registros obtidos pelo systemd não são armazenados em um formato binário, o que significa que eles ocupam menos espaço e podem ser vistos e exportados em vários formatos, mas o lado negativo é que você irá precisar de uma ferramenta específica para visualiza-los. Para nossa alegria esta ferramenta já vem instalada em nosso sistema, ela é chamada de journalctl e por padrão, registra todos os log’s de cada daemon em um único local.
Para darmos uma olhada em nossos registros no systemd, execute o comando journalctl. Isso irá exibir todos registros gerados até o momento. Tendo clareza do que se está visualizando, veja uma única entrada de registro gerada no journalctl:
Jul 06 11:53:47 aaathats3as pulseaudio[2216]: [pulseaudio] alsa-
util.c: Disabling timer-based scheduling because running inside a
VM.Este registro em específico contém (em ordem) a data e o momento em que foi registrado, o hostname da máquina, o nome do processo que foi registrado, o PID (process ID number) do processo registrado e o registro em si.
Se um programa que está rodando em seu sistema não está funcionando como o esperado, cheque o registro (caso esteja usando o vim/vi utilize o “/”) e procure pelo nome do programa. Em alguns casos os registros são detalhados o suficiente para você poder resolve-los sem a necessidade de uma ida rápida ao google. Outras vezes, você terá de buscar uma ajuda externa (o que seria de nós sem o Stackoverflow não é mesmo?).
Google sem dúvidas é plataforma mais conveniente para estes casos, onde é preciso resolver problemas esquisitos do Linux.
Tenha certeza de apenas inserir a parte do registro que contém a descrição do problema, visto que as informações contidas no início do mesmo (data, hostname, PID) são desnecessárias e podem retornar falso-positivo.
Saiba como realizar buscas no System Logs
Após procurar pelo problema, os primeiros resultados são, normalmente, páginas contendo várias possíveis soluções. Claro que você não deve testar quaisquer instruções que você encontra na internet: sempre tenha a certeza de fazer uma pesquisa complementar para compreender o que estás instruções irão de fato executar em seus sistema.
Com isso esclarecido, as soluções para um problema, com sua descrição extraída de um registro, são muito mais eficientes para sua resolução que buscas por termos genéricos que descrevem o mal funcionamento do programa.
Notícias Relacionadas
Isto se dá porque diversos fatores podem influenciar o mal funcionamento de um programa, e diversos problemas podem indicar instabilidades semelhantes.
Por exemplo, uma falta de áudio no sistema pode ocorrer por inúmeras razões, desde caixas de som desplugadas, caixas auxiliares não funcionando ou até mesmo a falta de drivers corretos.
Se você buscar a solução para o problema de uma maneira genérica, tal como, opensuse no audio, verá um amontoado de soluções inúteis para o problema e irá acabar perdendo tempo a ver navios.
Com uma busca específica, extraída da descrição do problema identificada no registro, você poderá ver outras pessoas que passaram pelo mesmo problema e que possuem exato mesmo registro que você. Veja nos exemplos a seguir:
Há imagem 1 mostra resultados genéricos, a falta de clareza na solução de um problema que está categorizado como ‘mal funcionamento do sistema’. Este tipo de busca quase nunca ajuda, e nos faz perder tempo, que sejamos francos, não é luxo que dispomos.
Já na imagem 2 temos resultados mais eficientes, uma clareza do problema indicando uma solução específica para o caso, nos poupando tempo e fornecendo a resolução ideal para o caso.
Existem ainda alguns sistemas que armazenam os registros fora do journalctl. Os mais importantes e que você irá lidar com mais frequência estão em ‘/var/log/zypper.log’ no caso do package manager do OpenSUSE, ‘/var/log/boot.log’ para os registros que seguem rápido demais durante a inicilização do sistema e ‘/var/log/ntp’ caso seu Daemon de Rede esteja tendo problemas com a sincronização.
Um outro local importante para buscar por registros, caso você esteja enfrentando problemas específicos com hardware é o Kernel Ring Buffer, o qual você pode ler digitando o comando dmesg -H (isso exibe uma lista de resultados). O Kernel Ring Buffer é armazenado na RAM, assim você o perde ao reiniciar, mas ele contém importantes mensagens do Kernel Linux sobre eventos importantes, tais como uma adição de hardware, módulos carregados ou problemas esquisitos com a rede.
Agora você já está mais preparado para compreender melhor seu sistema Linux e avançar um pouco mais em sua jornada ao SysAdmin. Esperamos que continue conosco nessa série!
Mais informações sobre logs no Linux
Se o assunto de logs em sistemas Linux te interessa, temos outro artigo que talvez você queira ler:
Bom, é isso, espero que não tenha ficado com dúvidas!
