Visualizar e Manipular Logs do Systemd com o Journalctl

O sistema e o registro de processos são apenas duas das vantagens mais cruciais do systemd. Quando os logs estão dispersos por todo o sistema, abrangem múltiplas aplicações e são tratados por diferentes processos e daemons, eles podem ser difíceis de interpretar. O systemd fornece uma solução centralizada para gerenciar todos os logs de processos do kernel e do userland em um meio de compilação conhecido como journal. Você pode aprender mais sobre o systemd em nosso tutorial sobre como gerenciar serviços e unidades do systemd com o systemctl. Todas as mensagens geradas por serviços, initrd, kernels, etc. em um journal são tratadas pelo daemon do journal. O objetivo deste guia é ilustrar como acessar e manipular os dados do journal usando o journalctl.

Premissa Básica

Independentemente de onde uma mensagem possa se originar, uma das principais mensagens do systemd é permitir que seu gerenciamento seja centralizado. Como muitos dos processos de boot e grande parte do gerenciamento de serviços são tratados pelo processo systemd, a maneira como os logs são compilados e acessados deve ser padronizada. Coletando dados de quaisquer fontes disponíveis em uma única ferramenta abrangente, o journald os armazena em um formato binário. Isso permite que os dados estejam prontamente disponíveis para manipulação dinâmica e simples.

Esta abordagem tem várias vantagens importantes. Ao ter um local central para coletar todos os dados, os administradores podem filtrar e exibir apenas os dados de que precisam. Por exemplo, é possível visualizar dados de boot de três inicializações do sistema atrás. Isso também pode significar o registro sequencial de entradas de serviços relacionados e rastrear de forma mais eficaz um problema de comunicação entre eles.

Graças ao armazenamento binário, os dados podem ser exibidos em uma variedade de formatos de saída, dependendo das necessidades do usuário no momento. Por exemplo, um log diário pode ser visualizado em um formato syslog padrão. Mas se você precisar analisar tendências de interrupções de serviço na forma de um gráfico, a entrada pode ser gerada como um JSON objeto, tornando-o compatível com um serviço de gráficos. Quando você precisa alterar os formatos dependendo das demandas situacionais, nenhuma conversão é necessária, pois os dados são binários e não são gravados no disco em texto simples.

Dependendo das necessidades de cada um, você pode implementar o journal do systemd com um syslog existente ou ele pode substituir essa funcionalidade. O systemd pode até complementar os mecanismos de log existentes. Por exemplo, múltiplos serviços em um único sistema podem ter seus dados compilados interligados em um único sistema com o journal do systemd.

Configurando a Hora do Sistema

O systemd irá, por padrão, exibir os resultados no horário local, um benefício do registro de log em formato binário do journal na forma como os registros de log podem ser visualizados. Alternativamente, eles podem ser visualizados em UTC. Portanto, é importante certificar-se de que o fuso horário esteja configurado corretamente antes de começar a usar o registro de log do journal. Para fazer isso, o systemd está equipado com uma ferramenta chamada timedatectl. Começamos vendo quais fusos horários estão disponíveis para uso, exibindo uma lista com as opções list-timezones:

Depois de encontrar o fuso horário correspondente à localização do seu servidor, o fuso horário pode ser definido usando a opção set-timezone:

Para testar e verificar se o fuso horário está sendo exibido corretamente, você pode usar o comando timedatectl sozinho ou adicionando 'status':

A primeira linha mostra a hora local. Esta linha deve conter a hora correta para a sua região local.

Visualização Geral de Logs

O comando journalctl permitirá que você visualize os logs que o daemon journald coletou. Quando você usa o journalctl, cada entrada do journal do sistema será exibida na tela, com as entradas mais antigas listadas no topo. A lista completa de dados terá, no entanto, dezenas de milhares de linhas de comprimento.

Quem já utilizou o registro padrão do syslog achará o formato familiar, mas é importante ter em mente que esta compilação de dados é incluída a partir de muitas fontes, ao contrário do método syslog. Os logs incluirão o processo inicial de inicialização, o initrd e o kernel, bem como os erros padrão das aplicações.

Agora que a hora local está configurada, todas as entradas começarão com carimbos de data/hora definidos no horário local, e isso está disponível para todos os logs atualmente armazenados no sistema, com toda a lógica sendo exibida usando essa nova informação. No entanto, você não está limitado ao horário local. Usando a flag –utc, você também pode exibir os carimbos de data/hora em UTC:

Filtragem do Journal por Hora

Ter tantos dados disponíveis é fantástico, mas vasculhá-los e ser capaz de absorvê-los, sem mencionar processá-los mentalmente, pode ser uma tarefa assustadora. Com isso em mente, chegamos à parte mais importante da função journalctl: a filtragem.

Exibição de Logs da Inicialização Atual

Se você estiver procurando pelos dados no journal a partir da última inicialização, poderá usar a função journalctl com a flag -b. Isso exibirá todas as informações de log pertinentes da inicialização mais recente do seu sistema. Este comando permitirá que você encontre e gerencie as informações mais pertinentes ao ambiente de trabalho atual:

Se o visualizador optar por não avaliar cada entrada individualmente, o journalctl mostrará mais de um dia de inicializações que serão exibidas no journalctl com separadores convenientes de ‘Reboot’. Isso ajuda a separar logicamente as informações de diferentes sessões de inicialização para revisão:

Informações de Inicializações Passadas

Embora a exibição das informações da inicialização atual tenda a ser a mais útil, existem situações em que as informações de inicializações passadas serão úteis. O Journal salva informações de múltiplas inicializações anteriores, de modo que o journalctl pode facilmente exibir as informações de qualquer período de tempo.

Algumas distribuições desativam o salvamento de informações de inicializações anteriores, enquanto outras o mantêm ativado por padrão. A ativação das informações de inicialização persistentes pode ser realizada criando um diretório para armazenamento do journal, digitando o seguinte:

Alternativamente, você pode editar o arquivo de configuração do journal da seguinte maneira:

Definir a opção Storage= como “persistent” sob a seção [Journal] habilitará o log persistente:

Uma vez ativado, o journalctl disponibiliza certos comandos que ajudam a designar essas inicializações como unidades de divisão. Para visualizar as inicializações que foram registradas no journald, você pode usar a opção –list-boots através do journalctl:

Como ilustrado, cada inicialização será listada em sua própria linha, com a primeira coluna refletindo as inicializações anteriores em ordem da mais antiga para a mais recente. Se uma referência mais absoluta for necessária, a segunda coluna conterá a identificação da inicialização. Depois disso, há duas especificações de tempo listadas. As informações da primeira ou da segunda coluna podem ser usadas para exibir as informações do journal para a inicialização específica. Por exemplo, você pode usar a flag -b com o ponteiro de inicialização relativo -1 para visualizar as informações da segunda inicialização mais recente:

Da mesma forma, o ID de inicialização da segunda coluna também pode ser usado desta maneira:

Janelas de Tempo

Visualizar inicializações por ID é uma opção, mas geralmente é mais útil poder referenciar inicializações anteriores por uma janela de tempo no passado que pode não necessariamente se alinhar com inicializações específicas. Por exemplo, isso é relevante em uma situação em que se está trabalhando com servidores de longa execução que não são reiniciados com frequência. A filtragem de limites de tempo pode ser feita com limites de tempo arbitrários. Isso exibirá apenas informações sobre as reinicializações que ocorrem dentro de uma janela de tempo específica. Os parâmetros desta janela são designados com as opções –since e –until. Existem vários formatos disponíveis para opções de tempo. O formato do valor de tempo absoluto é o seguinte:

Então, se você quiser ver todas as inicializações desde 10 de janeiro de 2015 às 17:15, digite o seguinte comando:

Se qualquer um dos componentes for omitido, existem padrões integrados. Além disso, se uma data for deixada de fora, a data atual é usada por padrão. Se o componente de tempo estiver ausente, a meia-noite é o padrão (00:00:00). Se você deixar os segundos de fora do componente de tempo, eles serão padronizados para o ponto inicial daquele minuto (00):

O journal consegue entender atalhos relacionados ao tempo como “today”, “tomorrow”, “yesterday” e “now”. Palavras como “ago”, em conjunto com qualificadores prefixados “-” e “+”, podem ser usadas para construir um comando do tipo frase:

Se você foi notificado de uma interrupção de serviço que começou às 9:00 e deseja verificar os logs do journal até uma hora atrás, você pode fazer isso com o seguinte:

Como fica evidente, definir uma janela de tempo flexível para visualizar as entradas desejadas é muito simples.

Filtrar por interesse de mensagem

Além de filtrar o journal por restrições de tempo, os dados também podem ser filtrados com base no componente de serviço de interesse. O Systemd fornece vários métodos para fazer isso.

Por unidade

Provavelmente o parâmetro de filtragem mais útil é pela unidade de interesse. Para filtrar por unidade, a opção -u pode ser aproveitada. Por exemplo, se você deseja ver todos os logs pertencentes à unidade do Nginx, digite o seguinte comando:

Realisticamente, você gostaria de emparelhar isso com um filtro de tempo para exibir as linhas interessantes. Se você quiser verificar o serviço acima e como ele se comportou hoje, você pode fazer o seguinte:

Isso é especialmente útil ao utilizar a capacidade do journal de compilar registros de várias unidades, especialmente as colaborativas. Se o processo do Nginx estiver conectado a uma unidade PHP-FPN para processamento de conteúdo dinâmico, as entradas podem ser mescladas em ordem cronológica especificando ambas as unidades:

Isso pode ajudar muito a notar a interação dos programas e facilitar a depuração de sistemas em vez de processos individuais.

Por ID de grupo, processo ou usuário

Muitos serviços iniciam uma infinidade de subprocessos (processos filhos) para realizar um trabalho específico. Se o ID de um processo específico estiver disponível, ele também poderá ser filtrado especificando o campo _PID. Se o PID de interesse for 8088, o seguinte pode ser feito:

Você também pode querer ver as entradas registradas de um grupo específico ou de um usuário específico. Isso pode ser feito usando os filtros _GID e _UID. Se um servidor web for executado sob o usuário www-data, o seguinte comando pode encontrar o ID necessário:

Usando esse ID, você pode visualizar os resultados qualificados do journal:

Systemd disponibiliza muitos campos para fins de filtragem. Alguns campos são aplicados pelo journald com base em informações coletadas do sistema no momento do registro, enquanto outros são passados a partir do processo que está sendo registrado no momento.

Um pré-qualificador de _PID indica que a informação foi coletada do sistema no momento do registro. O journal registra e indexa o PID automaticamente durante o processo de registro para disponibilizar a capacidade de filtragem mais tarde. Para saber mais sobre os campos disponíveis do journal, você pode digitar:

Discutiremos alguns destes mais adiante neste guia, mas por enquanto, abordaremos algumas outras opções úteis relacionadas a esses campos. Se você quiser ver todos os valores disponíveis para um campo específico do journal, pode usar a opção -F. Se desejar ver o que o journal do systemd possui para IDs de grupo, o seguinte pode ser feito:

Isso pode ajudar na construção de filtros, fornecendo uma lista completa de valores que o campo de ID de grupo do journal armazenou.

Por Caminho do Componente

A filtragem também pode ser realizada fornecendo a localização de um caminho. Se o caminho for para um executável, as entradas no journalctl serão exibidas se envolverem esse executável. Se o executável de interesse for o ‘bash’, você pode digitar:

Embora às vezes não seja possível fazer isso, se a unidade do executável estiver disponível, ela pode gerar um método de filtragem mais claro e informativo.

Exibir Mensagens do Kernel

As mensagens do kernel, normalmente encontradas na saída do dmesg, também podem ser recuperadas do journal. Para que apenas essas mensagens sejam exibidas, utilizamos as flags -k ou -dmesg como parte do nosso comando:

Mensagens da inicialização atual serão exibidas por padrão, mas inicializações anteriores podem ser especificadas conforme a utilização da flag de seleção mencionada anteriormente. Se você estiver procurando por mensagens de cinco inicializações atrás, digitar isto trará os resultados necessários:

Por Prioridade

Os administradores de sistema geralmente preferem filtrar por prioridade. Logs de baixa prioridade, embora muitas vezes úteis de visualizar, podem ser confusos e conter muitas distrações, tornando-os menos compreensíveis durante a análise. O uso da opção -p no journalctl exibirá apenas mensagens de uma prioridade especificada, filtrando quaisquer outras prioridades. Se desejar exibir entradas do nível de erro ou superior, insira o seguinte:

Esse comando retornará todas as mensagens indicadas como erros, alerta, emergência ou críticas, com o journal usando os níveis de mensagens padrão do syslog. Os níveis de prioridade são definidos de acordo com um valor numérico, classificados do maior para o menor:

• 0: emerg
• 1: alert
• 2: crit
• 3: err
• 4: warning
• 5: notice
• 6: info
• 7: debug

Qualquer um dos itens acima pode ser usado de forma intercambiável com a opção -p. Selecionar qualquer uma das prioridades conforme descrito acima filtrará todas as prioridades daquele nível e superiores.

Modificando a Exibição no Journal

Além de usar a filtragem para seleção de entradas, temos outros métodos para modificar a saída, adaptando a exibição do journalctl para atender às nossas necessidades.

Truncar/Expandir Saída

Podemos ajustar a visualização da nossa saída definindo se o journalctl encolhe ou expande os dados. O padrão do journalctl é mostrar a entrada completa, estendendo as entradas mais longas para a direita da tela. Você pode visualizar as entradas na íntegra rolando com a tecla de seta para a direita. O usuário pode preferir truncar a saída, com reticências indicadas nas linhas que, de outra forma, sairiam da tela. Para isso, a opção –no-full pode ser usada:

Alternativamente, você também pode permitir que a exibição mostre tudo, independentemente do comprimento ou da inclusão de caracteres não imprimíveis, usando a flag -a:

Saída para a Saída Padrão

O Journalctl exibe a saída em um paginador por padrão, mas se você deseja manipular os dados com ferramentas de edição de texto, provavelmente precisará que a saída seja gerada para uma opção de saída padrão. Você pode conseguir isso com a opção –no-pager:

Dependendo das necessidades do usuário, isso pode ser redirecionado para um arquivo no disco ou para um utilitário de processamento.

Formatos de Saída

Os dados são sempre mais fáceis de analisar quando apresentados em um formato mais consumível. O journal oferece várias opções de exibição usando o qualificador -o seguido por um formato especificamente indicado.

Se você deseja exportar as entradas do journal para um formato JSON, pode fazer isso da seguinte maneira:

Esta estratégia é particularmente útil ao analisar utilitários. O formato json-pretty pode ser melhor para exibir as estruturas de dados antes de passá-las para o consumidor JSON:

Existem vários formatos que você pode utilizar para exibição:

• cat: Exibe apenas o próprio campo de mensagem.
• export: Um formato binário adequado para transferência ou backup.
• json: JSON padrão com uma entrada por linha.
• json-pretty: JSON formatado para melhor legibilidade humana
• json-sse: Saída formatada em JSON encapsulada para torná-la compatível com eventos enviados pelo servidor (server-sent events)
• short: A saída padrão no estilo syslog
• short-iso: O formato padrão aumentado para mostrar carimbos de data/hora do relógio de parede ISO 8601.
• short-monotonic: O formato padrão com carimbos de data/hora monotônicos.
• short-precise: O formato padrão com precisão de microssegundos
• verbose: Mostra todos os campos do journal disponíveis para a entrada, incluindo aqueles que geralmente ficam ocultos internamente.

As opções acima permitem que o journal seja exibido no seu formato preferido.

Monitoramento de Processos Ativos

O journal permite o acesso a recursos de monitoramento de atividades ativas ou recentes sem a necessidade de envolver outra ferramenta. Você pode fazer isso com o comando journalctl com uma função ‘tail’.

• Exibindo Logs Recentes

Exibir a opção -n (que funciona exatamente como o comando tail -n) permitirá a exibição de uma certa quantidade de registros:

O número de entradas que você gostaria de exibir pode ser especificado com um número específico após o qualificador -n:

• Acompanhando os Logs

Você também pode acompanhar os logs ativamente à medida que são gravados no sistema com a flag -f. Isso também funciona da mesma maneira que o comando tail -f:

Manutenção do Journal

Os logs ocupam espaço. Vale a pena explorar isso, potencialmente para limpar alguns dos logs mais antigos para liberar espaço.

Descobrindo o Uso Atual do Disco

A flag –disk-usage pode ajudar a identificar quanto espaço o registro de logs está ocupando atualmente no disco:

Excluindo Logs Antigos

Com o systemd versão 218 (e versões subsequentes), você pode reduzir o journal de duas maneiras diferentes. Uma delas é a opção –vacuum-size. Isso pode reduzir o journal indicando seu tamanho. Em outras palavras, as entradas mais antigas serão eliminadas do log até que o espaço ocupado esteja no parâmetro solicitado:

A opção –vacuum-time pode reduzir a ocupação de espaço do journal indicando um tempo limite, a partir do qual quaisquer entradas anteriores serão excluídas, enquanto as criadas após o tempo especificado serão mantidas. Se você deseja manter as entradas apenas do último ano civil, pode usar:

Limitar a Expansão do Journal

Você também pode limitar a quantidade de espaço que o journal ocupará. Isso é feito editando o arquivo /etc/systemd.journald.conf. O crescimento do journal pode ser limitado usando qualquer um dos seguintes métodos:

• SystemMaxUse=: Indica o espaço máximo em disco que o journal tem permissão para usar no armazenamento persistente.
• SystemKeepFree=: Indica quanto espaço deve ser deixado livre quando as entidades do journal são adicionadas no armazenamento persistente.
• SystemMaxFileSize=: Especifica o tamanho máximo que os arquivos do journal podem atingir até a rotação no armazenamento persistente.
• RuntimeMaxUse=: Especifica quanto espaço em disco é permitido utilizar no armazenamento volátil (dentro do sistema de arquivos /run).
• RuntimeKeepFree=: Ao gravar dados no armazenamento volátil, esta função indica a quantidade de espaço que deve ser dedicada a outros usos (dentro do sistema de arquivos /run).
• RuntimeMaxFileSize=: Indica quanto espaço um journal de log individual pode ocupar no armazenamento volátil (dentro do sistema de arquivos /run) antes de precisar ser rateado.

Todas essas opções podem ajudar a controlar o consumo de armazenamento pelo journal. Um fato importante a ser observado é que as opções SystemMaxFileSize e RuntimeMaxFileSize terão como alvo arquivos arquivados para atingir os limites estabelecidos. Este é um fato importante a ser mantido em mente ao interpretar a contagem de arquivos após as operações pós-vacuuming.

Conclusão

É evidente que o journal do systemd é uma ferramenta incrivelmente útil para se aproveitar, com a maioria de seus benefícios decorrendo da natureza centralizada dos logs’ e do extenso volume de metadados registrados. Os amplos recursos do journal podem ser aproveitados através da utilização do comando journalctl, promovendo um método mais fácil para realizar a depuração relacional de componentes de aplicativos, bem como uma análise extensa do sistema.

Feliz Computação!