Linux server administrator Journald beginner's guide

Journald is a new system log method created for Linux servers. it marks the end of text log files. Now the log information is written to the binary file and read using journalctl. to obtain this information, the Linux administrator will need some practices. RedHatEnterpriseLin label: Linux server

Journald is a new system log method created for Linux servers. it marks the end of text log files. Now the log information is written to the binary file and read using journalctl. to obtain this information, the Linux administrator will need some practices.

The next-generation Linux releases, Red Hat Enterprise Linux 7 and SUSE Linux Enterprise Server 12, use the systemd management service. Journal is a component of systemd, which is processed by journald. It captures system log information, kernel log information, and information from the original RAM disk, early start information, and information written to STDOUT and STDERR data streams in all services. Journald quickly changes how servers process log information and how administrators access it.

Goodbye to log files

There is no log file location in the systemd and journald worlds. Journald logs are written to binary files in/run/log/journal on the RedHat system. You should not or use a page to open a file. Instead, use journalctl to view the content. This command displays all login information to the server (see table 1 ).

Table 1: default format of the journalctl output table.

 
 

  
  
Apr 04 09:48:59 localhost.localdomain chronyd[768]: Can't synchronise: no majority 
  
  
Apr 04 09:50:01 localhost.localdomain systemd[1]: Starting Session 3 of user root. 
  
  
Apr 04 09:50:01 localhost.localdomain systemd[1]: Started Session 3 of user root. 
  
  
Apr 04 09:50:01 localhost.localdomain CROND[3699]: (root) CMD (/usr/lib64/sa/sa1 1 1) 
  
  
Apr 04 09:50:03 localhost.localdomain chronyd[768]: Selected source 46.249.47.127 
  
  
Apr 04 09:50:03 localhost.localdomain chronyd[768]: System clock wrong by -2.417074 seconds, adjustment started 
  
  
Apr 04 09:50:36 localhost.localdomain pulseaudio[3163]: [alsa-sink] alsa-sink.c: ALSA woke us up to write new data to the device, but there 
  
  
Apr 04 09:50:36 localhost.localdomain pulseaudio[3163]: [alsa-sink] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_ens1371'. 
  
  
Apr 04 09:50:36 localhost.localdomain pulseaudio[3163]: [alsa-sink] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent s 
  
  
Apr 04 09:51:07 localhost.localdomain chronyd[768]: Selected source 81.171.44.131 
  
  
Apr 04 09:52:12 localhost.localdomain chronyd[768]: System clock wrong by 0.669116 seconds, adjustment started 
  
  
Apr 04 09:53:17 localhost.lo 
 
 

No worries. journalctl has many filtering options. Journalctl-B filters information generated at startup. Journalctl -- since = yesterday only displays information starting from yesterday's logon. The administrator can search for information from the specific number of days, for example, journalctl -- since = -- until = "23:59:59 ". Use journalctl-u httpd since = -- until = to view the httpd process logged on last night. If the administrator has advanced journald filtering options, it is easier to analyze log files.

In some cases, the default log information displayed by journalctl is not detailed enough. For more information, set the output format to verbose and run the journalctl-o verbose-n command.

Table 2: by displaying verbose log information, the Linux administrator can obtain more information from the log file.

 
 

  
  
Fri 2014-04-04 10:12:32.072521 CEST [s=a52ddd97575747a18c6378d388b2b9ff;i=955;b=bc03fb52eddb41 
  
  
b0bb4829ae19c1c286;m=8f1dd 5f2;t=4f633145a58d9; 
  
  
PRIORITY=6 
  
  
_UID=0 
  
  
_GID=0 
  
  
_BOOT_ID=bc03fb52eddb41b0bb4829ae19c1c286 
  
  
_MACHINE_ID=1fbfd90ac4fc49919fe1b63d6bcf9097 
  
  
_HOSTNAME=localhost.localdomain 
  
  
SYSLOG_FACILITY=3 
  
  
_TRANSPORT=syslog 
  
  
_SYSTEMD_CGROUP=/system.slice/network.service 
  
  
_SYSTEMD_UNIT=network.service 
  
  
SYSLOG_IDENTIFIER=dhclient 
  
  
_COMM=dhclient 
  
  
E=/usr/sbin/dhclient 
  
  
_CMDLINE=/sbin/dhclient -H localhost -1-q-lf/var/lib/dhclient/dhclient-0b5faf33-6df0-4f11-bbb9-659b5cd940e9-ens33.lease -pf /var/run/ 
  
  
_CAP_EFFECTIVE=0000000000203402 
  
  
_SELINUX_CONTEXT=system_u:system_r:dhcpc_t:s0 
  
  
SYSLOG_PID=1760 
  
  
_PID=1760 
  
  
MESSAGE=bound to 192.168.4.232 -- renewal in 892 seconds. 
  
  
_SOURCE_REALTIME_TIMESTAMP=1396599152072521 
 
 

Logrotate and remote logs

Some of the operational methods you are used to have changed. Logrotate, a system that disables and archives log files, becomes increasingly large. On journald, there is no need to loop log files. It is built to monitor the remaining space on the storage volume. If the volume is full, delete the old record and release the space. To set a maximum size for journald logs, modify the SystemMaxUse parameter in the/etc/systemd/journal. conf file.

Remote logs are another issue. If your data center has a remote log server, it should be retained. Journald is not a complete replacement for centralized log servers, such as rsyslog or syslog-ng do. Journald does not provide an alternative option to log files from other servers or devices. No option is specified for which Log server can forward log events. If you want journald to store log information elsewhere, the best practice is to forward the information to [r] syslog [{d-ng}], where concentrated logs are processed.