Master journalctl: entenda os logs do systemd - Brasil Linux

O Systemd é uma ferramenta de gerenciamento de serviços. Criado inicialmente pela Red Hat, permite gerenciar melhor os serviços por meio de um processo centralizado que monitora e lança serviços conforme necessário. Mas o systemd também inclui um sistema de contêineres, um sistema cron, uma maneira de fornecer diretórios temporários a serviços de maneira segura e também um sistema de registro de logs - é aí que vamos nos concentrar aqui.

Entender os logs é importante: se você cair em um servidor que tenha um bug ou é hackeado, geralmente sua única maneira de entender o que aconteceu é via logs. A principal aplicação que vamos usar é journalctl, daí o nome do artigo.

Onde estão armazenados logs do systemd? E em que formato está armazenado?

Vamos supor que você tem um sistema normal, porque o systemd pode ser personalizado para estar em lugares excepcionais. Além disso, algumas distribuições Linux como o Ubuntu 16.04 desabilitaram o log persistente por padrão, o que impediu que o systemd fizesse seu trabalho corretamente. Se você tem essa distribuição, edite o arquivo /etc/systemd/journald.conf, mude Storage=auto para Storage=persistent e finalmente, reinicialize.

Assim, você encontrará normalmente os arquivos de logs do systemd em /var/log/ journal. O sistema de journalling é em si um serviço chamado system-journald.service. Vamos tentar listar os arquivos nesse diretório:

Porque eu quero que você continue lendo, eu tive que encurtar a saída, pois contém muitos arquivos (no meu exemplo, mais de 60 arquivos), desculpe por isso!

Ei, veja, isso realmente não parece com os arquivos de log normais que você vê, certo? Não se preocupe, esse arquivo não está corrompido, você acabou de descobrir um aspecto do systemd: o systemd armazena arquivos em um formato binário.É por isso que é tão pequeno quanto possível: dados estruturados como hora ou local são armazenados diretamente em binário, o que geralmente leva menos bytes do que o texto. Mas essa não é a única razão.

O systemd não armazena apenas linhas de log. Sua intenção é facilitar o monitoramento e a exploração de logs. Para ajudar nessa tarefa, as mensagens de log são, na verdade, uma linha de texto acompanhada de dados como gravidade do log (aviso, erro etc.) ou até mesmo campos que seriam úteis apenas para o aplicativo (URL solicitada, por exemplo).

Eu disse a você que há muitos campos (aqui há 25 campos ou 29 timestamps de contagem), todo o snippet acima é apenas para uma única mensagem de log. O grande benefício é que você pode executar uma pesquisa filtrando qualquer campo nessa mensagem de log. Isso realmente permite a filtragem avançada.

Um dos filtros mais óbvios que você deseja é filtrar pelo serviço. Como você pode ver acima, há um campo UNIT para que você possa filtrar facilmente para obter somente mensagens de log de um serviço. Eu vou falar mais sobre isso depois.

Mas essa quantidade de dados também significa outra coisa: em quase todos os casos, você nunca abrirá um arquivo de registro manualmente e nunca tocará na pasta /var/ log/journal. Você usará o journalctl para qualquer tarefa relacionada ao registro em log. Não existe esse tipo de rotação de log, tudo é gerenciado pelo tempo de mensagem de log.

Além disso, o número de campos dependerá de quão boa é a integração do systemd em seu aplicativo. Quanto mais campos uma mensagem de log contiver, melhor será. Para serviços de sistema básico, systemd já teve o cuidado de fazer uma boa integração, mas para outras aplicações e serviços, a qualidade da integração varia muito. Normalmente, isso deve ficar melhor ao longo do tempo como as pessoas se acostumam a systemd.

Ok, agora é hora de descobrir os recursos do journalctl.

Comandos mais usados para journalctl

O primeiro comando que você pode querer dar uma olhada é o que mostra os logs do kernel do Linux. Sim, o systemd também lida com o armazenamento dos logs do kernel, para que você possa obter os logs das inicializações anteriores também. Aqui está o comando:

Ele mostra um pager onde você pode ver as últimas mensagens. Você pode rolar até as últimas 3.000 linhas usando as teclas de seta (↑ / ↓) ou Page Up / Page Down. O sinalizador --catalog instrui o journalctl a mostrar o contexto em torno das linhas do log, da mesma forma que as reinicializações do computador ou, em outros contextos, um serviço que stopping / starting. Eu sempre coloco essa bandeira como o contexto sempre importa, ajuda saber em que situação a linha de registro apareceu, então você pode adivinhar porque você conseguiu essa linha de log.

Agora, talvez você queira ver apenas as linhas de log da inicialização atual:

Observe que o argumento de linha de comando --boot funciona em todas as situações, não apenas nos logs do kernel. Se você preferir começar do começo: (obvio começar do fim ? hahahaha)

Eu não sei se é o seu caso, mas eu tenho bastante logs de kernel! E que tal ter uma visão geral da sua máquina?

Uau, há muitas coisas acontecendo no seu sistema! Um pouco de filtragem seria útil aqui. Um dos filtros mais usados é a correspondência de um serviço específico (como seu servidor SSH ou servidor HTTP), o nome do arquivo da unidade systemd para o serviço SSH é sshd.service, portanto:

Isso é legal, não é? Bem, só é utilizável se você souber o nome do serviço, mas, em muitos casos, não sabe o nome desse serviço. Se você estiver em tal situação, talvez queira uma listagem dos serviços, suas descrições e seus status:

Ok, esse problema está resolvido agora. Mas, às vezes, você recebe uma mensagem de erro de um sistema externo, como seu próprio site ou de um aplicativo em sua área de trabalho. Então você provavelmente vai querer procurar uma palavra ou sentença específica na mensagem de log. Desde o systemd v237, agora é possível.

Em journalctl, a pesquisa não faz distinção entre maiúsculas e minúsculas se a palavra pesquisada estiver em minúsculas. Portanto, se você pesquisar a palavra port, ela também pesquisará a palavra port com letras maiúsculas. Um exemplo:

Agora, se você pesquisar uma palavra como CPU, ela só pesquisará a CPU com todas as letras maiúsculas, não pesquisará a CPU.

Você se lembra da mensagem de erro do sistema externo? Geralmente, essas mensagens contêm um registro de data e hora. Para filtrar a mensagem de log, você pode querer usar esse carimbo de data / hora. O journalctl pode listar todas as mensagens de log desde uma data e hora específicas com o argumento --since:

Se esse sistema externo for remoto ou estiver usando registros de data e hora UTC, será necessário filtrar com base em uma data e hora UTC e exibir no terminal os registros de data e hora UTC para que você não precise convertê-lo em sua cabeça. realmente confuso. Para fazer isso, você precisará adicionar o UTC após a string de hora no argumento --since. Você precisará então adicionar o sinalizador --utc. Então, por exemplo:

Observe que você pode usar o sinalizador --utc sozinho, nesse caso, ele exibirá basicamente todas as datas e horas no fuso horário UTC.

Logs são melhor gerenciados com journalctl

Como você pode ver com todos os comandos anteriores, o journaling do systemd torna a filtragem e a depuração mais fáceis, pois é possível selecionar todas as linhas de registro usando um único comando, journalctl. Alguns de vocês provavelmente conheciam os tempos antigos em que precisavam abrir manualmente todos os arquivos em /var/log para ter uma ideia geral do problema e do que aconteceu. Com todas as dicas que você aprendeu aqui, você terá ferramentas sólidas para analisar suas mensagens de registro da maneira desejada.

Fonte : AQUI

Grupo: Brasil Linux