Ubuntu日志级别设置：你需要知道什么

Understanding Ubuntu Log Levels
Log levels define the severity of logged events, helping administrators filter and prioritize system/app messages. Ubuntu supports standard log levels (from most severe to least): emerg (system unusable), alert (immediate action required), crit (critical errors), err (errors), warning (potential issues), notice (normal but important), info (general information), and debug (detailed debugging). Choosing the right level balances log detail and storage usage—for example, debug is useful for troubleshooting but can clutter logs in production.

1. Configuring rsyslog (Default System Log Service)
rsyslog is Ubuntu’s default logging service. To adjust log levels:

• Edit the main configuration file: Open /etc/rsyslog.conf with a text editor (e.g., sudo nano /etc/rsyslog.conf).
• Modify log level rules: Locate lines like #kern.* /dev/console (comments are disabled by default). Change the level (e.g., kern.* /var/log/kern.log to log all kernel messages, or kern.err /var/log/kern.log to log only kernel errors).
• Restart rsyslog: Apply changes with sudo systemctl restart rsyslog.
  For more granular control, edit files in /etc/rsyslog.d/ (e.g., 50-default.conf)—this is recommended for customizing specific services (e.g., Apache, Nginx).

2. Configuring systemd-journald (Systemd Log Manager)
systemd-journald manages logs for systemd-based systems. To set log levels:

• Edit the journald configuration: Open /etc/systemd/journald.conf with sudo nano.
• Adjust log level parameters: Add or modify SystemMaxLevel (for persistent logs) and RuntimeMaxLevel (for volatile logs, stored in RAM). For example, set both to debug to capture detailed logs:

  SystemMaxLevel=debug  
  RuntimeMaxLevel=debug  
  

• Restart systemd-journald: Apply changes with sudo systemctl restart systemd-journald.
  Note: journald does not use traditional syslog levels directly—these parameters control the verbosity of collected logs.

3. Application-Specific Log Level Settings
Many applications (e.g., Apache, Nginx) have their own log level configurations. These settings override system-wide defaults:

• Apache: Edit the main configuration file (/etc/apache2/apache2.conf or a virtual host file in /etc/apache2/sites-available/). Modify the LogLevel directive (e.g., LogLevel debug to enable debug logs). Restart Apache with sudo systemctl restart apache2.
• Nginx: Edit the main configuration file (/etc/nginx/nginx.conf). Modify the error_log directive (e.g., error_log /var/log/nginx/error.log debug; to enable debug logs). Restart Nginx with sudo systemctl restart nginx.

4. Key Considerations for Log Level Management

• Storage Impact: Higher log levels (e.g., debug) generate large volumes of logs, which can fill disk space. Use tools like logrotate (configured in /etc/logrotate.conf) to automate log rotation, compression, and retention.
• Security: Avoid running services in debug mode in production—it may expose sensitive information (e.g., passwords, API keys) in logs.
• Service Restart Requirement: All log level changes require restarting the relevant service (rsyslog, systemd-journald, or the application) to take effect.

5. Verifying Log Levels
To confirm current log levels:

• For rsyslog: Check configuration files (e.g., /etc/rsyslog.conf) or view logs with journalctl -u rsyslog.
• For systemd-journald: View the current level with journalctl --disk-usage (indirectly) or check /etc/systemd/journald.conf.
• For applications: Review their configuration files (e.g., Apache’s LogLevel, Nginx’s error_log) or documentation.