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