Como usar o Journalctl para visualizar e manipular logs do Systemd

Introdução

Algumas das vantagens mais atraentes do systemd são aquelas envolvidas com o processo e registro do sistema. Ao usar outras ferramentas, os logs geralmente são dispersos pelo sistema, manipulados por diferentes daemons e processos e podem ser bastante difíceis de interpretar quando abrangem vários aplicativos. O systemd tenta resolver esses problemas fornecendo uma solução de gerenciamento centralizado para registrar todos os processos do kernel e da área do usuário. O sistema que coleta e gerencia esses registros é conhecido como diário.

O diário é implementado com o daemon journald, que lida com todas as mensagens produzidas pelo kernel, initrd, serviços, etc. Neste guia, discutiremos como usar o journalctl utilitário, que pode ser usado para acessar e manipular os dados contidos no diário.

Ideia geral

Um dos ímpetos por trás do diário systemd é centralizar o gerenciamento de logs, independentemente de onde as mensagens são originadas. Como grande parte do processo de inicialização e gerenciamento de serviço é tratado pelo processo systemd, faz sentido padronizar a maneira como os logs são coletados e acessados. O daemon journald coleta dados de todas as fontes disponíveis e os armazena em um formato binário para manipulação fácil e dinâmica.

Isso nos dá uma série de vantagens significativas. Ao interagir com os dados usando um único utilitário, os administradores podem exibir dinamicamente os dados de log de acordo com suas necessidades. Isso pode ser tão simples quanto visualizar os dados de inicialização de três inicializações anteriores ou combinar as entradas de log sequencialmente de dois serviços relacionados para depurar um problema de comunicação.

Armazenar os dados de log em um formato binário também significa que os dados podem ser exibidos em formatos de saída arbitrários, dependendo do que você precisa no momento. Por exemplo, para o gerenciamento diário de logs, você pode estar acostumado a visualizar os logs no formato syslog padrão, mas se decidir representar graficamente as interrupções do serviço mais tarde, poderá gerar cada entrada como um objeto JSON para fazer é consumível para o seu serviço gráfico. Como os dados não são gravados no disco em texto simples, nenhuma conversão é necessária quando você precisa de um formato sob demanda diferente.

O diário systemd pode ser usado com uma implementação syslog existente ou pode substituir a funcionalidade syslog, dependendo de suas necessidades. Embora o diário systemd cubra a maioria das necessidades de log do administrador, ele também pode complementar os mecanismos de log existentes. Por exemplo, você pode ter um servidor syslog centralizado que usa para compilar dados de vários servidores, mas também pode querer intercalar os logs de vários serviços em um único sistema com o systemd diário. Você pode fazer ambos combinando essas tecnologias.

Definir a hora do sistema

Um dos benefícios de usar um diário binário para log é a capacidade de visualizar registros de log em UTC ou hora local à vontade. Por padrão, systemd exibirá os resultados na hora local.

Por isso, antes de começarmos a usar o diário, vamos garantir que o fuso horário esteja configurado corretamente. O conjunto systemd vem com uma ferramenta chamada timedatectl que pode ajudar com isso.

Primeiro, veja quais fusos horários estão disponíveis com a opção list-timezones:

timedatectl list-timezones

Isso listará os fusos horários disponíveis em seu sistema. Ao encontrar aquele que corresponda à localização do seu servidor, você pode configurá-lo usando a opção set-timezone:

sudo timedatectl set-timezone zone

Para garantir que sua máquina esteja usando a hora correta agora, use o comando timedatectl sozinho ou com a opção status. A exibição será a mesma:

timedatectl status

Output               Local time: Fri 2021-07-09 14:44:30 EDT
           Universal time: Fri 2021-07-09 18:44:30 UTC
                 RTC time: Fri 2021-07-09 18:44:31
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

A primeira linha deve exibir a hora correta.

Visualização básica de registros

Para ver os logs que o daemon journald coletou, use o comando journalctl.

Quando usado sozinho, cada entrada de diário que está no sistema será exibida em um pager (geralmente less) para você navegar. As entradas mais antigas estarão no topo:

journalctl

Output-- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules

. . .

Você provavelmente terá páginas e mais páginas de dados para percorrer, que podem ter dezenas ou centenas de milhares de linhas se systemd estiver em seu sistema por um longo tempo. Isso demonstra quantos dados estão disponíveis no banco de dados do diário.

O formato será familiar para aqueles que estão acostumados com o log syslog padrão. No entanto, isso realmente coleta dados de mais fontes do que as implementações tradicionais de syslog são capazes. Ele inclui logs do processo de inicialização inicial, do kernel, do initrd e do erro e saída padrão do aplicativo. Tudo isso está disponível na revista.

Você pode perceber que todos os carimbos de data/hora exibidos são da hora local. Isso está disponível para cada entrada de log agora que temos nosso horário local definido corretamente em nosso sistema. Todos os logs são exibidos usando essas novas informações.

Se você deseja exibir os timestamps em UTC, pode usar o sinalizador --utc:

journalctl --utc

Filtragem de Diário por Tempo

Embora ter acesso a uma coleção tão grande de dados seja definitivamente útil, uma quantidade tão grande de informações pode ser difícil ou impossível de inspecionar e processar manualmente. Por causa disso, um dos recursos mais importantes do journalctl são suas opções de filtragem.

Exibindo logs da inicialização atual

O mais básico deles, que você pode usar diariamente, é o sinalizador -b. Isso mostrará todas as entradas de diário que foram coletadas desde a reinicialização mais recente.

journalctl -b

Isso o ajudará a identificar e gerenciar as informações pertinentes ao seu ambiente atual.

Nos casos em que você não está usando esse recurso e está exibindo mais de um dia de inicialização, você verá que journalctl inseriu uma linha semelhante a esta sempre que o sistema caiu:

Output. . .

-- Reboot --

. . .

Isso pode ser usado para ajudá-lo a separar logicamente as informações em sessões de inicialização.

botas passadas

Embora você normalmente deseje exibir as informações da inicialização atual, certamente há momentos em que as inicializações anteriores também seriam úteis. O diário pode salvar informações de várias inicializações anteriores, então journalctl pode ser feito para exibir informações facilmente.

Algumas distribuições permitem salvar informações de inicialização anteriores por padrão, enquanto outras desativam esse recurso. Para ativar as informações de inicialização persistentes, você pode criar o diretório para armazenar o diário digitando:

sudo mkdir -p /var/log/journal

Ou você pode editar o arquivo de configuração do diário:

sudo nano /etc/systemd/journald.conf

Na seção [Journal], defina a opção Storage= como \persistent para ativar o log persistente:

. . .
[Journal]
Storage=persistent

Quando salvar inicializações anteriores estiver ativado em seu servidor, journalctl fornecerá alguns comandos para ajudá-lo a trabalhar com inicializações como uma unidade de divisão. Para ver as botas que journald conhece, use a opção --list-boots com journalctl:

journalctl --list-boots

Output-2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
-1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
 0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC

Isso exibirá uma linha para cada inicialização. A primeira coluna é o deslocamento para a inicialização que pode ser usado para referenciar facilmente a inicialização com journalctl. Se você precisar de uma referência absoluta, o ID de inicialização estará na segunda coluna. Você pode saber a hora a que a sessão de inicialização se refere com as duas especificações de tempo listadas no final.

Para exibir as informações dessas botas, você pode usar as informações da primeira ou da segunda coluna.

Por exemplo, para ver o diário da inicialização anterior, use o ponteiro relativo -1 com o sinalizador -b:

journalctl -b -1

Você também pode usar o ID de inicialização para chamar de volta os dados de uma inicialização:

journalctl -b caf0524a1d394ce0bdbcff75b94444fe

Janelas de tempo

Embora ver as entradas de log por inicialização seja incrivelmente útil, muitas vezes você pode desejar solicitar janelas de tempo que não se alinham bem com as inicializações do sistema. Isso pode ser especialmente verdadeiro ao lidar com servidores de longa duração com tempo de atividade significativo.

Você pode filtrar por limites de tempo arbitrários usando as opções --since e --until, que restringem as entradas exibidas após ou antes do tempo determinado, respectivamente.

Os valores de tempo podem vir em uma variedade de formatos. Para valores de tempo absoluto, você deve usar o seguinte formato:

YYYY-MM-DD HH:MM:SS

Por exemplo, podemos ver todas as entradas desde 10 de janeiro de 2015 às 17h15 digitando:

journalctl --since "2015-01-10 17:15:00"

Se os componentes do formato acima forem deixados de fora, alguns padrões serão aplicados. Por exemplo, se a data for omitida, a data atual será assumida. Se o componente de tempo estiver faltando, \00:00:00 (meia-noite) será substituído. O campo dos segundos também pode ser deixado de fora para o padrão \00:

journalctl --since "2015-01-10" --until "2015-01-11 03:00"

O diário também entende alguns valores relativos e atalhos nomeados. Por exemplo, você pode usar as palavras \ontem, \hoje, \amanhã ou \agora. Você pode fazer tempos relativos acrescentando \- ou \+ a um valor numerado ou usando palavras como \atrás na construção de uma frase.

Para obter os dados de ontem, você pode digitar:

journalctl --since yesterday

Se você recebeu relatórios de interrupção de serviço começando às 9h e continuando até uma hora atrás, digite:

journalctl --since 09:00 --until "1 hour ago"

Como você pode ver, é relativamente simples definir janelas de tempo flexíveis para filtrar as entradas que você deseja ver.

Filtragem por interesse de mensagem

Acima, aprendemos algumas maneiras de filtrar os dados do diário usando restrições de tempo. Nesta seção, discutiremos como filtrar com base em qual serviço ou componente você está interessado. O diário systemd fornece várias maneiras de fazer isso.

Por unidade

Talvez a maneira mais útil de filtrar seja pela unidade em que você está interessado. Podemos usar a opção -u para filtrar desta forma.

Por exemplo, para ver todos os logs de uma unidade Nginx em nosso sistema, podemos digitar:

journalctl -u nginx.service

Normalmente, você provavelmente também deseja filtrar por tempo para exibir as linhas nas quais está interessado. Por exemplo, para verificar como o serviço está sendo executado hoje, você pode digitar:

journalctl -u nginx.service --since today

Esse tipo de foco torna-se extremamente útil quando você aproveita a capacidade do diário de intercalar registros de várias unidades. Por exemplo, se seu processo Nginx estiver conectado a uma unidade PHP-FPM para processar conteúdo dinâmico, você pode mesclar as entradas de ambos em ordem cronológica especificando ambas as unidades:

journalctl -u nginx.service -u php-fpm.service --since today

Isso pode tornar muito mais fácil identificar as interações entre diferentes programas e sistemas de depuração em vez de processos individuais.

Por processo, usuário ou ID de grupo

Alguns serviços geram uma variedade de processos filhos para realizar o trabalho. Se você pesquisou o PID exato do processo em que está interessado, também pode filtrá-lo.

Para fazer isso, podemos filtrar especificando o campo _PID. Por exemplo, se o PID que nos interessa é 8088, podemos digitar:

journalctl _PID=8088

Em outras ocasiões, você pode querer mostrar todas as entradas registradas de um usuário ou grupo específico. Isso pode ser feito com os filtros _UID ou _GID. Por exemplo, se o seu servidor web for executado sob o usuário www-data, você poderá encontrar o ID do usuário digitando:

id -u www-data

Output33

Depois, você pode usar o ID que foi retornado para filtrar os resultados do diário:

journalctl _UID=33 --since today

O diário systemd possui muitos campos que podem ser usados para filtragem. Alguns deles são passados do processo que está sendo registrado e alguns são aplicados pelo journald usando informações que ele coleta do sistema no momento do registro.

O sublinhado inicial indica que o campo _PID é do último tipo. O diário registra e indexa automaticamente o PID do processo que está registrando para filtragem posterior. Você pode descobrir todos os campos de diário disponíveis digitando:

man systemd.journal-fields

Discutiremos alguns deles neste guia. Por enquanto, porém, examinaremos mais uma opção útil relacionada à filtragem por esses campos. A opção -F pode ser usada para mostrar todos os valores disponíveis para um determinado campo de diário.

Por exemplo, para ver para quais IDs de grupo o diário systemd tem entradas, você pode digitar:

journalctl -F _GID

Isso mostrará todos os valores que o diário armazenou para o campo ID do grupo. Isso pode ajudá-lo a construir seus filtros.

Por Caminho do Componente

Também podemos filtrar fornecendo um local de caminho.

Se o caminho levar a um executável, journalctl exibirá todas as entradas que envolvem o executável em questão. Por exemplo, para encontrar as entradas que envolvem o executável bash, você pode digitar:

journalctl /usr/bin/bash

Normalmente, se uma unidade estiver disponível para o executável, esse método é mais limpo e fornece informações melhores (entradas de processos filhos associados, etc). Às vezes, porém, isso não é possível.

Exibindo Mensagens do Kernel

As mensagens do kernel, aquelas normalmente encontradas na saída dmesg, também podem ser recuperadas do diário.

Para exibir apenas essas mensagens, podemos adicionar os sinalizadores -k ou --dmesg ao nosso comando:

journalctl -k

Por padrão, isso exibirá as mensagens do kernel da inicialização atual. Você pode especificar uma inicialização alternativa usando os sinalizadores normais de seleção de inicialização discutidos anteriormente. Por exemplo, para obter as mensagens de cinco inicializações atrás, você pode digitar:

journalctl -k -b -5

Por Prioridade

Um filtro no qual os administradores de sistema geralmente estão interessados é a prioridade da mensagem. Embora muitas vezes seja útil registrar informações em um nível muito detalhado, ao digerir as informações disponíveis, os logs de baixa prioridade podem distrair e confundir.

Você pode usar journalctl para exibir apenas mensagens de uma prioridade especificada ou superior usando a opção -p. Isso permite que você filtre as mensagens de prioridade mais baixa.

Por exemplo, para mostrar apenas as entradas registradas no nível de erro ou acima, você pode digitar:

journalctl -p err -b

Isso mostrará todas as mensagens marcadas como erro, crítica, alerta ou emergência. O diário implementa os níveis de mensagem syslog padrão. Você pode usar o nome da prioridade ou seu valor numérico correspondente. Em ordem da prioridade mais alta para a mais baixa, são eles:

0: emergir
1: alerta
2: crítico
3: erro
4: aviso
5: aviso
6: informações
7: depuração

Os números ou nomes acima podem ser usados alternadamente com a opção -p. Selecionar uma prioridade exibirá mensagens marcadas no nível especificado e aquelas acima dele.

Modificando a Exibição do Diário

Acima, demonstramos a seleção de entrada por meio de filtragem. No entanto, existem outras maneiras de modificar a saída. Podemos ajustar a exibição journalctl para atender a várias necessidades.

Truncar ou expandir a saída

Podemos ajustar como o journalctl exibe os dados informando-o para reduzir ou expandir a saída.

Por padrão, journalctl mostrará toda a entrada no pager, permitindo que as entradas fiquem à direita da tela. Esta informação pode ser acessada pressionando a tecla de seta para a direita.

Se preferir que a saída seja truncada, inserindo reticências onde as informações foram removidas, você pode usar a opção --no-full:

journalctl --no-full

Output. . .

Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot

Você também pode ir na direção oposta com isso e dizer ao journalctl para exibir todas as suas informações, independentemente de incluir caracteres não imprimíveis. Podemos fazer isso com o sinalizador -a:

journalctl -a

Saída para Saída Padrão

Por padrão, journalctl exibe a saída em um pager para facilitar o consumo. No entanto, se você planeja processar os dados com ferramentas de manipulação de texto, provavelmente deseja produzir na saída padrão.

Você pode fazer isso com a opção --no-pager:

journalctl --no-pager

Isso pode ser canalizado imediatamente para um utilitário de processamento ou redirecionado para um arquivo no disco, dependendo de suas necessidades.

Formatos de saída

Se você estiver processando entradas de diário, conforme mencionado acima, provavelmente terá mais facilidade em analisar os dados se estiverem em um formato mais consumível. Felizmente, o diário pode ser exibido em vários formatos, conforme necessário. Você pode fazer isso usando a opção -o com um especificador de formato.

Por exemplo, você pode gerar as entradas de diário em JSON digitando:

journalctl -b -u nginx -o json

Output{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }

. . .

Isso é útil para analisar com utilitários. Você pode usar o formato json-pretty para entender melhor a estrutura de dados antes de passá-la para o consumidor JSON:

journalctl -b -u nginx -o json-pretty

Output{
	"__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
	"__REALTIME_TIMESTAMP" : "1422990364739502",
	"__MONOTONIC_TIMESTAMP" : "27200938",
	"_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
	"PRIORITY" : "6",
	"_UID" : "0",
	"_GID" : "0",
	"_CAP_EFFECTIVE" : "3fffffffff",
	"_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
	"_HOSTNAME" : "desktop",
	"SYSLOG_FACILITY" : "3",
	"CODE_FILE" : "src/core/unit.c",
	"CODE_LINE" : "1402",
	"CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
	"SYSLOG_IDENTIFIER" : "systemd",
	"MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
	"_TRANSPORT" : "journal",
	"_PID" : "1",
	"_COMM" : "systemd",
	"_EXE" : "/usr/lib/systemd/systemd",
	"_CMDLINE" : "/usr/lib/systemd/systemd",
	"_SYSTEMD_CGROUP" : "/",
	"UNIT" : "nginx.service",
	"MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
	"_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
}

. . .

Os seguintes formatos podem ser usados para exibição:

cat: Exibe apenas o próprio campo da mensagem.
exportar: 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 agrupada para tornar compatível adicionar evento enviado pelo servidor
short: A saída padrão do 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 timestamps monotônicos.
short-precise: O formato padrão com precisão de microssegundos
verbose: Mostra todos os campos do diário disponíveis para a entrada, incluindo aqueles geralmente ocultos internamente.

Essas opções permitem que você exiba os lançamentos contábeis manuais no formato que melhor se adapte às suas necessidades atuais.

Monitoramento de processo ativo

O comando journalctl imita quantos administradores usam tail para monitorar atividades ativas ou recentes. Essa funcionalidade é incorporada ao journalctl, permitindo que você acesse esses recursos sem precisar canalizar para outra ferramenta.

Exibindo Logs Recentes

Para exibir uma quantidade definida de registros, você pode usar a opção -n, que funciona exatamente como tail -n.

Por padrão, ele exibirá as 10 entradas mais recentes:

journalctl -n

Você pode especificar o número de entradas que gostaria de ver com um número após -n:

journalctl -n 20

Seguindo registros

Para acompanhar ativamente os logs conforme eles estão sendo gravados, você pode usar o sinalizador -f. Novamente, isso funciona como você pode esperar se tiver experiência usando tail -f:

journalctl -f

Para sair deste comando, digite CTRL+C.

Manutenção do Diário

Você pode estar se perguntando sobre o custo de armazenar todos os dados que vimos até agora. Além disso, pode ser interessante limpar alguns logs antigos e liberar espaço.

Encontrando o uso atual do disco

Você pode descobrir a quantidade de espaço que o diário está ocupando no disco usando o sinalizador --disk-usage:

journalctl --disk-usage

OutputArchived and active journals take up 8.0M in the file system.

Apagando Logs Antigos

Se você deseja reduzir seu diário, pode fazer isso de duas maneiras diferentes (disponível com systemd versão 218 e posterior).

Se você usar a opção --vacuum-size, poderá reduzir seu diário indicando um tamanho. Isso removerá as entradas antigas até que o espaço total do diário ocupado no disco esteja no tamanho solicitado:

sudo journalctl --vacuum-size=1G

Outra maneira de reduzir o diário é fornecer um tempo limite com a opção --vacuum-time. Quaisquer entradas além desse tempo são excluídas. Isso permite que você mantenha as entradas que foram criadas após um horário específico.

Por exemplo, para manter as entradas do último ano, você pode digitar:

sudo journalctl --vacuum-time=1years

Limitando a Expansão do Diário

Você pode configurar seu servidor para colocar limites em quanto espaço o diário pode ocupar. Isso pode ser feito editando o arquivo /etc/systemd/journald.conf.

Os seguintes itens podem ser usados para limitar o crescimento do diário:

SystemMaxUse=: Especifica o espaço máximo em disco que pode ser usado pelo diário em armazenamento persistente.
SystemKeepFree=: especifica a quantidade de espaço que o diário deve deixar livre ao adicionar entradas de diário ao armazenamento persistente.
SystemMaxFileSize=: Controla o tamanho que os arquivos de diário individuais podem atingir no armazenamento persistente antes de serem girados.
RuntimeMaxUse=: Especifica o espaço máximo em disco que pode ser usado em armazenamento volátil (dentro do sistema de arquivos /run).
RuntimeKeepFree=: Especifica a quantidade de espaço a ser reservada para outros usos ao gravar dados em armazenamento volátil (dentro do sistema de arquivos /run).
RuntimeMaxFileSize=: especifica a quantidade de espaço que um arquivo de diário individual pode ocupar no armazenamento volátil (dentro do sistema de arquivos /run) antes de ser girado.

Definindo esses valores, você pode controlar como journald consome e preserva espaço em seu servidor. Lembre-se de que SystemMaxFileSize e RuntimeMaxFileSize terão como alvo os arquivos arquivados para atingir os limites estabelecidos. Isso é importante lembrar ao interpretar contagens de arquivos após uma operação de aspiração.

Conclusão

Como você pode ver, o diário systemd é incrivelmente útil para coletar e gerenciar seus dados de sistema e aplicativos. A maior parte da flexibilidade vem dos extensos metadados registrados automaticamente e da natureza centralizada do log. O comando journalctl facilita o aproveitamento dos recursos avançados do diário e a realização de análises extensivas e depuração relacional de diferentes componentes do aplicativo.