Introdução ao Systemd Journal

Introdução ao Systemd Journal

Atualmente, o Systemd está no sistema init adotado por quase todas as distribuições Linux, do Red Hat Enterprise Linux a Debian e Ubuntu. Uma das coisas que tornaram o SystemD o alvo de muitos críticos é que ele tenta ser muito mais do que um simples sistema init e tenta reinventar alguns subsistemas Linux.

O sistema de registro tradicional usado no Linux, por exemplo, foi rsyslog, uma versão moderna do tradicional syslog. Systemd introduziu seu próprio sistema de registro: é implementado por um daemon, Journal, que armazena logs no formato binário em um "diário", que pode ser consultado pelo JournalCtl Utilitário.

Neste tutorial, aprenderemos alguns parâmetros que podemos usar para modificar o Journal comportamento da daemon e alguns exemplos de como consultar o diário e formatar a saída resultante das referidas consultas.

Neste tutorial, você aprenderá:

  • Como alterar as configurações de jornal padrão
  • Como Journald pode coexistir com syslog
  • Como consultar o diário e algumas maneiras de formatar a saída de consultas

Requisitos de software e convenções usadas

Requisitos de software e convenções de linha de comando Linux
Categoria Requisitos, convenções ou versão de software usada
Sistema Uma distribuição Linux usando o Systemd (quase todos)
Programas Nenhum software específico é necessário
Outro Privilégios de raiz para (eventualmente) alterar as configurações padrão
Convenções # - linux -commands a serem executados com privilégios de raiz diretamente como usuário root ou por uso de sudo comando
$-Linux-commands para serem executados como um usuário não privilegiado regular

Arquivo de configuração do Journald

O comportamento do Journal Daemon pode ser modificado alterando as configurações em seu arquivo de configuração: /etc/Systemd/Journald.conf. A modificação direta deste arquivo não é recomendada; Em vez disso, devemos criar alguns arquivos de configuração separados que contêm os parâmetros que pretendemos mudar, salve -os com o .conf extensão e coloque -os dentro do /etc/Systemd/Journald.conf.d diretório.

Os arquivos colocados dentro do /etc/Systemd/Journald.conf.d diretório tem uma precedência maior do que /etc/Systemd/Journald.conf: Eles são classificados pelo nome deles em ordem lexicográfica e analisou nessa ordem, tudo após o arquivo principal. Caso exista a mesma configuração de opção em mais de um arquivo, a última a ser analisada será eficaz.

O /etc/systemd/jourlnald.conf Arquivo, por padrão, contém uma lista comentada de opções dentro do [Diário] Stanza: eles representam os valores padrão usados ​​no tempo de compilação (o conteúdo abaixo é de um sistema de Fedora):

[Journal] #Storage = Auto #compact = Sim #SEAL = Sim #splitMode = uid #syncintervalsec = 5m #ratelimitintervalsec = 30s #rateliMitburst = 10000 #SystemMaxuse = #SystemkeepFree = #SystemMaxFilesize = #SystemMaxFiles = #RUNTIMAXEX #Runtimemaxfilesize = #runtimemaxfiles = 100 #maxretentionsec = #maxfileSec = 1Morth #forwardToSySlog = não #forwardTokmsg = não #forwardTocOnsole = no #forwardTowall = sim #ttypath =/dev/console #maxlevelSxEx = #dencugum MAXLevel = MaxlevelConsole = info #maxlevelwall = emerg #linemax = 48k #readkmsg = sim #audit = sim 


Vamos ver qual é o significado de algumas dessas opções e como elas podem mudar o comportamento do Journal Daemon.

A opção "armazenamento"

A primeira opção que encontramos no arquivo é Armazenar. Esta opção controla onde os dados da revista são armazenados. O valor padrão usado no momento da compilação aqui está auto, Mas é possível escolher entre:

  • volátil
  • persistente
  • auto
  • nenhum

Se usarmos volátil Como o valor desta opção, os dados do diário serão armazenados apenas na memória em /RUN/LOG/Journal (/correr é um tmpfs: seu conteúdo é armazenado na memória), por isso não sobreviverá a uma reinicialização do sistema.

Se persistente é usado em vez disso, os dados do diário serão armazenados no disco, em /var/log/diário, que é criado se não existir. Se por algum motivo o disco não for gravável, no entanto, /RUN/LOG/Journal é usado como um retorno.

O auto valor para o Armazenar opção, que aqui é usada como padrão, funciona basicamente como persistente No sentido de que, quando é usado, os dados do diário são armazenados em /var/log/diário. A diferença é que, se o caminho não existir, não for criado e os logs serão armazenados apenas na memória.

Finalmente, se o nenhum O valor é usado, todo o armazenamento está desligado: ao encaminhar para outros sistemas de registro, como syslog Ainda funcionará, todos os dados recebidos serão retirados.

A opção "compactação"

A opção "compactar" controla se os dados excedem o limite de 512 Bytes é comprimido antes de ser armazenado no disco. Esta opção aceita dois tipos de valores: a boleano Como no caso acima (sim), ou um número que define o próprio limite de compressão. Se o último for fornecido, a compressão será ativada implicitamente. O valor limiar é, por padrão, expresso em bytes, mas o K, M ou G Os sufixos podem ser usados ​​em vez disso.

A opção "Forwardtosyslog"

Como já mencionado, na era pré-Systemd, os troncos foram gerenciados pelo syslog Sistema de registro (rsyslog na verdade). Este sistema de registro é capaz de encaminhar logs para muitos destinos, como arquivos de texto, terminais ou até outras máquinas na rede. A Systemd implementou seu próprio sistema de registro, que é o objeto deste tutorial: Journal.

Os dois sistemas podem coexistir (isso às vezes é necessário, já que o Journald perde alguns recursos como registro centralizado, ou apenas porque nós, como administradores, podemos gostar de logs a serem armazenados em arquivos de texto em vez de em formato binário, para que possam ser manipulados com ferramentas Unix padrão).

Esse ForwardToSysLog a opção leva um boleano Valor: se definido como sim, As mensagens serão encaminhadas para o /run/systemd/journal/syslog soquete, onde pode ser lido por syslog. Este comportamento também pode ser definido em inicialização através do Systemd.Journal.forward_to_syslog opção.

Opções semelhantes podem ser usadas para encaminhar mensagens para kmsg (Buffer de log do kernel), para consolar ou "parede" (enviado como mensagens de log para usuários conectados). Apenas o último está definido como sim por padrão.

Consultando o diário

A ferramenta que podemos usar para examinar os registros do sistema e consultar o Systemd Journal é JournalCtl. Se o comando for chamado sem mais parâmetros, todo o conteúdo da revista será exibido. Felizmente, várias estratégias podem ser implementadas para filtrar os logs. Vamos ver alguns deles.

Filtrando mensagens por unidades

Uma das opções mais úteis para as quais podemos passar JournalCtl é -você, qual é a versão curta de --unidade. Com esta opção, podemos filtrar o conteúdo da revista para que apenas mensagens do específico Systemd-Unit passou como o argumento da opção é retornado. Por exemplo, para exibir apenas mensagens provenientes do Gerente da rede.serviço unidade, podemos correr:

$ journalctl -u NetworkManager-Os registros começam em 2020-07-01 21:47:23 CEST, termine em SAT 2020-07-25 15:26:59 CEST. -- 01 de julho 21:48:07 Eru Systemd [1]: Iniciando gerente de rede… 01 de julho 21:48:07 Eru NetworkManager [1579]: [1593632887.7408] NetworkManager (versão 1.22.10-1.FC32) está começando… (pela primeira vez) 01 de julho 21:48:07 Eru NetworkManager [1579]: [1593632887.7413] Leia Config:/etc/NetworkManager/NetworkManager.Conf Jul 01 21:48:07 Eru Systemd [1]: Iniciado gerente de rede. 

Além disso, uma opção específica é dedicada a filtrar apenas as mensagens do kernel: -k, qual é a forma curta de --DMESG.

Filtrando logs por data

Se queremos filtrar as mensagens armazenadas no diário por data, podemos usar duas opções dedicadas: -S (abreviatura de --desde) e -você (abreviatura de --até). Ambas as opções aceitam uma data no formato AAA AYYY-MM-DD HH: MM: SS. A parte "horário" da data pode ser omitida e, nesse caso 00:00:00 é assumido. Suponha que queremos filtrar os logs a partir da data atual; Nós executamos o seguinte comando:

$ journalctl-desde 2020-07-25 


Para restringir ainda mais os logs com um tempo de 16:04:21 para 16:04:26:

$ JournalCtl--Desde "2020-07-25 16:04:21" --until "2020-07-25 16:04:26" 

Também existem uma série de aliases: eles podem ser usados ​​em vez de datas simples:

Corda Significado
"ontem" 00:00:00 do dia antes do atual
"hoje" o dia atual
"amanhã" no dia seguinte ao atual
"agora" o horário atual

Exibindo apenas os últimos logs

Se lançarmos o JournalCtl comando com o -f (--seguir) Opção, podemos visualizar apenas os últimos toras recebidas e ainda observar como novos logs são anexados a ele (é basicamente como ligar cauda com o -f opção). Por outro lado, se queremos apenas visualizar o fim do diário, podemos usar o -e opção (--Pager-End).

Formatando a saída do JournalCTL

A saída que recebemos ao usar JournalCtl pode ser facilmente formatado usando uma opção dedicada: -o, ou sua versão longa, --saída. Ao usar esta opção, podemos especificar entre uma série de "estilos". Entre os (muitos) outros:

  • curto
  • detalhado
  • JSON-PRETTY

O curto O formato é o padrão: uma linha por entrada é exibida em uma saída semelhante à do syslog tradicional:

01 de julho 21:48:07 Eru Systemd [1]: Iniciando gerente de rede… 

O detalhado O formato, em vez disso, faz com que todos os campos da entrada sejam exibidos:

Qua 2020-07-01 21:48:07.603130 CEST [s=d61cdf3710e84233bda460d931ebc3bb;i=6be;b=1c06b8c553624a5f94e1d3ef384fb50d;m=2e82666;t=5a966922b0155;x=6668aad5e895da03] PRIORITY=6 _BOOT_ID=1c06b8c553624a5f94e1d3ef384fb50d _MACHINE_ID=afe15f1a401041f4988478695a02b2bf _HOSTNAME=eru SYSLOG_FACILITY=3 SYSLOG_IDENTIFIER=systemd _UID=0 _GID= 0 _Transport = Journal _cap_efffect = 3ffffffff code_file = src/core/job.c code_line = 574 code_func = JOB_LOG_BEGIN_STATUS_MESSAGE JOB_TYPE = Iniciar message_Id = 7d4958e842DA4A758F6C1CDC7B36DCC5 _PID = 1 _Comm = SystemD _EXE =/inDr/inB/sSemSyD =/inb36dc5 _pid =/systemd _exe =/nosrr/inb/inb/sSemSyd =/inb36b36dc5 _pid = Systemd _Exe =/inb36dc5.escopo _systemd_unit = init.escopo _systemd_slice =-.slice _selinux_context = System_u: System_r: init_t: s0 _cmdline =/usr/lib/Systemd/Systemd-Switched-Root-System--desseserialize 34 Mensagem = Gerenciador de rede inicial… Job_id = 243 Unidade = NetworkManager.Serviço Invocation_Id = 6416439E51FF4543A76BDED5984C6CF3 _SOURCE_REALTIME_TIMESTAMP = 1593632887603130 


O JSON-PRETTY formato exibe as entradas como JSON objetos de uma maneira legível pelo homem. Neste formato, as entradas são separadas por uma nova linha:

"__Realtime_timestamp": "1593632887603541", "Priority": "6", "_systemd_unit": "init.escopo "," _systemd_cgroup ":"/init.escopo "," _uid ":" 0 "," _comm ":" systemd "," _systemd_slice ":"-.slice", "_CAP_EFFECTIVE" : "3fffffffff", "_BOOT_ID" : "1c06b8c553624a5f94e1d3ef384fb50d", "_SELINUX_CONTEXT" : "system_u:system_r:init_t:s0", "__CURSOR" : "s=d61cdf3710e84233bda460d931ebc3bb;i=6be;b=1c06b8c553624a5f94e1d3ef384fb50d; m=2e82666;t=5a966922b0155;x=6668aad5e895da03", "_HOSTNAME" : "eru", "_PID" : "1", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "CODE_FUNC" : "job_log_begin_status_message", "MESSAGE" : " Iniciando gerente de rede ... "," _exe ":"/usr/lib/systemd/systemd "," __monotonic_timestamp ":" 48768614 "," _transport ":" Journal "," syslog_facility ":" 3, "unidade": " Gerente da rede.serviço "," job_id ":" 243 "," job_type ":" start "," _gid ":" 0 "," code_file ":" src/core/job/job.C "," _machine_id ":" AFE15F1A401041F4988478695A02B2BF "," _CMDLINE ":"/usr/lib/systemd/systemd--switched-root--SYSTEM-SYSYSTEM "SYSDELIZE 34 "574", "Invocation_id": "6416439e51ff4543a76bded5984c6cf3", "_source_realtime_timestamp": "1593632887603130" 

Conclusões

Neste tutorial, nos aproximamos Journal O daemon Systemd que implementa o diário de madeira. Este sistema de registro deve ser usado em vez de syslog, que era o sistema tradicional usado no Linux. Em muitas distribuições, por um motivo ou outro, os dois sistemas ainda coexistem.

Vimos o que é o Journal arquivo de configuração e qual é o significado de algumas opções importantes que podem ser usadas para modificar seu comportamento, e aprendemos como podemos consultar o diário do Systemd com o JournalCtl Utilitário. Se você quiser saber mais sobre Journal e JournalCtl. Eu sugiro que você leia os respectivos manuais (Homem Journald.conf e Man JournalCtl são os comandos que você está procurando).

Tutoriais do Linux relacionados:

  • Loging e auditoria avançados no Linux
  • Coisas para instalar no Ubuntu 20.04
  • Arquivos de configuração do Linux: os 30 primeiros mais importantes
  • Coisas para fazer depois de instalar o Ubuntu 20.04 fossa focal linux
  • Download do Linux
  • Uma introdução à automação, ferramentas e técnicas do Linux
  • Coisas para fazer depois de instalar o Ubuntu 22.04 Jellyfish…
  • Linux pode obter vírus? Explorando a vulnerabilidade do Linux…
  • Melhor distro Linux para desenvolvedores
  • Coisas para instalar no Ubuntu 22.04