rsyslog

# -----------------------------------------------
#  Basic syntax of rsyslog.conf
# -----------------------------------------------

# {facility}.{severity}  {action}
#   → Determines the log destination (action)
#     based on the combination of facility and severity.
#   Example: auth.info /var/log/auth.log
#            kern.crit /var/log/kernel-crit.log

# -----------------------------------------------
#  Special notation for facility and severity
# -----------------------------------------------

# * (wildcard): matches all facilities or all severities
#   Example: *.emerg :omusrmsg:*   # Notify all users of emerg from any facility

# none: excludes the specified facility
#   Example: *.info;mail.none;authpriv.none /var/log/messages
#       → Writes info-level and above to /var/log/messages,
#         but excludes mail and authpriv.

# -----------------------------------------------
#  Module configuration (for receiving logs via UDP/TCP)
# -----------------------------------------------

# Enable the module to receive logs over UDP (port 514)
# module(load="imudp")
# input(type="imudp" port="514")

# Enable the module to receive logs over TCP (port 514)
# module(load="imtcp")
# input(type="imtcp" port="514")

# -----------------------------------------------
#  Forwarding logs to a remote server
# -----------------------------------------------

# @{host}:{port}   → UDP forwarding (lightweight but less reliable)
# @@{host}:{port}  → TCP forwarding (more reliable; recommended for production)
#   Example: *.* @@log-server.example.com:514
#       → Forwards all logs to log-server via TCP.

# -----------------------------------------------
#  Custom format using templates
# -----------------------------------------------

# $template {template-name}, "{format-string}\n"
# $ActionFileDefaultTemplate {template-name}
#   Example: $template KiryuFmt,"%timegenerated% %hostname% %syslogtag%%msg%\n"
#            $ActionFileDefaultTemplate KiryuFmt

Facility / Severity	Description
kern	Messages generated by the kernel. Hardware errors and driver issues are recorded here.
user	General-purpose messages from user processes. This is the default facility for applications.
mail	Messages from mail systems such as Postfix and sendmail.
daemon	General-purpose messages from system daemons such as sshd and cron.
auth / authpriv	Messages related to authentication and authorization. Login attempts and sudo execution history are recorded here.
syslog	The facility used internally by rsyslog itself.
lpr	Messages from the print subsystem.
local0 to local7	Facilities reserved for custom applications. Used by Nginx, Apache, and other services with custom configurations.
emerg (level 0)	The system is unusable. This is the highest severity and requires immediate action.
alert (level 1)	Action must be taken immediately. Conditions such as database corruption or disk failure fall into this category.
crit (level 2)	Critical conditions. Hardware failures and kernel panics fall into this category.
err (level 3)	Error conditions. Service startup failures and configuration file read errors fall into this category.
warning (level 4)	Warning conditions. Situations that are not errors but require attention, such as high disk usage.
notice (level 5)	Normal but significant events. Service starts and stops are recorded here.
info (level 6)	Informational messages. General operational logs fall into this category.
debug (level 7)	Detailed messages for debugging. Typically disabled in production environments.
* (wildcard)	Matches all facilities or all severities.
none	Excludes logs from the specified facility. Used like mail.none.

/etc/rsyslog.d/kiryu-remote.conf

# -----------------------------------------------
#  Configuration to forward logs from Kiryu's server
#  to the central log server.
#  File: /etc/rsyslog.d/kiryu-remote.conf
# -----------------------------------------------

# -------------------------------------------------
#  Define the forwarding target (use an action queue for reliability)
# -------------------------------------------------

# Forward all facilities and severities to the log server via TCP.
# @@  → TCP forwarding (a single @ means UDP; TCP is recommended for production).
# With a queue configured, logs are buffered locally and retransmitted
# even if the log server is temporarily unavailable.
$ActionQueueType LinkedList                      # Queue type (dynamic linked list)
$ActionQueueFileName kiryu_fwd_queue             # Spool file prefix
$ActionQueueMaxDiskSpace 100m                    # Maximum disk usage
$ActionQueueSaveOnShutdown on                    # Save queue on shutdown
$ActionResumeRetryCount -1                       # Retry count (-1 = unlimited)

# Forward all warning-level and above logs to the central log server via TCP.
*.warning @@log.kiryu-corp.internal:514

# -------------------------------------------------
#  Forward auth facility at info level and above.
#  (Login attempts and sudo records are always sent.)
# -------------------------------------------------
auth.info @@log.kiryu-corp.internal:514

# -------------------------------------------------
#  Use the local7 facility for application logs.
#  Example: forwarding Nginx custom logs via local7.
# -------------------------------------------------
local7.* @@log.kiryu-corp.internal:514

# -------------------------------------------------
#  Write debug-level logs to local storage only.
#  (Not forwarded to the central server.)
# -------------------------------------------------
*.debug;*.!warning /var/log/kiryu-debug.log

Run the following command:

$ sudo rsyslogd -N1
rsyslogd: version 8.2102.0, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.

$ sudo systemctl restart rsyslog

$ sudo systemctl status rsyslog
● rsyslog.service - System Logging Service
     Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2026-03-25 09:12:34 JST; 3s ago
       Docs: man:rsyslogd(8)
             https://www.rsyslog.com/doc/
   Main PID: 4501 (rsyslogd)
      Tasks: 4 (limit: 4681)
     Memory: 3.2M
        CPU: 18ms
     CGroup: /system.slice/rsyslog.service
             └─4501 /usr/sbin/rsyslogd -n -iNONE
Mar 25 09:12:34 kiryu-srv01 systemd[1]: Started System Logging Service.

/etc/rsyslog.d/majima-filter.conf

# -----------------------------------------------
#  Log routing configuration for Majima's server.
#  File: /etc/rsyslog.d/majima-filter.conf
# -----------------------------------------------

# Write info-level and above to /var/log/messages.
# Exclude mail, authpriv, and cron since they are routed to separate files.
*.info;mail.none;authpriv.none;cron.none /var/log/messages

# Write authentication-related logs (authpriv) to a dedicated file.
# Login successes, failures, and sudo executions are all recorded here.
authpriv.*  /var/log/secure

# Write mail system logs to a dedicated file.
mail.*      -/var/log/maillog
#           ^ The leading - enables asynchronous writes (improves performance,
#             but the last few lines may be lost if the system crashes).

# Write cron daemon logs to a dedicated file.
cron.*      /var/log/cron

# Notify all logged-in users for emerg-level events.
*.emerg :omusrmsg:*

# Send err-level and above via email to nishikiyama (uses the ommail module).
# *.err :ommail:;mailBody
# Note: ommail module configuration is defined separately in /etc/rsyslog.d/ommail.conf.

Run the following command:

$ logger -p auth.warning "majima: sudo attempt from 192.168.10.50"

$ sudo tail -n 3 /var/log/secure
Mar 25 09:15:02 majima-srv02 root: majima: sudo attempt from 192.168.10.50
Mar 25 09:15:10 majima-srv02 sshd[4712]: Accepted publickey for nishikiyama from 192.168.10.30 port 51234 ssh2
Mar 25 09:15:10 majima-srv02 sshd[4712]: pam_unix(sshd:session): session opened for user nishikiyama by (uid=0)

Receiving configuration on the central log server (log aggregation server managed by Shinada)

# -----------------------------------------------
#  Receiving configuration for the central log server managed by Shinada.
#  File: /etc/rsyslog.conf (server side)
# -----------------------------------------------

# Load the module to receive logs over TCP.
module(load="imtcp")
input(type="imtcp" port="514")

# Save logs in a separate directory per source hostname.
# %HOSTNAME% → a template variable that expands to the sender's hostname.
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"

# Save incoming remote logs according to the template above.
# *.* → applies to all facilities and severities.
*.* ?RemoteLogs

# -------------------------------------------------
#  Create the destination directory in advance.
#   sudo mkdir -p /var/log/remote
#   sudo chown syslog:adm /var/log/remote
# -------------------------------------------------

Run the following command:

$ sudo ls /var/log/remote/
kiryu-srv01  majima-srv02  nishikiyama-srv03

$ sudo ls /var/log/remote/kiryu-srv01/
nginx.log  rsyslogd.log  sshd.log  sudo.log

$ sudo tail -n 2 /var/log/remote/kiryu-srv01/sshd.log
Mar 25 10:02:11 kiryu-srv01 sshd[5301]: Accepted publickey for date_shin from 192.168.10.40 port 49122 ssh2
Mar 25 10:02:11 kiryu-srv01 sshd[5301]: pam_unix(sshd:session): session opened for user date_shin by (uid=0)

'rsyslog' is a high-performance log collection daemon that extends the POSIX syslog standard, and is the default implementation in major distributions including RHEL, CentOS, Ubuntu, and Debian. The main configuration file is /etc/rsyslog.conf, with per-application files split under /etc/rsyslog.d/. Routing rules combine facilities (kern, user, mail, daemon, auth, local0–7, etc.) with severities (eight levels: emerg, alert, crit, err, warning, notice, info, debug) to achieve flexible log management suited to your needs. By combining TCP forwarding via @@host:port with action queues, you can safely aggregate logs from multiple servers onto a central server. For log rotation to prevent log files from growing too large, see the logrotate page. For real-time monitoring and filtering of logs written to files, see the /var/log page. In systemd environments, journalctl (systemd-journald) also runs alongside rsyslog, and managing logs using both together is the modern approach.