Als alter “syslog-ng” Nutzer tue ich mir immer wieder hart mit der Protokollierung durch “systemd”. Der Schlüssel-Befehl “journactl” ist mir natürlich präsent – aber welche Opionen muss ich dann wählen, um die Unzahl von Journal-Einträge nach solchen zu ganz bestimmten Services oder Kommandos zu filtern?
Den entscheidenden Tip für Dummies wie mich habe ich hier gefunden:
http://blog.delouw.ch/2013/07/24/why-journalctl-is-cool-and-syslog-will-survive-for-another-decade/
(Vielen Dank für den hilfreichen Blog-Artikel).
journactl hat eine Autocompletion-Funktionalität über die Tab-Taste:
Generelle Filter-Optionen erreicht man über
journalctl <TAB>[<TAB>]
Ggf. muss man die TAB-Taste 2-mal drücken.
mytux:~ # journalctl
CODE_FILE= _KERNEL_DEVICE=
CODE_FUNC= _KERNEL_SUBSYSTEM=
CODE_LINE= _MACHINE_ID=
COREDUMP_EXE= _PID=
ERRNO= _SELINUX_CONTEXT=
MESSAGE= _SOURCE_REALTIME_TIMESTAMP=
MESSAGE_ID= _SYSTEMD_CGROUP=
PRIORITY= _SYSTEMD_OWNER_UID=
SYSLOG_FACILITY= _SYSTEMD_SESSION=
SYSLOG_IDENTIFIER= _SYSTEMD_UNIT=
SYSLOG_PID= _TRANSPORT=
_AUDIT_LOGINUID= _UDEV_DEVLINK=
_AUDIT_SESSION= _UDEV_DEVNODE=
_BOOT_ID= _UDEV_SYSNAME=
_CMDLINE= _UID=
_COMM= __CURSOR=
_EXE= __MONOTONIC_TIMESTAMP=
_GID= __REALTIME_TIMESTAMP=
_HOSTNAME=
Das ist doch schon sehr hilfreich. Da die meisten System-Services direkt zu irgendwelchen “systemd UNITs” korrespondieren, kommt man hier schon ein gutes Stück weiter. Beispiel:
mytux:~ # journalctl _SYSTEMD_UNIT=sshd.service
-- Logs begin at Fri 2014-12-19 17:40:02 CET, end at Sun 2015-09-27 19:02:35 CEST. --
......
-- Reboot --
Jan 24 10:49:37 mytux sshd-gen-keys-start[5942]: Checking for missing server keys in /etc/ssh
Jan 24 10:49:37 mytux sshd[5947]: Server listening on 0.0.0.0 port 22.
Jan 24 10:49:37 mytux sshd[5947]: Server listening on :: port 22.
Jan 24 10:50:03 mytux sshd[5971]: Accepted keyboard-interactive/pam for root from xxx.xxx.xxx.xxx port 33032 ssh2
Jan 24 10:50:03 mytux sshd[5971]: pam_unix(sshd:session): session opened for user root by (uid=0)
Jan 24 10:50:03 mytux sshd[6013]: Accepted keyboard-interactive/pam for root from xxx.xxx.xxx.xxx port 33033 ssh2
Jan 24 10:50:03 mytux sshd[6013]: pam_unix(sshd:session): session opened for user root by (uid=0)
Jan 24 12:10:20 mytux sshd[13201]: Accepted keyboard-interactive/pam for root from xxx.xxx.xxx.xxx port 33310 ssh2
.......
Oder:
mytux:~ # journalctl _SYSTEMD_UNIT=vmware.service
-- Logs begin at Fri 2014-12-19 17:40:02 CET, end at Sun 2015-09-27 19:07:41 CEST. --
Jan 03 09:31:07 mytux vmware[1475]: Starting VMware services:
Jan 03 09:31:07 mytux vmware[1475]: [33B blob data]
Jan 03 09:31:07 mytux vmware[1475]: [49B blob data]
Jan 03 09:31:07 mytux vmware[1475]: [50B blob data]
Jan 03 09:31:07 mytux vmware[1475]: [30B blob data]
Jan 03 09:31:07 mytux vmnetBridge[1775]: Bridge process created.
Jan 03 09:31:07 mytux vmnetBridge[1775]: RTM_NEWLINK: name:enp8s0 index:2 flags:0x00011043
Jan 03 09:31:07 mytux vmnetBridge[1775]: Adding
interface enp8s0 index:2
Jan 03 09:31:07 mytux vmnetBridge[1775]: Started bridge enp8s0 to virtual network 0.
.......
Erinnert man sich nicht mehr an laufende Services bzw. systemd-Units, so benutzt man die TAB-Taste erneut:
mytux:~ # journalctl _SYSTEMD_UNIT=<TAB>[<TAB>]
Display all 196 possibilities? (y or n)
Das Ganze geht auch für Optionen:
journalctl –<TAB>[<TAB>]
Also:
mytux:~ # journalctl -<TAB>[<TAB>]
--all --system
--boot --this-boot
--cursor --unit
--directory --until
--disk-usage --update-catalog
--field --user
--file --user-unit
--follow --verify
--full --verify-key
--header --version
--help -D
--interval -F
--lines -a
--list-boots -b
--list-catalog -c
--local -f
--merge -h
--new-id128 -l
--no-pager -m
--no-tail -n
--output -o
--priority -p
--quiet -q
--setup-keys -u
--since
Wie so oft führen bzgl. eines bestimmten Dienstes bzw. eines korrespondierenden Kommandos mehrere Wege zum Ziel:
mytux:~ # journalctl _SYSTEMD_UNIT=sshd.service
oder
mytux:~ # journalctl -u sshd
oder
mytux:~ # journalctl –unit sshd
und
rux:~ # journalctl _COMM=sshd
führen zu sehr ähnlichen Outputs. Der letzte Befehl zeigt am meisten an.
“_COMM” steht dabei für “Command” – das ermöglicht natürlich sehr vielfältige Filtermöglichkeiten – je nach Logging-Einstellungen.
Nun kombiniert man den Filter für eine Unit oder ein Komamndo noch mit einer Zeiteinschränkung über die Optionen “–since” und “–until” und jeweiligen Zeitstempeln im Format „2015-06-30 10:13:16“ – und schon fühlt man sich als Admin bzgl. der Analyse etwas besser. Z.B.:
mytux:~ # journalctl -u sshd –since “2015-06-30” –until “today”
Fazit: Durch die Autocompletion-Funktionalität wird einem der Gewöhnungsprozess an “journalctl” doch erheblich erleichtert. Man muss es halt nur wissen – und irgendwann sitzen die Kommando-Optionen auch bei mir.
Links:
https://wiki.archlinux.org/index.php/Systemd
http://0pointer.de/blog/projects/journalctl.html
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/s1-Using_the_Journal.html
https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs
