答案：rsyslog通过配置客户端和服务器端实现日志集中化，服务器启用UDP/TCP接收模块并定义存储模板，客户端配置转发规则、过滤日志、使用TLS加密及队列机制保障安全可靠传输。
在Linux环境下，rsyslog是实现日志集中化管理的关键工具。简单来说，它能把散落在不同服务器上的日志文件，像河流汇入大海一样，统一收集到一个中央日志服务器。这不仅大大简化了日常运维的复杂性，让故障排查和安全审计变得高效许多，还能为数据分析提供一个统一的入口。它的强大之处在于高度可配置性和稳定性，无论是面对瞬时高并发的日志流，还是需要长期存储和分析，rsyslog都能提供一个坚实可靠的基础。
要实现Linux下的rsyslog集中化日志收集，核心在于配置两部分：日志发送端（客户端）和日志接收端（服务器端）。这就像是建立一个邮局系统，客户端负责打包信件并寄出，服务器端负责接收、分类并妥善保管。
服务器端配置： 首先，确保你的中央日志服务器上安装了rsyslog。大部分Linux发行版默认都已安装。 打开rsyslog主配置文件，通常位于
/etc/rsyslog.conf
/etc/rsyslog.d/*.conf
启用UDP和TCP接收模块： UDP协议发送日志速度快，但不可靠（可能丢包）；TCP协议则提供可靠传输，但略有性能开销。通常我们会同时启用。
# 启用UDP接收 module(load="imudp") input(type="imudp" port="514") # 启用TCP接收 module(load="imtcp") input(type="imtcp" port="514")
这里监听的是标准的514端口。如果需要，可以修改端口号，但客户端也要相应调整。
定义日志存储规则： 这是最关键的部分，我们需要告诉rsyslog如何存储接收到的日志。一个好的实践是根据发送日志的主机名或IP地址，将日志分别存放到不同的目录或文件中，这样便于管理和查找。
# 定义一个模板，用于动态生成文件名，将日志按主机名和程序名存储
# 例如：/var/log/remote/webserver01/auth.log
template(name="HostLog" type="string"
string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")
# 定义一个模板，用于更精细的按日期存储，例如：/var/log/remote/webserver01/2023-10-27/auth.log
# 这种方式在日志量大时非常有用，但配置会稍微复杂一点
# template(name="DailyHostLog" type="string"
# string="/var/log/remote/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%/%PROGRAMNAME%.log")
# 接收所有远程日志并使用HostLog模板存储
# :fromhost-ip, !isequal, "127.0.0.1" 是为了避免将本地日志也存到远程目录
# 如果你的服务器也作为客户端发送日志给自己，这行很重要
if $fromhost-ip != "127.0.0.1" then {
action(type="omfile" dynaFile="HostLog")
# 如果需要同时将所有远程日志也写入一个总的日志文件，可以再加一行
# *.* /var/log/remote/all-remote.log
}保存配置后，重启rsyslog服务：
sudo systemctl restart rsyslog
客户端配置： 在每台需要发送日志的服务器上，同样确保安装了rsyslog。 打开客户端的rsyslog配置文件。
配置日志转发规则： 在文件的末尾添加一行，指示rsyslog将所有日志转发到中央日志服务器。
# 将所有日志通过UDP发送到日志服务器，@ 表示UDP *.* @your_log_server_ip_or_hostname:514 # 如果需要更可靠的传输，使用TCP，@@ 表示TCP # *.* @@your_log_server_ip_or_hostname:514
将
your_log_server_ip_or_hostname
# 只转发警告及以上级别的日志到服务器 *.warn;*.err;*.crit;*.alert;*.emerg @@your_log_server_ip_or_hostname:514
或者只转发特定程序的日志：
# 转发nginx的日志 if $programname == 'nginx' then @@your_log_server_ip_or_hostname:514
保存配置后，重启rsyslog服务：
sudo systemctl restart rsyslog
至此，一个基本的集中化日志收集系统就搭建起来了。日志服务器会在
/var/log/remote/
客户端的配置远不止简单地转发所有日志那么粗暴。我们追求的是既不丢日志，又能保证传输安全，同时还不至于因为日志转发拖慢系统。这中间的平衡点，得靠一些细致的配置来拿捏。
1. 选择合适的传输协议：UDP还是TCP？ 这是个老生常谈的问题，但它确实是效率和可靠性的第一道坎。
@
@@
2. 引入TLS加密，保障日志传输安全： 日志内容往往包含敏感信息，明文传输是安全大忌。rsyslog通过GnuTLS模块（
gtls
服务器端（接收方）配置示例：
# 加载gtls模块
module(load="gtls")
# 定义CA证书、服务器证书和私钥路径
global(DefaultNetstreamDriver="gtls"
DefaultNetstreamDriverCAFile="/etc/rsyslog.d/certs/ca.pem"
DefaultNetstreamDriverCertFile="/etc/rsyslog.d/certs/server-cert.pem"
DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/certs/server-key.pem")
# 启用TCP over TLS接收，通常使用6514端口
input(type="imtcp" port="6514"
StreamDriver="gtls"
StreamDriverMode="1" # 1 for server
StreamDriverAuthMode="x509/certvalid") # 客户端必须提供有效证书客户端（发送方）配置示例：
# 加载gtls模块
module(load="gtls")
# 定义CA证书、客户端证书和私钥路径
global(DefaultNetstreamDriver="gtls"
DefaultNetstreamDriverCAFile="/etc/rsyslog.d/certs/ca.pem"
DefaultNetstreamDriverCertFile="/etc/rsyslog.d/certs/client-cert.pem"
DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/certs/client-key.pem")
# 使用TLS加密TCP发送
action(type="omfwd" Target="your_log_server_ip_or_hostname" Port="6514" Protocol="tcp"
StreamDriver="gtls"
StreamDriverMode="0" # 0 for client
StreamDriverAuthMode="x509/certvalid" # 验证服务器证书
ResendLastMsgOnReconnect="on" # 断线重连时重发最后一条消息
QueueFileName="fwdRule1" # 队列文件名，用于持久化队列
QueueSize="100000" # 队列大小，防止日志量过大时内存溢出
QueueDiscardMessages="off" # 队列满时不丢弃消息，而是阻塞
QueueType="LinkedList" # 队列类型，推荐LinkedList或Disk
ActionQueueMaxDiskSpace="1G" # 磁盘队列最大空间
ActionQueueSaveOnShutdown="on") # 关闭时保存队列内容证书的生成和管理是一个独立的话题，通常会用到OpenSSL。这部分配置需要仔细，任何证书路径或权限问题都可能导致连接失败。
3. 客户端日志过滤，减少不必要的传输： 并非所有日志都需要转发到中央服务器。例如，一些调试信息、低级别的INFO日志，可能只在本地排查问题时有用。在客户端进行过滤，可以显著减少网络带宽占用和服务器端的处理压力。
# 过滤掉debug和info级别的日志，不发送 :msg, contains, "DEBUG" stop :msg, contains, "INFO" stop # 仅发送critical和error级别的日志到服务器 *.crit;*.err @@your_log_server_ip_or_hostname:514 # 或者，如果特定程序产生的日志量巨大，但只有一部分需要转发 if $programname == 'my_chat_app' and $syslogseverity <= '4' then @@your_log_server_ip_or_hostname:5114 # 上面这行表示：如果程序是'my_chat_app'并且日志级别是error(4)或更严重，则发送到5114端口
通过
stop
programname
msg
facility
severity
4. 缓冲区与队列管理，应对网络波动： 网络中断或服务器暂时不可用是常有的事。rsyslog客户端的队列机制是保证日志不丢失的关键。 在
action
QueueType
QueueSize
ActionQueueMaxDiskSpace
日志服务器端是整个集中化系统的“大脑”，它不仅要接收来自四面八方的日志流，还要智能地进行分类、存储，甚至初步的过滤和分析。这里的配置直接决定了日志数据的可用性和管理效率。
1. 接收多协议日志： 前面已经提过，通过
imudp
imtcp
gtls
imtcp
StreamDriver
2. 灵活的日志存储路径：动态文件名模板（Templates）： 这是服务器端最强大的功能之一。我们不可能为每台客户端机器手动创建日志文件。rsyslog的模板功能允许你根据日志的元数据（如主机名、程序名、时间戳等）动态生成文件名和路径。
# 定义一个按主机名和日期分目录的模板
template(name="RemoteHostDailyLog" type="string"
string="/var/log/remote/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%/%PROGRAMNAME%.log")
# 定义一个按主机名和程序名分文件的模板（简化版）
template(name="RemoteHostProgramLog" type="string"
string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")
# 接收所有远程日志，并应用模板存储
# 这里的条件 `$fromhost-ip != "127.0.0.1"` 确保只处理远程日志
if $fromhost-ip != "127.0.0.1" then {
action(type="omfile" dynaFile="RemoteHostDailyLog"
FileCreateMode="0640" DirCreateMode="0755") # 确保目录和文件权限正确
}dynaFile
FileCreateMode
DirCreateMode
3. 精细化日志过滤和路由：规则集（Rulesets）： 当日志量巨大，或者需要对不同类型的日志进行不同处理时，单一的全局规则可能就不够用了。rsyslog的规则集允许你创建独立的日志处理流程。
# 定义一个专门处理Nginx日志的规则集
ruleset(name="nginx_ruleset") {
# Nginx访问日志，单独存到access.log
if $programname == 'nginx' and $syslogtag contains 'access' then {
action(type="omfile" file="/var/log/nginx_remote/access.log")
stop # 处理完后停止，不进入其他规则
}
# Nginx错误日志，单独存到error.log
if $programname == 'nginx' and $syslogtag contains 'error' then {
action(type="omfile" file="/var/log/nginx_remote/error.log")
stop
}
# 其他Nginx日志，存到通用Nginx日志
action(type="omfile" file="/var/log/nginx_remote/general.log")
}
# 定义一个专门处理数据库日志的规则集
ruleset(name="mysql_ruleset") {
# 数据库错误日志，除了存文件，还可能要发邮件通知
if $programname == 'mysqld' and $syslogseverity <= '3' then { # error或更严重
action(type="omfile" file="/var/log/mysql_remote/error.log")
# action(type="ommail" target="admin@example.com" subject="MySQL Critical Alert")
}
# 其他数据库日志
action(type="omfile" file="/var/log/mysql_remote/general.log")
}
# 将来自特定IP的日志路由到不同的规则集
# 例如，来自192.168.1.10的日志，如果是nginx的，就走nginx_ruleset
if $fromhost-ip == "192.168.1.10" then {
call nginx_ruleset
} else if $fromhost-ip == "192.168.1.11" then {
call mysql_ruleset
} else {
# 其他所有远程日志走默认的远程日志存储
action(type="omfile" dynaFile="RemoteHostDailyLog")
}call
4. 数据库集成（可选）： 对于需要进行复杂查询、报表生成或与SIEM（安全信息和事件管理）系统集成的场景，将日志直接存储到数据库（如MySQL、PostgreSQL）会更方便。rsyslog提供了
ommysql
ompgsql
# 加载数据库输出模块
module(load="ommysql")
# 将特定日志写入MySQL数据库
if $programname == 'web_app' and $syslogseverity <= '4' then {
action(type="ommysql" server="db_server_ip" db="syslog_db"
uid="syslog_user" pwd="syslog_password"
template="MySQLTemplate") # 需要定义一个SQL插入模板
}数据库集成虽然功能强大，但会引入数据库本身的性能瓶颈和管理复杂性，通常在日志量达到一定规模或有特定分析需求时才考虑。
日志收集系统一旦搭建起来，并不意味着万事大吉。它是一个动态运行的服务，可能会遇到各种问题，比如网络中断、磁盘空间不足、配置错误等。有效的监控和故障排查手段，是保证日志系统稳定运行的“定心丸”。
1. 检查rsyslog服务状态： 最基本的检查是查看rsyslog服务是否正在运行。
sudo systemctl status rsyslog
这会显示服务的当前状态（active/inactive）、最近的日志输出以及是否有错误。如果服务没有运行，或者显示“failed”，那么需要进一步查看日志。
2. 查看rsyslog自身的日志： rsyslog服务自身的运行信息和错误通常会记录到系统的
journalctl
/var/log/syslog
/var/log/messages
sudo journalctl -u rsyslog -f # 实时查看rsyslog服务的日志
仔细阅读这些日志，很多时候问题的原因（比如配置语法错误、文件权限问题、网络连接失败）会直接在这里显示出来。
3. 检查网络连通性与端口：
sudo firewall-cmd --list-all
sudo ufw status
sudo iptables -L -n
nc -vz your_log_server_ip 514
telnet your_log_server_ip 514
ping your_log_server_ip
4. 检查日志文件权限和磁盘空间： 在日志服务器端，如果日志文件或目录的权限设置不正确，rsyslog可能无法写入日志。
ls -ld /var/log/remote/ ls -l /var/log/remote/your_hostname/
确保rsyslog运行的用户（通常是
syslog
root
df -h /var/log/remote/
如果磁盘满了，rsyslog会停止写入日志，甚至可能导致服务不稳定。定期清理旧日志或增加存储空间是必须的。
5. 客户端日志队列状态： 如果客户端配置了持久化队列，当网络中断时，日志会堆积在本地。你可以检查队列文件是否存在以及大小。 队列文件通常在
/var/spool/rsyslog/
QueueFileName
以上就是如何在Linux下使用rsyslog管理日志？集中化日志收集的实用配置教程的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告
收藏
收藏
收藏
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
619
