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
