配置数据库日志输出到syslog，运维再也不用挨个找日志了

作为运维或DBA谁没被数据库日志坑过本地日志散在各个服务器排查问题时登录一台又一台机器翻来翻去找不到关键信息偶尔磁盘满了日志被自动清理出了故障连追溯的机会都没有更别提合规审计要求本地日志随便删、随便改根本达不到要求。今天就给大家分享一个实测可用、零成本落地的方案——用Linux自带的rsyslog服务把所有数据库日志集中推送到syslog服务器从此日志管理躺平排查问题效率翻倍全程无复杂操作无额外组件依赖小白也能跟着一步到位亲测生产环境稳定运行放心抄作业先跟大家说下本次实战的环境很经典的客户端服务端架构大家可以直接对应自己的环境替换IP客户端数据库服务器同时也是rsyslog客户端IP192.168.1.201服务端专用syslog日志服务器IP192.168.1.202全程操作都是Linux基础命令不用写复杂脚本跟着敲就行一、先唠唠为啥非要把数据库日志推给syslog可能有人会问数据库日志存在本地不也能用吗那是你没遇到过这些糟心事单机存储太坑磁盘满、误删、硬件坏了日志直接永久丢失出问题连“黑匣子”都没有多节点排查崩溃如果有好几台数据库服务器排查问题要逐个登录翻不同目录的日志半天找不到重点合规审计过不了很多企业要求日志集中留存、不可篡改本地日志随便清理审计时直接翻车占用本地资源数据库本身就耗资源日志存本地还占磁盘万一磁盘满了直接影响数据库运行。而syslog咱们实际用的是增强版rsyslog就不一样了它是Linux系统自带的日志服务轻量又稳定几乎所有设备服务器、路由器、数据库都支持往它那发日志。把数据库日志推过去相当于给所有日志建了个“统一档案室”异地存储防丢失、统一检索省时间还能满足合规要求一举多得二、小科普rsyslog核心知识点不用深钻懂这些就够动手前先简单搞懂几个关键点避免踩坑不用死记硬背知道怎么用就行rsyslog的双重身 份它既能当“接收器”服务端监听端口接收其他设备的日志也能当“发送器”客户端把本机的日志转发给远程服务器。咱们这次就是用它的双重身份实现日志上送。日志的“分类标签”rsyslog用Facility设施给日志分类比如系统日志、邮件日志其中local0~local7是用户自定义的专门用来存数据库、应用这类业务日志咱们这次就用local0避免和系统日志混在一起。核心配置语法记不住也没关系后面直接抄加载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端口$ModLoadimudp$UDPServerRun514# 加载TCP接收模块备用$ModLoadimtcp$InputTCPServerRun514# 自定义日志存储模板按主机名进程名分类#### 业务日志集中存储 ####$templateRemoteLogs,/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 systemctlenablersyslog# 设为开机自启避免重启服务器后失效systemctl status rsyslog如果看到“active (running)”就说明服务启动成功了没报错就是好现象4. 检查端口确认监听成功最后确认一下514端口是否被rsyslog监听命令netstat-antulp|grep514正常情况下会显示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的客户端和服务端但数据库还不知道要把日志发给谁所以这一步要告诉数据库别再只把日志存本地了发给syslog1. 修改数据库配置文件kingbase.conf先切换到数据库用户找到kingbase.conf配置文件命令su- kingbasevi/home/kingbase/db/r6_c8/data/kingbase.conf# 路径按自己的实际路径改找到日志相关的参数修改成下面这样找不到就直接搜索vi里按/搜索# 日志输出目标指定为sysloglog_destinationsyslog# syslog设施必须和rsyslog配置的local0一致不然日志发不过去syslog_facilityLOCAL0# 日志标识服务端会用这个名字建日志文件好识别syslog_identkingbase# 下面两个可选按需开启# 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_logls-lh# 查看日志文件cat最新的日志文件名如果看到下面这句话就说明数据库配置成功了日志已经开始往syslog发了2023-10-1915:34:37.932 CST[4597]LOG: ending log output to stderr HINT: Future log output will go to log destinationsyslog.翻译一下就是以后日志不往stderr输出了都发给syslog啦第四步验收成果在syslog服务端查看远程日志所有配置都完成了最激动人心的时刻到了去syslog服务端看看能不能收到数据库的日志1. 找到日志存储路径咱们在服务端配置了模板日志会按“客户端主机名/进程名.log”的格式存储路径是/var/log/客户端主机名/进程名.log2. 查看日志内容确认成功用cat命令查看日志文件如果能看到数据库的启动、关闭、连接等日志比如下面这样就说明日志上送成功了Oct1915:34:37 loe kingbase[4597]: LOG: database system is ready to accept connections到这里整个数据库日志集中上送syslog的配置就全部完成了以后不管有多少台数据库服务器日志都集中存在syslog服务端排查问题直接去一个目录找再也不用挨个登录机器了是不是超省心总结其实整个配置流程很简单核心就是“服务端监听接收客户端转发数据库输出”用Linux原生的rsyslog零成本实现数据库日志集中管理不用装任何第三方组件稳定又省心。日志管理是运维的基础把日志管好不管是故障排查、安全审计还是合规检查都能省不少事。