tencent cloud

TencentOS Server

ドキュメントTencentOS ServerUser GuideSystem Diagnosis and ObservabilityLog Management

Log Management

ダウンロード
フォーカスモード
フォントサイズ
最終更新日: 2026-10-19 17:22:52
AI翻訳
This document describes the log management mechanism on TencentOS Server, including the configuration and use of systemd-journald and rsyslog, helping you efficiently manage system and application logs.

System Log File

System logs are mainly stored in the /var/log/ directory, including the following files:
/var/log/messages: contains most system messages and error information, including kernel messages, system startup information, and system service start and stop information. This file is usually the primary source for system administrators to troubleshoot and monitor the system.
/var/log/secure: contains authentication and security-related log information, including user login and logout information, sudo command usage information, and SSH connection information. This file is usually the primary source for system administrators to perform security audits and monitoring.
/var/log/audit/audit.log: records security audit information in the system. This file is usually generated and maintained by the auditd daemon process, and can help system administrators monitor security events and activities in the system.
/var/log/dnf.log: records detailed information about software package installation, update, and removal operations performed by using the DNF package manager in the system.
/var/log/boot.log: contains log information during system startup, including startup script output, service start and stop information, and more. This file is usually the primary source for system administrators to troubleshoot startup failures and monitor the system.
/var/log/lastlog: records the last login information of all users in the system.
/var/log/wtmp: records the login and logout information of all users in the system, including usernames, login times, logout times, login sources, and login IP addresses.

journald Service

journald is the log service of systemd, responsible for collecting and storing system logs. You can use the journalctl command to view system logs.

Viewing System Logs

View all logs in the system:
journalctl
This command displays all system logs, including kernel logs, service logs, and system startup logs.
To view logs for a specific service, replace <service-name> with the name of the service you want to view:
journalctl -u <service-name>
View logs within a specified time range. Replace the date and time with the time range you want to query:
journalctl --since "2024-01-01 00:00:00" --until "2024-01-02 00:00:00"
View kernel logs:
journalctl -k
In the current system, journald saves only the logs from the current boot by default, and the storage location is /run/log/journal/. To record all boot logs, you can manually create the /var/log/journal directory, after which the journald service will store boot logs there.
Create a directory for persistent log storage and restart the system:
mkdir -p /var/log/journal/
reboot
After the system restarts again, run the following command to view all boot records:
journalctl --list-boots
The output is as follows, where the IDX column indicates the boot sequence number. Negative numbers represent historical boot records, and 0 represents the current boot:
IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
-1 506feea161494cff925010ea7599ab5d Fri 2023-05-26 15:57:28 CST Fri 2023-05-26 16:00:10 CST
 0 59f4624ce2d94299be2afd80d3650c1a Fri 2023-05-26 16:00:18 CST Fri 2023-05-26 16:03:20 CST

Managing System Logs

You can use the journalctl command to manage system logs, including operations such as clearing and exporting logs.
Clear all logs in the system:
journalctl --vacuum-time=1s
This command clears all logs older than the specified time by setting an extremely short retention period (1 second).
Clear logs within a specified time range. Replace the date and time with the time range you want to clear:
journalctl --vacuum-time=1s --since "2024-01-01 00:00:00" --until "2024-01-02 00:00:00"
Output all logs to a specified file, here a file named log.txt:
journalctl > log.txt
Output logs for a specific service to a file. Replace <service-name> with the name of the service you want to export:
journalctl -u <service-name> > service-log.txt
This command writes the logs of a specified service to the service-log.txt file.

Installing and Configuring rsyslog

Introduction to rsyslog

rsyslog (Reliable System Logging) is a powerful system log processing engine that provides a complete set of tools for easily transmitting, post-processing, and storing system and application logs from various sources. rsyslog improves and extends the Syslog protocol with higher reliability, performance, and a powerful plugin architecture.

Installing rsyslog

On TencentOS Server, rsyslog is typically preinstalled. If you need to install it manually, you can use the dnf package manager. Run the following command to update the software package index and install rsyslog:
dnf install rsyslog  #Install the rsyslog component
dnf update rsyslog #Update the rsyslog component

Configuring rsyslog

The rsyslog configuration file is typically located at /etc/rsyslog.conf. In this file, you can define the sources, formats, and destinations of log messages, for example, configuring rsyslog to read logs from a specific Unix socket, read logs from journald, or send log messages to a remote server.
The rsyslog configuration file uses a special syntax that includes modules, templates, and rules. The following is a simple configuration example that you can modify by using vim /etc/rsyslog.conf:
# Load modules
module(load="imuxsock") # Provides Unix socket support
module(load="imklog")  # Provides kernel log support
# Provide UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")
# Provide TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")
# Specify the location of the log file
auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
After modifying the configuration file, restart the rsyslog service for the changes to take effect.
systemctl restart rsyslog
Warning:
Before modifying the configuration file, back up the original configuration file (for example, cp /etc/rsyslog.conf /etc/rsyslog.conf.bak) so that you can quickly restore it if a configuration exception occurs. Restarting the rsyslog service briefly interrupts log collection, so confirm that it does not affect your business before proceeding.

Basic Usage of rsyslog

After rsyslog is installed and configured, it will automatically start running and processing log messages. You can use the systemctl command to manage the rsyslog service, including starting, stopping, and restarting it.
systemctl start rsyslog 
systemctl stop rsyslog
systemctl restart rsyslog
To configure rsyslog to start by default with the system, run the following command:
systemctl enable rsyslog
You can also run the following command to check the rsyslog service status and ensure that the service is running properly:
systemctl status rsyslog

Configuring Log Forwarding Rules

The power of rsyslog lies in its convenient log file forwarding feature. You can use the rsyslog configuration file to easily send local log files to a remote server or receive log information from a remote server.

Forwarding Local Log Messages

By configuring the vim /etc/rsyslog.conf file, you can forward all local log messages to other servers through rsyslog. Add the following content to the configuration file:
*.* @@192.168.1.1:514
In this example, *.* represents log messages from all facilities and all priorities, @@ indicates the use of a TCP connection, and 192.168.1.11:514 is the IP address and port of the remote server. The port must match the listening port configured in the remote server's rsyslog configuration. After modifying the configuration file, restart the rsyslog service for the changes to take effect.
systemctl restart rsyslog

Receiving Remote Log Messages

By configuring the vim /etc/rsyslog.conf file, you can load specific modules and open specific ports to receive log messages from other servers. Add the following content to the configuration file:
# Provide UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")
# Provide TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")
In this example, rsyslog enables the TCP and UDP reception modules to receive syslog messages from other servers. After modifying the configuration file, restart the rsyslog service for the changes to take effect.
systemctl restart rsyslog

Using rsyslog with journal

rsyslog and journal are both tools for processing and managing system logs, but they differ in design and implementation. rsyslog uses the traditional text file format, which can be read and processed directly, while journal uses a binary format that requires specific tools for processing. In addition, rsyslog focuses more on network log collection, while journal focuses more on the structuring and indexing of local logs.

Using journal with rsyslog

By loading the imjournal module, rsyslog can obtain log data directly from systemd journal, replacing the traditional Unix domain socket input method (such as /dev/log). This mechanism enables rsyslog to directly access the native structured metadata of journal (such as _PID, _COMM, SYSTEMD_UNIT, and so on), thereby achieving efficient collection and structured processing of system logs.
In the rsyslog configuration file vim /etc/rsyslog.conf, add the following configuration to load the imjournal module (which is usually configured by default in TencentOS Server):
module(load="imjournal" StateFile="imjournal.state")

Using rsyslog with journal

By configuring the systemd-journald ForwardToSyslog=yes option, you can forward Journal logs to rsyslog in real time. After this feature is enabled, journald pushes log messages to rsyslog through a Unix domain socket (usually /run/systemd/journal/syslog), allowing rsyslog to receive and process system logs in the traditional syslog protocol format, thereby achieving compatibility with existing syslog infrastructure and centralized log management.
In the journal configuration file vim /etc/systemd/journald.conf, add or modify the following configuration to enable the ForwardToSyslog option (the default value is no):
ForwardToSyslog=yes
Then restart the systemd-journald service for the changes to take effect.
systemctl restart systemd-journald
Note:
Generally, if you need to forward journal log messages to rsyslog, it is recommended to enable both the imjournal module in rsyslog and the ForwardToSyslog option in journald to ensure that all log messages can be correctly captured by rsyslog.

Configuration Example: Forwarding journal Logs to a Remote Server

Combining rsyslog and journal allows you to fully leverage the advantages of both. With its binary storage and structured indexing capabilities, Journald significantly improves the efficiency of local log search and analysis. rsyslog, on the other hand, relies on its network transmission capabilities to reliably forward logs to remote servers, meeting centralized log management requirements. In addition, rsyslog's full compatibility with the traditional Syslog protocol ensures support for legacy applications and older devices.
For example, configure the vim /etc/rsyslog.conf file to forward all local journal log messages to other servers through rsyslog. Add the following content to the configuration file (using 192.168.1.1 as an example):
*.* @@192.168.1.1:514

Common Issues and Solutions

rsyslog FAQs
The rsyslog service fails to start.
If the rsyslog service fails to start, check the following issues:
Configuration syntax validation: Run rsyslogd -N1 to pre-validate the configuration file. If no error is output after execution (only a validation completion message is returned), the configuration file syntax is valid. If a syntax error exists, the command returns the exact error line number and exception type, allowing you to directly locate and fix the issue.
File permission check: If the configuration validation passes but the service still fails to start, check the read and write permissions of the rsyslog process on the log output directory, log files, and state cache directory. Ensure that the service account running rsyslog (usually syslog or root) has valid access permissions to the target paths to avoid process initialization failures caused by insufficient permissions.

rsyslog does not receive remote logs.
If rsyslog cannot receive remote logs, check the following issues:
Network connectivity check: Check the system firewall rules to confirm that the rsyslog listening port (514 by default, UDP/TCP) is not blocked by firewall components such as iptables or firewalld, ensuring that remote log traffic can reach the server properly.
Service configuration check: Open the rsyslog configuration file and confirm that the imudp or imtcp input module is explicitly loaded and that the corresponding UDP/TCP listening service is enabled. This prevents external logs from failing to be received due to the remote listening capability not being enabled.
journal FAQs
journal logs are lost.
If systemd-journald logs are found to be lost, the issue may be caused by the following reasons. Optimize the configuration accordingly:
Storage space limit: When a surge in log volume reaches the default storage limit, old logs are automatically rotated and deleted. You can edit /etc/systemd/journald.conf to adjust the SystemMaxUse parameter (for example, set it to 500M or 1G) to explicitly limit the maximum disk space that Journal can occupy, balancing storage requirements against disk pressure.
Missing persistent storage: By default, Journald in some distributions stores logs only in a volatile in-memory file system (/run/log/journal). An unexpected system crash or restart causes logs to be completely lost. Set the Storage option to persistent in the configuration file to force Journald to create persistent storage in the /var/log/journal directory, ensuring that logs remain traceable after a power failure or crash.
Note: After modifying /etc/systemd/journald.conf, run systemctl restart systemd-journald to restart the service and apply the new policy.

The journal log is too large.
If systemd-journald logs occupy excessive space, adopt the following policies:
1. Manual space reclamation: Use the journalctl tool to immediately release disk resources. You can clean up by size threshold using the --vacuum-size parameter (for example, keep only the most recent 500MB), or clean up by time window using the --vacuum-time parameter (for example, keep only the last two weeks of data) to quickly relieve storage pressure.
2. Configure automatic rotation: Edit the /etc/systemd/journald.conf configuration file and configure SystemMaxUse to limit the maximum disk usage of the journal, and configure SystemKeepFree to ensure that the file system always retains the specified minimum free space.
Note: After modifying /etc/systemd/journald.conf, run systemctl restart systemd-journald to restart the service and apply the new policy.

Log Dump

As system uptime increases, log files continue to grow and may occupy a large amount of disk space or even fill the disk. By configuring log rotation (logrotate), you can automatically rotate, compress, and clean up log files to prevent them from growing indefinitely, ensuring that disk space can be reclaimed and logs remain traceable.

Installing logrotate

logrotate is a commonly used log rotation tool in Linux systems. It can automatically rotate, compress, and delete log files. Run the following command to install logrotate:
dnf install logrotate

Configuring logrotate

The logrotate configuration file is typically located at /etc/logrotate.conf and in the /etc/logrotate.d/ directory. You can edit these files to configure log rotation rules.
The current configuration of /etc/logrotate.conf on the system is as follows:
weekly
rotate 4
create
dateext
include /etc/logrotate.d
The parameters in this configuration file are described as follows:
Parameter
Description
weekly
The log rotation interval is weekly.
rotate 4
A maximum of 4 backup files are retained.
create
A new file is created for each rotation.
dateext
Use the date as the prefix of rotation files.
include /etc/logrotate.d
Include other configuration files in the /etc/logrotate.d directory.
In addition, you can set the log rotation period and retention policy by using the following parameters:
daily: Rotate log files every day.
weekly: Rotate log files every week.
monthly: Rotate log files every month.
rotate N: Keep N log copies, where N is an integer.
The include /etc/logrotate.d directive merges all configuration files in that directory with the main configuration file /etc/logrotate.conf for execution. This means that the global rules defined in the main configuration file apply to all log files, while the individual configuration files in the /etc/logrotate.d/ directory can define specific rotation rules for particular services or applications.
When software package components are installed, some packages that have logs also install their log rotation configuration files by default. Run the following command to view the configuration files in the /etc/logrotate.d directory:
ls /etc/logrotate.d
The output is as follows, showing a list of installed log rotation configuration files on the system:
btmp  chrony  dnf  httpd  iptraf-ng  iscsiuiolog  libvirtd  libvirtd.qemu  mariadb  numad  openstack-trove  psacct  rabbitmq-server  wtmp
The following example uses a configuration file to explain the basic rules in a logrotate configuration file:
/var/log/myapp.log {
  rotate 7
  daily
  missingok
  notifempty
  compress
  delaycompress
  postrotate
      /usr/bin/systemctl restart myapp.service > /dev/null 2>&1 || true
  endscript
}
The preceding configuration file defines rules for rotating the log file /var/log/myapp.log. The details are as follows:
rotate 7: Keep 7 old log files, and automatically delete any beyond that.
daily: Rotate logs once a day.
missingok: Ignore the error if the log file does not exist.
notifempty: Do not rotate the log file if it is empty.
compress: Compress old log files using gzip.
delaycompress: Compress old log files during the next rotation.
postrotate: Commands to be executed after rotation is complete, such as restarting a service.
endscript: The end marker of the postrotate command.

Manually Running logrotate

You can use the following command to manually run logrotate and rotate all log files according to the rules in the configuration file:
logrotate -f /etc/logrotate.conf

Automating logrotate

The logrotate service is automatically started at system startup and periodically rotates log files according to the rules in the configuration file.
Run the following command to check the status of the logrotate service:
systemctl status logrotate.service
If the logrotate service is not started, run the following command to start it:
systemctl start logrotate.service
After modifying the configuration file, restart the logrotate service for the new configuration to take effect. Run the following command to restart the service:
systemctl restart logrotate.service

Rotating rsyslog Logs with logrotate

Combining rsyslog and logrotate can lead to more efficient log management. rsyslog offers rich features and high performance in receiving, processing, and storing logs, while logrotate provides flexible log rotation policies to avoid resource waste. By adjusting the configuration, you can implement automatic management of the entire log lifecycle from generation, collection, and processing to storage and rotation, meeting requirements such as log retention, auditing, and troubleshooting.

Configuring logrotate

To configure log rotation, you need to set up logrotate. In the /etc/logrotate.d/ directory, you can create a logrotate configuration file for a specific log.
For example, to create a configuration file named rsyslog for rsyslog, run the following command:
touch /etc/logrotate.d/rsyslog
Open the file you just created with a text editor and add the following configuration:
/var/log/cron
/var/log/maillog
/var/log/messages
/var/log/secure
/var/log/spooler
{
    daily
    rotate 7
    create
}
This configuration indicates that these log files in the /var/log directory are rotated daily, and log copies from the last 7 days are retained.

Setting Rotation Intervals and Retention Policies

The rotation period and retention policy parameters for log rotation are described in the logrotate configuration section. You can set the appropriate rotation period and retention policy in the configuration file at /etc/logrotate.conf or in the /etc/logrotate.d/ directory based on your actual requirements.
At this point, you have completed the basic configuration for logrotate to rotate rsyslog system logs.

前の記事へ: TCP Transfer Rate and Performance Analysis次の記事へ: OOM Killer Analysis and Handling

ヘルプとサポート

この記事はお役に立ちましたか？

フィードバック

キーワードで検索
    Enter keywords to search documentation