Porque o Journalctl é Bacana e Porque o Syslog Vai Sobreviver Por Mais Uma Década

Sobre o Journalctl no Systemd

O Systemd usa o Journalctl, que é o utilitário para analisar registros do Systemd. Então muitas pessoas começaram a se adaptar ao uso do Journalctl para analisar os logs.

Obs. Saiba mais sobre as diferenças entre o init e o Systemd.

Bem, há prós e contras sobre este tipo de registro. Para administradores de sistema, o journalctl é uma ferramenta poderosa que simplifica a busca de entradas no arquivo de log.

Por outro lado, eu procurei e ainda não encontrei nenhuma ferramenta de monitoramento (por enquanto) que trabalhe com journalctl, portanto os logs ainda devem ser analisados usando comandos de filtragem desejados e existe até uma ferramenta com interface gráfica do Gnome que mostra e filtra as mensagens do Journalctl chamada gnome-logs, mas nesse artigo mostrarei apenas algumas formas de usar o journalctl via comandos no terminal.

Por que o Journalctl torna a vida mais fácil?

No syslog para filtrar logs, você precisaria fazer muitos “grep” em muitas linhas do arquivo /var/log/messages, e no journalctl você simplesmente pode filtrar as mensagens e trabalhar nelas.

(Vou citar alguns exemplos abaixo, mas no artigo mostrarei como usar melhor o Journalctl).

O journalctl tem preenchimento automático (é só apertar a tecla tab) mostrando-lhe as opções para usar.

journalctl  < TAB > 
_AUDIT_LOGINUID=             __MONOTONIC_TIMESTAMP=
_AUDIT_SESSION=              _PID=
_BOOT_ID=                    PRIORITY=
_CMDLINE=                    __REALTIME_TIMESTAMP=
CODE_FILE=                   _SELINUX_CONTEXT=
CODE_FUNC=                   _SOURCE_REALTIME_TIMESTAMP=
CODE_LINE=                   SYSLOG_FACILITY=
_COMM=                       SYSLOG_IDENTIFIER=
COREDUMP_EXE=                SYSLOG_PID=
__CURSOR=                    _SYSTEMD_CGROUP=
ERRNO=                       _SYSTEMD_OWNER_UID=
_EXE=                        _SYSTEMD_SESSION=
_GID=                        _SYSTEMD_UNIT=
_HOSTNAME=                   _TRANSPORT=
_KERNEL_DEVICE=              _UDEV_DEVLINK=
_KERNEL_SUBSYSTEM=           _UDEV_DEVNODE=
_MACHINE_ID=                 _UDEV_SYSNAME=
MESSAGE=                     _UID=
MESSAGE_ID=

Como você viu, existem muitas opções de filtragem disponíveis aqui. A maioria destas opções são auto-explicativas.

Se você quiser apenas para ver as entradas feitas por um comando em particular, digite journalctl _COMM= e então a tecla TAB, conforme abaixo.

 #journalctl _COMM =
 abrtd dnsmasq mtp-sonda tgtd sh
 anacron rede gnome-keyring-d smartd udisksd
 avahi-daemon hddtemp polkit-agente de ele smbd umount
 festança journal2gelf polkitd sshd userhelper
 blueman-mechani kdumpctl pulseaudio sssd_be yum
 chronyd krb5_child qemu-system-x86 su               
 colord libvirtd sealert sudo             
 logger crond systemd sendmail          
 dbus-daemon mcelog setroubleshootd systemd-journal  

• Se você digitar journalctl _COMM= sshd você só vai ver as mensagens criadas por sshd.

# journalctl _COMM= sshd

-- Logs begin at Tue 2013-07-23 08:46:28 CEST, end at Wed 2013-07-24 11:10:01 CEST. --
Jul 23 09:48:45 fedora.example.com sshd[2172]: Server listening on 0.0.0.0 port 22.
Jul 23 09:48:45 fedora.example.com sshd[2172]: Server listening on :: port 22.

• Normalmente queremos filtrar mensagens dentro de um intervalo de tempo específico.

 journalctl _COMM = crond --since "10:00" --until "11:00"
 - Logs começam em Tue 2013/07/23 08:46:28 CEST, terminam na quarta-feira 2013/07/24 11:23:25 CEST.  -
 24 de julho 10:20:01 fedora.example.com crond [28305]: (root) CMD (/ usr / lib64 / sa / sa1 1 1)
 24 de julho 10:50:01 fedora.example.com crond [28684]: (root) CMD (/ usr / lib64 / sa / sa1 1 1)

E Por quê o Rsyslog Vai Durar Mais Uma Década Ou Até Mais?

Há uma grande quantidade de ferramentas e scripts que estão em vigor há muito tempo, alguns deles até mesmo vieram de um tempo antes de Linux nascer.

A maioria desses scripts devem ser reescritos ou pelo menos mudar o seu comportamento. Ou seja, tendo a entrada de STDIN ao invés de um arquivo de log, por isso, essas ferramentas podem atrasar bastante a transição geral para o Journalctl, e parece que o syslogd vai mesmo sobreviver até o último desses sistemas ser encerrado.

Quer saber mais sobre como usar o Journalctl? Leia o artigo abaixo:

Como Analisar Logs com o Journalctl

Dá para usar os dois juntos?

Sim! O journal do systemd pode ser usado com uma já existente aplicação syslog, ou pode substituir a funcionalidade do syslog dependendo de suas necessidades. Enquanto o journal do systemd vai cobrir as necessidades de registro de administradores, ele também pode complementar os mecanismos de registro existentes. Por exemplo, você pode ter em um servidor o sistema centralizado syslog que você usa para compilar dados de múltiplos servidores, mas você também pode querer intercalar os logs de múltiplos serviços em um único sistema com o journal systemd. Você pode fazer ambos ao combinar essas tecnologias.

O SUSE Enterprise e openSUSE por exemplo usam o systemd e o Journalctl para colher logs, mas você pode instalar o rsyslog também para colher logs. Claro que os dois juntos irão consumir mais processamento e você terá dados redundantes, mas se você deseja isso para uma utilização específica como nos exemplos citados no parágrafo anterior, então pode ser útil para você.

Abraços,

Cleuber

fonte: blogdelouw