ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

syslog与rsyslog实战:Linux日志收集、轮转与排错全解

syslog与rsyslog实战:Linux日志收集、轮转与排错全解 1. syslog 到底是什么为什么 Linux 运维离不开它syslog 在 Linux 里的地位有点像水管工手里的扳手——平时不起眼真到排故障、做审计、追溯源的时候少了它寸步难行。简单说syslog 是一套跨平台的日志传输协议和日志管理框架它把操作系统、应用、网络设备产生的运行信息统一收集起来按“设施facility 优先级severity”分类再写到本地文件或转发到远程日志服务器。它的价值在单机上看可能只是/var/log/messages里滚动的文字但当你负责几十台甚至上百台 Linux 服务器时没有集中式 syslog你根本不可能一台一台登录上去翻日志。这也是我在实际运维中一直建议团队无论规模大小都要先把 syslog 基础配置落地的原因。这套东西适合谁来学如果你是刚接触 Linux 的运维新手、正在折腾自己 Homelab 的爱好者或者负责公司服务器巡检的工程师这篇内容都能直接拿来用。我会从 rsyslog 这个当前 Linux 发行版默认的日志服务入手把配置拆开讲透包括服务端和客户端怎么配、日志怎么按天轮转、远程收集踩过哪些坑再穿插一些排错技巧。跟着走一遍你至少能搭出一套“能自动收日志、按主机分类、不爆磁盘”的日志体系而不是停留在只会tail -f的阶段。需要先说明的是Linux 下日志方案其实不止 syslog 一家但 syslog 依然是覆盖面最广、兼容性最好的基础协议。很多上层日志系统比如 ELK、Loki虽然功能更花哨底层采集端仍然保留了 syslog 通道说明这个老协议的生命力远比我们想象中强。理解了 syslog 的运作逻辑后面再接触其他日志平台你会发现很多概念都是相通的。1.1 syslog 的历史和定位一个老协议为什么还没被淘汰syslog 最初是 1980 年代 BSD Unix 上的一套日志机制后来被标准化成 RFC 3164再后来有了结构化更强的 RFC 5424。它最核心的设计思路是把“日志产生者”和“日志消费者”解耦应用不需要关心日志写到哪、怎么存、怎么转储只要按固定格式把消息丢给 syslog 即可。这个思路放到今天依然是日志架构里的基石。协议默认使用 UDP 514 端口传输消息格式大致是这样的34Oct 11 22:14:15 myhost su: su root failed for lonvick on /dev/pts/8尖括号里的数字是“优先级值”由设施乘以 8 再加上严重级别算出来。比如34对应 facility 为 4authseverity 为 2crit。早期协议比较简单设备把整段文本发出去就算完事接收方靠关键字匹配归类。后来 RFC 5424 引入了结构化数据、消息 ID、时间戳标准化的概念格式更像这样1651 2023-10-11T22:14:15.003Z myhost su 1234 ID47 - su root failed很多老工程师对 RFC 3164 的情节很深因为几乎所有网络设备、交换机、防火墙默认输出的都是这种格式。这也是 syslog 能成为“设备日志的事实标准”的原因你不需要给思科交换机装 agent只要配置logging server它就把日志往你的 syslog 服务器扔。Linux 服务器也一样rsyslog 开个 UDP 监听各种 Unix 系设备都能接入。这种跨厂商、跨系统、低门槛的兼容性是后来的很多私有日志协议比不了的。1.2 rsyslog 与 syslog-ng 怎么选别被“默认”限制住思路大多数 Linux 发行版默认装的是 rsyslog因为它直接从旧的 sysklogd 演进而来兼容性好、模块丰富CentOS、Ubuntu、Debian、RHEL 开箱即用。常见系统里你执行systemctl status rsyslog看到的服务就是它。rsyslog 的高性能表现也不错单机日志量不大时绰绰有余它还支持 TCP、TLS、REL 等可靠传输甚至内置了简单的队列和去重能力。syslog-ng 是另一个老牌实现特点是配置语法更干净支持正则解析、消息重写过滤能力强当年很多需要复杂日志路由的场景都爱用 syslog-ng。但这几年 rsyslog 的过滤能力也追上来了比如if $programname xxx then这类规则已经很好用。我的建议是新环境直接用 rsyslog因为生态和默认配置说明最多只有在需要处理非常复杂的日志流、要求高性能多级队列时才考虑 syslog-ng。选择标准只有一个能稳定解决你的问题就是好方案别陷入“工具决定论”。还有一个常被忽略的点rsyslog 和 systemd-journald 的关系。现在主流发行版用 systemdjournald 自己也在抓日志rsyslog 里面的 imjournal 模块会从 journald 读取日志再转发到 syslog 文件。这套双轨机制让很多人困惑——为什么journalctl看得到日志/var/log/messages却没有因为 rsyslog 对 journald 转发的消息有重复抑制、限速、过滤等配置后面我会专门讲这个坑。理解 rsyslog 和 journald 的关系比背任何配置文件都重要。2. rsyslog 核心配置怎么拆从模块加载到规则匹配搞清楚了 syslog 的定位接下来就该动真格的了。rsyslog 的配置主文件通常是/etc/rsyslog.conf很多发行版还会引入/etc/rsyslog.d/*.conf目录便于按功能拆分配置。我建议大家在/etc/rsyslog.d/下面单独建文件管理远程收集规则不要一股脑塞进主文件否则配置膨胀后跟个毛线团一样谁都理不清。2.1 打开配置文件先分清几大区域用vim /etc/rsyslog.conf打开一个典型的 CentOS 或 Ubuntu 配置你会看到三类内容模块加载区以module(load...)开头比如加载imuxsock监听本地日志 socket、imjournal读 systemd journal、imudp启动 UDP 服务、imtcp启动 TCP 服务。全局指令区定义$template输出模板、$FileOwner、$FileGroup、$FileCreateMode等控制生成日志文件的权限和路径格式。规则区形如facility.priority /var/log/xxx.log其实是一行行“条件到动作”的映射。理解这三个区域是必须迈的门槛因为很多人上来就抄网上的*.info;mail.none /var/log/messages抄完出了问题完全不知道从哪查。其实这条规则的意思是“所有设施、info 及以上级别的日志排除 mail 设施写入 /var/log/messages”。分号表示排除多个选择器用分号连接。*.info是通配符mail.none表示 mail 设施不匹配任何级别相当于忽略它。再看一下常见的选择器写法选择器示例含义*.info所有设施 info 及以上级别mail.*邮件的所有级别authpriv.*authpriv 设施所有级别cron.info仅 cron 的 info 级别不含更高或更低kern.!err内核日志中除 err 外全部user.*;mail.noneuser 全部mail 排除号是很多人忽略的细节。默认情况下facility.info匹配的是“info 及以上”也就是包括 notice、warning、err 等更高级别只有前缀才是精确匹配到这个级别。这个语义区别在写过滤规则时非常关键比如你想单独把cron.info归档如果写成cron.info实际的 cron 日志里什么级别的都会被写进去和预期完全不符。2.2 模板语法和属性变量让日志文件按主机、程序分开的关键默认配置只把日志堆在几个固定文件里比如/var/log/messages。但生产环境通常要按来源主机、程序名拆分否则几十台机器混在一起你查个问题眼睛都要花。rsyslog 的模板template就是解决这个问题的核心手段。一个最简单的按主机拆分的模板可以写成$template RemoteHostLog, /data/syslog/%HOSTNAME%/messages.log *.* ?RemoteHostLog当远程设备或服务器把日志发来后rsyslog 会自动读取消息里的 HOSTNAME 属性替换到路径模板中日志就被写到/data/syslog/web01/messages.log。路径里的目录如果不存在需要开启$DirCreateMode 0755和$FileCreateMode 0644并确保 rsyslog 进程有权限创建目录。第一次配置时最常见的报错就是目录权限不足日志直接被丢弃。rsyslog 的模板属性变量远不止 HOSTNAME我常用的还有programname程序名、syslogtag带 PID 的标签、timegenerated接收时间、fromhost-ip来源 IP、msg消息正文。比如要把不同程序的日志拆到不同文件可以这样$template SplitByProg, /data/syslog/%fromhost-ip%/%programname%.log if $programname sshd then ?SplitByProg stop最后那行 stop很多人看不懂。它的意思是“上一条规则匹配后的动作也作用于本条”实际上就是继续执行后面的动作而stop表示不再匹配后续规则。打个比方rsyslog 的规则像流水线上的分拣工消息经过一个规则如果命中要么写文件、要么继续流转stop就是让这条消息分流到这里就结束别再往下走重复写文件。这个机制用好了能避免日志重复落盘用不好会莫名丢日志。2.3 模块选型imuxsock、imjournal、imudp、imtcp 的应用场景rsyslog 最灵活的资产是模块体系。imuxsock负责从本地/dev/logsocket 读取日志这个模块几乎必须在配置里imjournal则对接 systemd-journald用于读取 journald 捕获的日志imklog读取内核日志通常和 imuxsock 配套imudp、imtcp则是远程收日志的入口。我在新装系统上一般至少确认下面这几行存在module(loadimuxsock) module(loadimjournal) module(loadimklog)远程服务器如果需要收设备日志再加上 UDP 或 TCP 模块。UDP 轻量但无保障网络抖动会丢日志TCP 可靠但可能因为连接阻塞影响日志实时性。我自己的习惯是如果设备不支持 TCP就用 UDP所有支持 TCP 的 Linux 客户端一律走 TCP重要审计场景再加 TLS 加密。配置模块的方式老语法和新语法都可能遇到比如$ModLoad imudp是老写法module(loadimudp)是新写法两种都能跑但新语法在 rsyslog 8.x 上更规范建议优先用新语法。还要特别提醒一下imjournal的限流问题。新版 rsyslog 为了防止 journald 刷屏默认可能有RateLimitInterval之类的设置。如果你发现某些高频日志比如 sshd 爆破尝试没有写入 syslog 文件多半就是限流在起作用。可以在模块加载后调整相关参数或者干脆在journald.conf里关掉限流。这个话题放到后面“常见问题”里再细说。3. 搭建 syslog 日志收集服务端五步搞定远程日志汇聚单机配置再熟练也只是 syslog 的起点。真正体现价值的是把几十台服务器的日志统一收集到一台中央日志机上。这里我以 rsyslog 搭建服务端为例完整走一遍配置流程。目标很明确客户端日志通过网络发送到服务器服务器按“来源 IP 程序名”分类落盘保留 N 天后再压缩归档。3.1 服务端开启 UDP/TCP 监听注意端口和防火墙第一步确认 rsyslog 已经安装并启动systemctl status rsyslog systemctl enable rsyslog如果没安装CentOS 系用yum install rsyslogUbuntu/Debian 系用apt install rsyslog。装好后编辑/etc/rsyslog.conf在模块区域添加module(loadimudp) input(typeimudp port514) module(loadimtcp) input(typeimtcp port514)这里我用 TCP 和 UDP 同时监听 514 端口方便兼容不同类型的客户端。需要注意514 是特权端口rsyslog 必须以 root 身份启动才能绑定。大多数发行版默认没问题但如果你用非 root 跑 rsyslog必须改用 10514 这类高端口否则启动会报Permission denied。第二步防火墙必须放行。CentOS 7 以上的 firewalld 命令是firewall-cmd --permanent --add-port514/udp firewall-cmd --permanent --add-port514/tcp firewall-cmd --reloadUbuntu 如果启用了 ufw加一条ufw allow 514/udp ufw allow 514/tcp这一步最容易翻车因为很多人配完服务端发现ss -lunp | grep 514明明在监听客户端也启动了但服务端就是收不到包。八成就是防火墙把你挡了。可以用tcpdump -i eth0 udp port 514先抓包验证包能到网卡却不进 rsyslog再查端口和进程权限。3.2 服务端按主机归类日志模板加目录规划端口通了之后就要规划日志落盘。我不建议把所有日志都丢进/var/log/messages因为多个主机的日志挤在一起既难查又难做权限隔离。生产环境我一般单独准备一块数据盘挂载到/data/syslog下目录结构按“来源 IP / 日期”组织。配置如下$template RemoteLog, /data/syslog/%fromhost-ip%/%$year%-%$month%-%$day%/messages.log $template RemoteMsg, /data/syslog/%fromhost-ip%/%$year%-%$month%-%$day%/%programname%.log规则部分用条件分流if $fromhost-ip ! 127.0.0.1 and $programname ! systemd then ?RemoteMsg stop这样每台客户端会在/data/syslog/192.168.1.10/2025-06-01/下生成按程序名拆分的日志文件比如sshd.log、nginx.log。按日期分目录的好处是后续清理和归档非常方便。时间变量$year、$month、$day来自消息接收时刻如果你要按消息本身的时间戳过滤得用timegenerated相关属性不要混。还要记得设置目录和文件的权限模式$DirCreateMode 0755 $FileCreateMode 0644 $Umask 0022如果希望某类日志单独给安全团队读可以用$FileOwner root、$FileGroup secgroup指定属主和属组。3.3 配置 Linux 客户端发送日志用 logger 测试最方便客户端配置就简单多了不需要开监听只需要把本机产生的日志转发到服务端。我通常直接在/etc/rsyslog.d/60-remote.conf里写*.* 192.168.1.10:514表示 UDP表示 TCP。如果希望日志既写本地又发远程把规则分开写*.info;mail.none;authpriv.none /var/log/messages *.info 192.168.1.10:514这里注意规则顺序rsyslog 按规则顺序从上到下执行消息可能匹配多条规则。如果你写了*.* server之后再写*.* /var/log/messages那么消息会同时写入本地和远程这是合理的如果只想发远程不写本地就要在远程规则后面加 stop否则默认会继续往下执行。配置完成后重启 rsyslog用logger命令做连通性测试logger -n 192.168.1.10 -P 514 test syslog message from client如果-n指定服务端那么这条日志直接以 UDP 发给服务端服务端那边可以执行tail -f /data/syslog/192.168.1.10/*/*.log看到消息就说明链路通了。另外如果客户端用到logger -u /var/log/...或者应用直接调用 syslog 接口rsyslog 都会捕获到不需要每个应用单独装 agent这是 syslog 相比其他采集方案最大的优势。3.4 基于 journald 的转发注意点在 systemd 发行版上rsyslog 的本地日志来源主要是 imjournal所以客户端发远程日志时要意识到你看到的journalctl输出和转发到远程服务器的内容可能存在“时间差”和“日志内容差”。这不是 bug而是 journald 和 rsyslog 之间也要通过 socket 传递消息。如果应用日志量特别大我建议在客户端把 rsyslog 的 imjournal 配置为StateFile指定状态文件这样 rsyslog 重启后能记住 journal 读取的位置不会重复或丢失日志。示例module(loadimjournal StateFile/var/lib/rsyslog/imjournal.state)之前我遇到过客户端重启后重复灌入几万条历史日志的事故就是因为状态文件丢了rsyslog 把 journal 里积压的旧日志重新传了一遍。所以说这个参数不是摆设。4. 日志轮转与存储策略别让磁盘被日志撑爆日志如果不做轮转早晚把磁盘写满。Linux 上负责日志轮转的主要是logrotate它配合 cron 定时执行。rsyslog 自己只管写不负责清理所以必须内外结合设置存储策略。4.1 logrotate 工作机制为什么要用 copytruncate/etc/logrotate.conf是全局配置文件/etc/logrotate.d/下面是各软件包的独立配置。一个典型的 rsyslog 轮转配置是/var/log/messages { weekly rotate 4 compress delaycompress missingok notifempty create 0644 root root postrotate /usr/bin/systemctl reload rsyslog /dev/null 21 || true endscript }关键参数的含义weekly每周轮转一次也可以写daily或size 100M按大小触发。rotate 4保留最近 4 个轮转文件更老的删除。compress轮转后压缩为 gzip。delaycompress延迟一天压缩让 rsyslog 能继续写最近一个轮转文件。copytruncate先复制文件内容再清空原文件适合无法通知进程重开文件句柄的场景。create轮转后创建新文件并设置权限配合postrotate通知 rsyslog。为什么 rsyslog 日志建议用createpostrotate而不是copytruncate因为 rsyslog 一直持有日志文件的文件描述符如果直接重命名文件rsyslog 还会往旧的 inode 写入文件不会变成新名日志会继续写进已经被轮转的旧文件里。postrotate里执行systemctl reload rsyslog相当于让 rsyslog 重新打开文件描述符。而copytruncate是先 cp 后 truncatersyslog 不必重启但 cp 大文件时会出现一个瞬间的空窗可能丢失少量日志。对于高要求环境我更倾向create reload 方案。4.2 远程日志目录单独管理按天归档和清理服务端/data/syslog/下的日志不能靠系统默认轮转去管因为文件名每天都在变目录结构也复杂。最简单的方案是自己写一个清理脚本用 crontab 每天执行。比如保留 90 天find /data/syslog -type f -mtime 90 -delete find /data/syslog -type d -empty -delete第一行删除 90 天前的日志文件第二行删掉空目录。对合规要求高的行业也可以先把压缩后的归档移到冷存储再删除。命令很直白但要注意时区问题find -mtime按天粒度计算如果日志文件是跨时区生成的清理边界可能差一天。想要精确控制就用touch -d做基准比较或者干脆按文件名日期过滤例如删除2024年之前的目录。我这里再给一个生产环境验证过的归档脚本思路。每天凌晨把前一天的日志打包放到/data/archive/下压缩后删除原目录DATE$(date -d yesterday %F) tar czf /data/archive/syslog-$DATE.tar.gz /data/syslog/*/$DATE/ 2/dev/null rm -rf /data/syslog/*/$DATE/这样磁盘占用的增长曲线就变成“每天一个压缩包”压缩比通常能达到 10:1 以上。如果你的日志包含大量重复消息甚至可以考虑在 rsyslog 层面做去重比如$RepeatedMsgReduction on但去重会牺牲审计完整性安全团队经常找我反对这个所以别默认开启。4.3 磁盘意外撑满时的应急处理即使配置了轮转日志磁盘也有可能突然被撑爆。最常见的场景某个程序抛异常疯狂打日志logrotate 还没来得及轮转磁盘分区就满了。此时不要慌先找出最大的日志文件du -sh /var/log/* /data/syslog/* 2/dev/null | sort -h然后可以直接手动清空指定文件但注意不能rm后立刻新建因为 rsyslog 还握着旧 inode。安全操作是先 truncatetruncate -s 0 /var/log/messagestruncate -s 0会清空内容但保留文件句柄rsyslog 会继续往这个文件里写不会产生新的空文件残留。这是我在磁盘告警时最常用的应急手段。之后再排查是什么程序刷了这么多日志用tail细看必要时候临时改配置把日志级别调高等系统稳定了再恢复。5. 可视化日志查看Visual Syslog Server 和轻量分析方案syslog 最大的弱点是“只有文本没有图形”。排错时你不可能一直瞪着眼睛刷终端所以很多人会在日志服务器上搭一层可视化。搜索结果里频繁出现的 Visual Syslog Server 就是这样一个轻量工具虽然它是个 Windows 程序但用途正好弥补 syslog 的不足我经常引用来做演示和临时分析。5.1 Visual Syslog Server 能干什么Visual Syslog Server 是一个运行在 Windows 上的免费小工具可以监听指定 UDP 端口接收 syslog 消息并在 GUI 界面上实时滚动显示日志。它的定位不是生产级日志分析平台而是一个“看得见日志流动”的调试工具。你可以在自己电脑上跑一个实例把 Linux 服务器的日志转发过来立刻就能看到消息一条条滚进来比在 Linux 上tail -f直观得多。它的配置很简单设置监听协议和端口默认 UDP 514打开后就能接收。因为协议是标准的Linux 端只要把日志你的WindowsIP:514发过来即可。我建议不要在生产环境依赖它它没有索引、没有历史查询、没有权限管理但用来验证转发链路、观察日志内容格式非常顺手。5.2 Grafana Loki 才是长期可视化方案如果你真的想长期做日志可视化我推荐组合是 Grafana Loki或者 ELK。这里不展开搭建步骤只讲和 syslog 的衔接点Loki 有专门的 syslog 采集端promtail可以直接监听 514 端口接收 syslog 并打上标签如 host、program然后在 Grafana 里按标签过滤查询。相比 Visual Syslog Server它能存历史、能写查询语句、能设告警才算是生产工具。如果你只是临时分析一条日志的格式我建议在 Linux 上用awk和grep先做快速过滤。比如查看某台主机今天 sshd 的登录失败记录grep -i failed password /data/syslog/192.168.1.10/*/sshd.log | awk {print $1,$2,$3,$9,$11}这种一行命令的威力经常被低估很多人动不动就想上 Kibana其实 90% 的查询需求用 grep awk 五秒内就能出结果。工具链够用就好我把可视化方案放在最后也是这个原因——先把日志收下来再考虑怎么展示顺序不要搞反。6. 常见问题与排查技巧实录我把这几年用 syslog 遇到的高频问题整理成一份排查手册。这些问题单独看都不难但组合起来足以让人抓狂。很多刚入行的同事问我“日志到底去哪了”我都会让他们按这套步骤查一遍。6.1 服务端收不到日志的排查路径收不到日志按下面的顺序逐一排除基本十分钟内定位客户端有没有真正产生 syslog先执行logger -n 服务端IP -P 514 hello手动发一条。服务端端口监听了没ss -lunp | grep 514。防火墙放行了没firewall-cmd --list-all或iptables -L -n。抓包确认包到了没tcpdump -i 网卡名 udp port 514 -nn。SELinux 拦截了没getenforce如果是 Enforcing用ausearch -m avc -ts recent查拒绝记录再决定是否放行 syslog 端口。rsyslog 自己的日志有没有报错journalctl -u rsyslog -e。我曾经遇到一个诡异问题客户端和服务端都在同一安全组抓包能看到包到了服务器网卡但/var/log/messages就是没有内容。最后发现是 rsyslog 配置文件里$SystemLogSocketName被改过本地 socket 和远程输入模块冲突导致远程消息没进入主事件循环。这种情况下直接看/var/log/rsyslog/或者systemctl status rsyslog的输出能发现线索。6.2 日志时间不对、时区不一致的处理syslog 消息里的时间戳有两个一个是消息产生时间timereported一个是服务端接收时间timegenerated。如果你发现日志记录时间比实际晚 8 小时多半是客户端发送时用的 UTC而接收端没做时区转换。rsyslog 支持在模板里对时间做格式化比如$template ChinaTime, %timegenerated:::date-rfc3339% %fromhost-ip% %msg%RFC 3339 格式自带时区偏移能明确显示08:00或Z。另外一个基础操作是把客户端和服务端都统一到同一时区直接timedatectl set-timezone Asia/Shanghai同时开启 NTP 同步。没有统一时间源日志排查时前后顺序都是乱的这个坑非常普遍。6.3 journald 限流导致日志缺失systemd-journald 默认有消息速率限制通常是一秒内最多接收一定量日志。如果程序刷屏journald 会开始丢弃消息rsyslog 自然也就收不到。遇到这种情况日志缺失的表现是“中间断了一截然后又恢复”。检查方法是看journalctl -f里有没有类似Journal file ... is full的消息。如果确认限流导致的问题可以调整/etc/systemd/journald.confRateLimitIntervalSec0 RateLimitBurst0改成 0 表示取消限制或者改成更大的数值。改完执行systemctl restart systemd-journald。注意这只是临时救火方案日志量过大时更好的思路是让应用直接写文件或降低日志级别而不是无限放大 journald 的接收能力。6.4 本地日志和远程日志重复很多人配完 rsyslog 后发现同一条日志本地messages有远程也发了一份甚至本地还有两三个文件各写一份。这通常是因为规则写得不严谨默认配置里*.info和自定义规则同时匹配。解决办法就是在自定义规则后用 stop终止匹配或者调整本地落盘规则把远程主机的日志排除在本地默认规则之外。举例我经常这样写if $fromhost-ip ! 127.0.0.1 then { /data/syslog/%fromhost-ip%/%programname%.log stop }这样远程消息只会进入远程目录不会落入本地/var/log/messages。本地设备自己的日志则照常走默认规则互不干扰。6.5 性能调优队列和并发参数如果日志量特别大rsyslog 默认配置会拖后腿。主要调几个地方MainMsgQueueSize主消息队列大小默认可能较小写入慢时消息会丢弃可以加大到几万甚至几十万。MainMsgQueueTimeoutEnqueue入队超时时间适当延长可以缓解突发流量。MainMsgQueueDiscardSeverity设置什么级别的消息在队列满时允许丢弃默认是 8不丢可以调整为 7 以上避免最严重级别丢失。远程 TCP 连接使用$ActionQueueType LinkedList和$ActionQueueFileName把写入动作挂到磁盘队列上。我的经验是单机日均几百万条日志rsyslog 默认配置还能抗住到千万级别以上就必须考虑分布式日志方案或者把不同设施分流到不同 rsyslog 实例。一味的调大队列只会把问题推迟不是根治办法。6.6 最后再分享一个排查技巧如果你要确认某条消息到底匹配了哪条规则rsyslog 可以开调试模式。停掉服务后前台执行/usr/sbin/rsyslogd -dn它会输出每条消息匹配规则的详细过程调试完再正常启动服务。这个方法比瞎猜配置高效得多我处理疑难杂症时必用。平时维护 syslog我的体会是“日志收不到先抓包配置不对看调试程序刷屏查限流时间不对看时区”。把这四句话记在心里能省下大半天排查时间。syslog 这套东西老则老矣但它依然是 Linux 日志体系的底座。把这套基础打扎实后面无论接 ELK、Loki 还是自研日志系统你都会有清晰的底牌。哪怕是再花哨的日志平台也总需要一个稳定可靠的日志入口那入口大概率还是 syslog。
返回列表