RHEL7.0 Log System

Source: Internet
Author: User
Tags rsyslog

Objective:

This article turns to self personal blog http://www.anyisalin.com welcome everyone to visit


This article is my note when I study RHCE7.0, I hope to be able to help you



System Log Schema



System log

The process and operating system cores need to be able to log in time that does not occur. These logs can be used for system audits and troubleshooting problems. Traditionally, these logs are stored permanently in the/var/log directory

RHEL7 in the log system

A standard logging system based on the System log protocol is built into Red Hat Enterprise Linux. Many programs use this system to log events and organize them into log files. syslog messages in Red Hat Enterprise Linux 7 are handled by two services, they are Systemd-journald and rsyslog.


The Systemd-journald daemon provides an improved log management service that collects messages from the kernel, early stages of the boot process, standard output, system logs, and errors during daemon startup and operation. It writes these messages to a structured event log, which is not retained by default between reboots. This allows system log messages and time that are missed by the system log to be collected in a central database. System messages can be forwarded by Systemd-journald to Rsyslog for further processing.

The Rsyslog service then arranges system log messages based on type (or device) and priority, and writes them to a permanent file within the/var/log directory.


The/var/log directory maintains a variety of system-and service-specific log files maintained by Rsyslog.


System Log File overview

Log file usage

/var/log/messages Most syslog messages are logged here. Exceptions are messages that run jobs periodically, related to authentication, e-mail processing, and purely debugging-related information.

/var/log/secure Security and authentication-related messages and error log files.

/var/log/maillog The log file associated with the mail server.

/var/log/boot.log messages related to system startup are logged here.



System log files

Many programs use the Syslog protocol to log time to the system. Each log message is categorized according to the device (type of message) and priority (the severity of the message). The available devices are outlined in the rsyslog.conf (5) man page.

Eight priority levels are standardized and graded as described below

Encoding priority severity

0Emerg system is not available.

1alert must take immediate action.

2crit serious condition.

3Err very serious error condition.

4warning warning status.

5Notice Normal but important events.

6Info Informational event.

7Debug debugging level messages.



The RSYSLOGD service uses the device and priority of the log message to determine how to handle it. This is configured through the/etc/rsyslog.conf file, as well as the *.conf file in/ETC/RSYSLOG.D. Programs and administrators can put custom files with the. conf suffix into the/ETC/RSYSLOG.D directory to change the RSYSLOGD configuration without being overwritten by rsyslog updates.


# # # # # # # #RULES ##### #部分包定义日志消息保存位置的相关指令/etc/rsyslog.conf. The left side of each line represents the device and severity of the log messages that match the instructions. The device and Severity fields of the rsyslog.conf file may contain the * character as a wildcard character, representing all devices and all severity levels. The right side of each line represents the file to save the log messages to. Log messages are typically stored in files in the/var/log directory.



Log files are maintained by the Rsyslog service, and the/var/log directory contains a variety of log files that are specific to certain services.

For example, the Apache Web server or Samba writes its own log files to the corresponding subdirectories in the/var/log directory.


Messages processed by Rsyslog may appear in several different log files, in order to avoid this situation, you can set the severity field to None,

All messages that are directed to this device are not added to the specified log file.


In addition to logging log file messages to a file, you can print them to the terminal of all logged-in users. In the default rsyslog.conf file, this is done for all messages with a priority of "Emerg".



Log file rotation

The logs are "rotated" through the logrotate utility to prevent them from filling up the file system that contains the/var/log/. When a log file is rotated, it is renamed with the name extension, and the name extension indicates the rotation date: If the file is rotated on October 30, 2014, the original/var/log/messages file becomes/var/log/messages-20141030. After the original, a new log file is created and the service is notified of the write operation.


Once rotated several times (usually rotated four times), discard the original log file to free up disk space. The cron job runs the Logrotate program once a day to see if any logs need to be rotated. Most log files are rotated once a week, but the logrotate rotate files are sometimes faster, sometimes slower, or rotated when a file reaches a certain size.

About the configuration of logrotate see Logrotate (8) man page





Analyzing System log Entries

The system log file written by Rsyslog displays the oldest message at the beginning of the file, displaying the most recent message at the end of the file. All log entries in the log files managed by Rsyslog are recorded in a standard format. The following example provides an in-depth description of the log messages in the/var/log/secure log file.


①feb 11 20:11:48②localhost③sshd[1438]④failed password for student from 172.25.0.10 Port 59344


① record the timestamp of the log entry

② the host that sent the log message

③ the program or process that sent the log message

Actual messages sent by ④




Using tail to monitor log files

One or more log files that monitor events, which is especially helpful for reproducing problems. The tail-f/path/to/file command outputs the last 0 lines of the specified file and continues to output them in a new write to the monitored file.


Sending system log messages using Logger

The logger command can send messages to the Rsyslog service. By default, his severity notice (user.notice) message is sent to the device user unless otherwise specified by the-P option. Testing for changes to the Rsyslog configuration is particularly useful.


To send a message to RSYSLOGD and record it in the/var/log/boot.log log file, you can do the following:

Logger-p Local7.notice logstring





View SYSTEMD Log Entries


Finding events by Journalctl

The SYSTEMD log stores the log data in a structured binary file with indexes. This data contains additional information related to log events. For example, for system log time, this can contain the device and priority of the original message.


In red Hat Enterprise Linux 7, the SYSTEMD log is stored by default in/run/log and its contents are purged after a reboot. This setting can be changed by the system administrator.


The Journalctl command displays the full system log starting from the oldest log entry.


The JOURNALCTL command highlights information in bold text with a priority of notice or warning, highlighting messages with a level of error or more advanced in red text.


The key to successfully using logs for troubleshooting and auditing is to limit log searches to show only related output.


By default, Journalctl-n displays the last 10 log entries. He can accept it. Specifies the last number of log entries that are displayed by an optional parameter. To display the last 5 log entries, you can run

Journalctl-n 5


Filtering the log file output according to the priority of the log entry when troubleshooting the issue it's very kind of journalctl-p to accept the name or number of a known priority as an argument, showing all specified levels and higher-level entries.

Journalctl-p Err

Similar to the tail-f command, journalctl-f outputs the last 10 lines of the log and continues to output them when new log entries are written to the log

Journalctl-f

When looking for events of a specific time, it is useful to limit the output to a specific time period, with the Journalctl command having two options to limit the output to a specific time range,--since and--until options, and two options to accept the format YYYY-MM-DD hh:mm: The time parameter of the SS. If the date is omitted, the command assumes that the log is the day, and if the time portion is omitted, it is assumed to be a full day since 00:00:00, except for the date and Time fields, which also accept yesterday,today and tomorrow as valid date parameters.


Outputs all log entries recorded on the current day.

Journalctl--since Today

Output February 10, 2014 20:30:00 to February 13, 2014 12:00:00 log entries

Journalctl--since "2014-02-10 20:30:00"--until "2014-02-13 12:00:00"


In addition to the visible contents of the log, the log entry comes with a field that is only visible when verbose output is turned on, and all additional fields displayed can be used to filter the output of the log query. This can be used to reduce the output of complex searches that look for specific events in the log.

Journalctl-o verbose

Other options for searching for rows about a particular process or event are also

The name of the _comm command _exe the path to the executable file of the process _pid the pid_uid of the process that runs the Uid_systemd_unit unit of the process that the user is running.


Can be combined into multiple options. For example, the query displays all the log entries that are related to the Systemd cell file Sshd.service startup, and the PID 1182 process.

Journalctl _systemd_unit=sshd.service _pid=1182




Save SYSTEMD Log


Persistent Storage System Log

By default, the Systemd log is saved in/run/log/journal, which means that it is purged when the system restarts. The log is

A new mechanism in Red Hat Enterprise Linux 7, and for most installations, a verbose log from the last boot is sufficient.


If there is a/var/log/journal directory, the log will be recorded in this directory instead. The advantage of this is that historical data can be used immediately upon launch. However, even a permanent log, not all data is permanently retained. The log has a built-in log rotation mechanism that starts every month. In addition, by default, the size of the log cannot exceed 10% of the file system, which can result in less than 15% of the file system's free space. These values can be adjusted in/etc/systemd/journald.conf, and the current limit of the log file size is recorded at the start of the Systemd-journald process and can be viewed using the following command, which displays the first two lines of the JOURNALCTL output:

Journalctl | Head-2


You can create the/var/log/journal directory as the root user, making the SYSTEMD log a permanent log.

Make sure that the/var/log/journal directory is owned by the root user and group systemd-journal and that the permissions are 2775

Need to reboot the system or send the special signal USR1 to the Systemd-journald process as root user

Killall-user1 systemd-journal


Because the SYSTEMD log is now permanently persisted between reboots, you can reduce the output by journal-b only the log messages from the system since the last boot.

Journalctl-b-1 #表示将输出限制为上一次启动




Keep the time accurate

For analyzing log files across multiple systems, it is important to synchronize the system time correctly, and Network Time Protocol (NTP) is a standard way for computers to provide and obtain the correct time information over the Internet. The computer can get the correct time information through the public NTP service on the Internet


Timedatectl #命令简要显示当前的事件相关的系统设置, such as the current time of the system, time zone and NTP synchronization settings. Timedatectl list-timezones #列出系统包含已知时区的数据库timedatectl set-timezone time zone #设置时间timedatectl set-time 9:00:00 #设置时间timedatec TL set-ntp true|false #打开或关闭NTP同步chronyc sources-v #验证NTP服务器
















This article is from the "The Anyisalin blog" blog, please be sure to keep this source http://anyisalin.blog.51cto.com/10917514/1736311

RHEL7.0 Log System

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.