作为运维或DBA，谁没被数据库日志坑过？本地日志散在各个服务器，排查问题时登录一台又一台机器，翻来翻去找不到关键信息；偶尔磁盘满了，日志被自动清理，出了故障连追溯的机会都没有；更别提合规审计要求，本地日志随便删、随便改，根本达不到要求。

今天就给大家分享一个实测可用、零成本落地的方案——用Linux自带的rsyslog服务，把所有数据库日志集中推送到syslog服务器，从此日志管理躺平，排查问题效率翻倍！全程无复杂操作，无额外组件依赖，小白也能跟着一步到位，亲测生产环境稳定运行，放心抄作业～

先跟大家说下本次实战的环境，很经典的客户端+服务端架构，大家可以直接对应自己的环境替换IP：

• 客户端：数据库服务器（同时也是rsyslog客户端），IP：192.168.1.201

• 服务端：专用syslog日志服务器，IP：192.168.1.202

全程操作都是Linux基础命令，不用写复杂脚本，跟着敲就行！

一、先唠唠：为啥非要把数据库日志推给syslog？

可能有人会问，数据库日志存在本地不也能用吗？那是你没遇到过这些糟心事：

1. 单机存储太坑：磁盘满、误删、硬件坏了，日志直接永久丢失，出问题连“黑匣子”都没有；

2. 多节点排查崩溃：如果有好几台数据库服务器，排查问题要逐个登录，翻不同目录的日志，半天找不到重点；

3. 合规审计过不了：很多企业要求日志集中留存、不可篡改，本地日志随便清理，审计时直接翻车；

4. 占用本地资源：数据库本身就耗资源，日志存本地还占磁盘，万一磁盘满了，直接影响数据库运行。

而syslog（咱们实际用的是增强版rsyslog）就不一样了，它是Linux系统自带的日志服务，轻量又稳定，几乎所有设备（服务器、路由器、数据库）都支持往它那发日志。把数据库日志推过去，相当于给所有日志建了个“统一档案室”，异地存储防丢失、统一检索省时间，还能满足合规要求，一举多得！

二、小科普：rsyslog核心知识点，不用深钻，懂这些就够

动手前先简单搞懂几个关键点，避免踩坑，不用死记硬背，知道怎么用就行：

1. rsyslog的双重身 份：它既能当“接收器”（服务端），监听端口接收其他设备的日志；也能当“发送器”（客户端），把本机的日志转发给远程服务器。咱们这次就是用它的双重身份，实现日志上送。

2. 日志的“分类标签”：rsyslog用Facility（设施）给日志分类，比如系统日志、邮件日志，其中local0~local7是用户自定义的，专门用来存数据库、应用这类业务日志，咱们这次就用local0，避免和系统日志混在一起。

3. 核心配置语法（记不住也没关系，后面直接抄）：

• 加载UDP/TCP模块：开启端口监听，UDP轻量高效，TCP更可靠，咱们内网用UDP就够；

• 日志转发：local0.* @IP 就是用UDP把local0的所有日志，推给指定IP的syslog服务器；

• 日志模板：服务端用模板，能按客户端主机名、进程名自动分类存日志，不用手动整理，比如客户端node201的数据库日志，会自动存在/var/log/node201/kingbase.log里，找起来超方便。

三、第一步：部署syslog服务端（192.168.1.202），做个“日志接收器”

服务端的作用就是接收所有客户端发来的日志，然后分类存好，配置就4步，全程复制粘贴命令就行：

1. 修改主配置文件，开启端口监听

编辑/etc/rsyslog.conf文件，把UDP和TCP的监听模块打开，再配置日志存储模板：

命令：vi /etc/rsyslog.conf

找到对应内容，取消注释（或者直接添加）下面这些配置：

# 加载UDP接收模块，默认514端口
$ModLoad imudp
$UDPServerRun 514
# 加载TCP接收模块，备用
$ModLoad imtcp
$InputTCPServerRun 514

# 自定义日志存储模板，按主机名+进程名分类
#### 业务日志集中存储 ####
$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log"
*.*  ?RemoteLogs
& ~   # 匹配后不再写入其他文件，避免日志重复

解释一下：& ~ 这个配置很重要，意思是日志按模板存好后，就不再往系统默认日志文件里写了，避免重复存储占磁盘。

2. 修改启动参数，允许接收远程日志

编辑/etc/sysconfig/rsyslog，添加-r参数，不然服务端收不到远程日志：

命令：vi /etc/sysconfig/rsyslog

找到SYSLOGD_OPTIONS这一行，修改为：

SYSLOGD_OPTIONS="-r -c 5"

简单说下：-r是允许接收远程日志，-c 5是用兼容模式，保证服务稳定运行，不用纠结太多，照改就行。

3. 重启服务，查看状态

配置改完，重启rsyslog服务才能生效，命令直接抄：

systemctl restart rsyslog
systemctl enable rsyslog  # 设为开机自启，避免重启服务器后失效
systemctl status rsyslog

如果看到“active (running)”，就说明服务启动成功了，没报错就是好现象～

4. 检查端口，确认监听成功

最后确认一下514端口是否被rsyslog监听，命令：

netstat -antulp | grep 514

正常情况下，会显示tcp和udp的514端口都在监听，这样服务端就配置完成了，就等客户端发日志过来啦！

四、第二步：配置客户端（数据库服务器192.168.1.201），做个“日志发送器”

客户端不用开启监听，只要告诉rsyslog：把数据库的日志，推给咱们刚才部署的syslog服务端，配置更简单，就2步：

1. 配置日志转发规则

同样编辑/etc/rsyslog.conf，添加转发规则，命令：vi /etc/rsyslog.conf

直接在文件末尾添加下面这两行，不用改别的：

#### 数据库日志配置 ####
local0.* /home/kingbase/db/r6_c8/data/sys_log  # 本地留存一份日志，可选，方便临时排查
local0.* @192.168.1.202                       # 核心：把local0的日志推给syslog服务端

说明一下：第一行是本地备份日志，怕远程日志出问题时，本地有备份，可加可不加；第二行是关键，@后面跟的是syslog服务端的IP，别写错了！

2. 重启客户端rsyslog服务

配置改完，重启服务生效，命令和服务端一样：

systemctl restart rsyslog
systemctl status rsyslog

只要没报错，客户端就配置好了，接下来就是让数据库把日志发给rsyslog，这步是核心，别走神～

第三步：让数据库“听话”，把日志输出到syslog

前面配置好了rsyslog的客户端和服务端，但数据库还不知道要把日志发给谁，所以这一步要告诉数据库：别再只把日志存本地了，发给syslog！

1. 修改数据库配置文件kingbase.conf

先切换到数据库用户，找到kingbase.conf配置文件，命令：

su - kingbase
vi /home/kingbase/db/r6_c8/data/kingbase.conf  # 路径按自己的实际路径改

找到日志相关的参数，修改成下面这样，找不到就直接搜索（vi里按/搜索）：

# 日志输出目标：指定为syslog
log_destination = 'syslog'

# syslog设施：必须和rsyslog配置的local0一致，不然日志发不过去
syslog_facility = 'LOCAL0'

# 日志标识：服务端会用这个名字建日志文件，好识别
syslog_ident = 'kingbase'

# 下面两个可选，按需开启
# syslog_sequence_numbers = on   # 开启序列号，防止日志丢失
# syslog_split_messages = on      # 长日志自动拆分，避免显示不全

重点提醒：syslog_facility必须是LOCAL0（大小写没关系），和前面rsyslog配置的local0.*对应上，不然日志会发丢，这是最容易踩的坑！

2. 重启数据库，让配置生效

配置改完，重启数据库才能生效，命令：

sys_ctl restart  # 按自己数据库的重启命令来，比如用服务命令也可以

重启后别着急，先验证一下本地日志，看看是不是已经转向syslog了。

3. 验证本地日志，确认配置生效

进入数据库的本地日志目录，查看最新的日志文件，命令：

cd /home/kingbase/db/r6_c8/data/sys_log
ls -lh  # 查看日志文件
cat 最新的日志文件名

如果看到下面这句话，就说明数据库配置成功了，日志已经开始往syslog发了：

2023-10-19 15:34:37.932 CST [4597] LOG:  ending log output to stderr
HINT:  Future log output will go to log destination "syslog".

翻译一下就是：以后日志不往stderr输出了，都发给syslog啦！

第四步：验收成果！在syslog服务端查看远程日志

所有配置都完成了，最激动人心的时刻到了，去syslog服务端看看，能不能收到数据库的日志！

1. 找到日志存储路径

咱们在服务端配置了模板，日志会按“客户端主机名/进程名.log”的格式存储，路径是：

/var/log/客户端主机名/进程名.log

2. 查看日志内容，确认成功

用cat命令查看日志文件，如果能看到数据库的启动、关闭、连接等日志，比如下面这样，就说明日志上送成功了！

Oct 19 15:34:37 loe kingbase[4597]: LOG:  database system is ready to accept connections

到这里，整个数据库日志集中上送syslog的配置就全部完成了，以后不管有多少台数据库服务器，日志都集中存在syslog服务端，排查问题直接去一个目录找，再也不用挨个登录机器了，是不是超省心！

总结

其实整个配置流程很简单，核心就是“服务端监听接收，客户端转发，数据库输出”，用Linux原生的rsyslog，零成本实现数据库日志集中管理，不用装任何第三方组件，稳定又省心。日志管理是运维的基础，把日志管好，不管是故障排查、安全审计，还是合规检查，都能省不少事。如果你也在为分散的数据库日志头疼，赶紧照着本文的步骤操作，几分钟就能搭建好一套稳定的日志集中化平台，亲测可用，放心冲！

（注：文档部分内容可能由 AI 生成）