3 Basic Commands and Simple Shell Scripts Once you have your first Red Hat Enterprise Linux rhel
Finding logs, using journald, and reading log files
Download 1.85 Mb. View original pdf
|
- Navigate this page:
- Dandified YUM (DNF
| Finding logs, using journald, and reading log files, including log preservation and rotation In this section, you will learn how to review a system’s status via logs. Previously in this chapter, we learned how to manage system services via systemd, check their status, and check their logs. Traditionally, the different daemons and system components used to create files under the /var/log/ folder are based on the name of the daemon or service. If the service is used to create several logs, it would do so inside a folder for the service (for example, httpd or samba). The rsyslogd system log daemon has anew systemd partner—named systemd-journald. service—that also stores logs, but instead of using the traditional plain text format, it uses the binary format, which can be queried via the journalctl command. It’s really important to get used to reading the log files as it’s the basis for troubleshooting, so let’s learn about general logging and how to use it. Logs contain status information for the services that generate them. They might have some common formatting and can often be configured, but they tend to use several common elements, such as the following Timestamp Module generating the entry Message Here is an example: Jan 03 22:36:47 rhel-instance sshd[50197]: Invalid user admin from 49.232.135.77 port In this case, we can see that someone attempted to login to our system as the admin user from IP address We can correlate that event with additional logs, such as the ones for the login subsystem via journalctl -u systemd-logind. In this example, we cannot find any login for the admin user (this is expected, as the admin user was not defined in this system). Additionally, we can seethe name of the host (rhel-instance), the service generating it (sshd), a PID of 50197, and the message that’s been logged by that service. Tools for Regular Operations 132 In addition to journalctl, there are additional logs that we can look at when we wish to check the system’s health. Let’s look at an example with /var/log/messages: Figure 4.14 – Excerpt of /var/log/messages In this example, we can see how the system ran some commands while following a similar output to the initial lines. For example, in the preceding example, we can see how sysstat has been executed every 10 minutes, as well as how the dnf cache has been updated. Let’s look at a list of important logs that are available in a standard system installation (note that the filenames are relative to the /var/log folder boot.log: Stores the messages that are emitted by the system during boot. It might contain escape codes that are used to provide colorized output audit/audit.log: Contains the stored messages that have been generated by the kernel audit subsystem secure Contains security-related messages, such as failed sshd login attempts dnf.log: Logs generated by the Dandified YUM (DNF) package manager, such as cache refreshes firewalld: Output generated by the firewalld daemon. Finding logs, using journald, and reading log files, including log preservation and rotation lastlog: This is a binary file that contains information about the last few users logging into the system (to be queried via the last command messages The default logging facility. This means that anything that is not a specific log will go here. Usually, this is the best place to start checking what happened with a system maillog: The log for the mail subsystem. When enabled, it attempts to deliver messages. Any messages that are received will be stored here. It’s common practice to configure outgoing mail from servers so that system alerts or script outputs can be delivered btmp: Binary log for failed access to the system wtmp: Binary log for access to the system sa/sar*: Text logs for the sysstat utility (the binary ones, named sa, plus the day number, are converted via a cron job at night). Additional log files might exist, depending on the services that have been installed, the installation method that was used, and soon. It is very important to get used to the available logs and—of course— review their contents to see how the messages are formatted, how many logs are created everyday, and what kind of information they produce. Using the information that’s been logged, we will get hints on how to configure each individual daemon. This allows us to adjust the log level between showing just errors or being more verbose about debugging issues. This means we can configure the required log rotation to avoid risking system stability because all the space has been consumed by logs. Download 1.85 Mb. Share with your friends:
|