做过几年运维和开发的同学一定对“日志”这两个字又爱又恨。系统出问题的时候日志是唯一的破案线索系统平稳运行的时候日志又是硬盘空间的“隐形杀手”。而在所有日志体系里有一个协议几乎无处不在它就是syslog。从Linux服务器的系统日志、交换机的运行日志到防火墙的审计记录、Docker容器的标准输出背后都有syslog的影子。这篇内容我想把syslog彻底讲透。从它是什么、消息格式长什么样到怎么搭建一套完整的日志采集链路再到日志轮转、检索分析、常见故障排查一次说清楚。内容会尽量贴近实操涉及的命令和配置都是可以直接复制去用的也会穿插一些我在真实环境里踩过的坑。不管你是刚接触服务器运维的新人还是被公司日志系统折磨已久的“老油条”这篇应该都能给你一些参考。1. syslog到底是什么一个老协议的前世今生1.1 从BSD时代走来的日志协议syslog这个词严格来说有两层含义。一层是指系统里的syslog服务也就是我们常说的rsyslog、syslog-ng这些守护进程另一层是指一套网络协议用于把日志消息从产生方传输到收集方。我们现在讨论的主要是后者。这套协议的诞生可以追溯到1980年代的BSD Unix系统。那时候的Unix机器已经有多用户、多服务的概念系统内核、邮件服务、打印服务都会产生运行信息需要一个统一的机制把这些信息记录下来。于是syslog被设计出来任何程序都可以通过syslog接口发送消息然后由一个集中的syslog守护进程负责把消息写到本地文件或者转发到远程服务器。这个设计在当年非常超前。它把日志的产生和存储解耦了应用程序不用关心日志最终写到哪只需要按照约定把消息丢给syslog就行。后来随着时间的推移这个机制被越来越多的系统和网络设备采用逐渐成了事实上的工业标准。不过早期的syslog只是Unix世界里的“民间规范”并没有一个正式的RFC文档。直到2001年IETF才发布了RFC 3164把传统的BSD syslog协议用文档形式固定下来。2009年又发布了RFC 5424对协议做了大幅度的现代化改进增加了结构化数据、字符集声明等能力。现在你去看各种日志服务器、SIEM平台基本都同时兼容这两个版本的格式。1.2 日志设施与级别syslog的坐标体系要理解syslog必须先理解它的两个核心维度设施Facility和级别Severity。这两个字段合在一起构成了每条日志消息的“坐标”决定了这条消息被归到哪个类别、拥有多高的优先级。设施表示日志来源的类型取值范围是0到23。比较常见的几个0是内核消息kern4是安全/认证消息auth3是系统守护进程daemon8是cron定时任务16到23是本地自定义设施local0到local7留给应用程序自己定义使用。比如很多网络设备会把业务日志发到local0数据库审计日志发到local3这种约定很常见。级别表示日志的严重程度从高到低依次是0emerg系统不可用、1alert必须立即处理、2crit严重问题、3err错误、4warning警告、5notice正常但重要、6info常规信息、7debug调试信息。这个分级体系非常重要因为日志过滤、告警触发、存储策略全都依赖它。比如生产环境通常只要记录warning以上的日志debug信息量太大只在排查问题时临时开启。在syslog协议里设施和级别不是分开传的而是合并成一个优先级值Priority简称PRI计算公式是设施编号乘以8加上级别编号。比如local0.info就是16×86134kern.err就是0×833。这个数值会出现在每条syslog消息的最前面用尖括号包起来。后面讲抓包分析时你会看到它的实际用法。1.3 为什么今天还在用syslog可能有同学会问现在都有ELK、Loki、ClickHouse这些现代化的日志系统了syslog这么“老”的协议还有意义吗我的答案是它不仅有意义而且仍然是整个日志采集链路的基石。原因有三点第一覆盖率极高。几乎所有的Linux发行版都内置了rsyslog网络设备交换机、路由器、防火墙基本都支持syslog输出很多数据库、中间件也都有syslog转发能力。它是整个IT基础设施里“最大公约数”级别的日志协议。第二协议简单资源开销极低。UDP传输模式下发送进程只需要拼好一条字符串丢出去就行对业务性能的影响几乎可以忽略。对于每天产生几十GB日志的交换机和上百台服务器来说这个开销是可以接受的。第三生态成熟。syslog的消息可以无缝接入ELK、Graylog、Splunk、Loki等主流日志平台运维监控工具Zabbix、Prometheus的告警体系也能直接消费syslog。你完全可以把它当作整个日志采集链路的最前端后面接什么都行。2. 日志格式深度拆解看懂一条syslog消息2.1 老格式RFC 3164一眼看懂的经典结构传统的syslog消息格式非常直观基本上一眼就能看懂。一条典型的RFC 3164格式消息长这样134Oct 11 22:14:15 myhost sshd[1234]: Failed password for root from 192.168.1.100 port 22 ssh2来逐段拆解一下。最前面的134就是优先级值计算一下134÷816余6所以设施是local0级别是info。紧跟着的是时间戳格式是Mmm dd hh:mm:ss注意这里只有月份、日期和时间没有年份——是的老格式就是这么“糙”跨年日志靠时间排序可能出问题。时间戳后面是主机名也就是产生这条日志的机器名这里就是myhost。再往后是进程标签TAG格式是进程名[PID]这里是sshd[1234]表示是sshd这个进程、进程号1234发出来的。冒号后面是消息内容MSG也就是日志的具体正文。这种格式最大的问题是各字段之间用空格分隔如果消息内容里本身带空格倒无所谓内容会原样保留在最后一段但如果主机名、进程名里出现异常字符解析就可能出错。另外它没有明确的版本号接收方只能靠猜。不过在真实环境里老格式仍然是最常见的绝大多数网络设备和Linux系统默认输出的就是这种。2.2 新格式RFC 5424加了版本号和结构化数据RFC 5424是为了解决老格式的种种缺陷而推出的。一条新格式的syslog消息长这样1651 2023-10-11T22:14:15.003Z myhost su 1234 ID47 - BOMsu root failed for lonvick on /dev/pts/8从左往右拆165是优先级16520×85设施是local4级别是notice。然后是版本号1表示这是RFC 5424格式。接着是完整的时间戳ISO 8601格式带时区2023-10-11T22:14:15.003Z最后面的Z表示UTC时区精确到毫秒。之后的主机名、应用名su、进程ID1234和消息IDID47都作为独立字段出现解析起来非常明确。再看中间那个单独的-它代表结构化数据字段为空。结构化数据Structured Data是RFC 5424最有价值的创新它允许在日志消息里嵌入键值对。比如可以把HTTP状态码、用户ID、请求耗时这些业务字段塞进去接收方就能做精确的字段过滤和统计。最后是消息正文BOM表示UTF-8编码后面才是真正的内容。新格式看着复杂但对于日志解析来说每个字段都有明确的边界不用再靠猜来解析了。2.3 实用技巧用tcpdump抓包看真实syslog说再多理论不如实际操作一次。如果你机器上装有tcpdump可以直接抓包看syslog到底是怎么在网络上传输的。比如我这台测试机上rsyslog把日志转发到192.168.1.200的514端口抓包命令是tcpdump -i eth0 udp port 514 -A -c 5-A参数表示以ASCII方式打印数据包内容-c 5表示抓到5个包就停。执行后你会看到类似这样的输出12:34:56.789012 IP 192.168.1.100.42102 192.168.1.200.514: UDP, length 87 E..s.....h....d.....?..134Oct 11 22:14:15 myhost sshd[1234]: Failed password for root from 192.168.1.100 port 22 ssh2第一行是IP和UDP层的信息第二行开头是IP头部的十六进制数据E..s.....h后面明文显示的就是完整的syslog消息。注意这里的源端口是42102一个随机的临时端口而不是514——因为514是服务端的监听端口客户端发送时用的是系统的临时端口。这个细节在排查防火墙策略时很重要别只放行514端口了事有些环境需要放行所有的UDP高位端口到日志服务器的流量。3. 搭建一套可用的syslog采集传输链路3.1 服务端配置用rsyslog接收远程日志现在动手搭一套最基础的syslog日志服务器。我以Linux上最常见的rsyslog为例因为它是大多数发行版默认安装的。服务端要做的事很简单开启远程接收监听。编辑/etc/rsyslog.conf找到下面两行把注释去掉# provides UDP syslog reception module(loadimudp) input(typeimudp port514) # provides TCP syslog reception module(loadimtcp) input(typeimtcp port514)如果你的环境里没有这两行手动加上也行。修改完成后重启rsyslog服务systemctl restart rsyslog systemctl status rsyslog这里有个细节UDP和TCP到底开哪个我的建议是两者都开。UDP适合日志量大、单条发送、可以容忍少量丢失的场景TCP适合要求不丢日志、网络有一定波动的情况。很多设备默认只支持UDP但后续如果要接TLS加密传输就必须用TCP了。另外别忘了防火墙放行514端口否则日志根本进不来。接收下来的日志默认会写到/var/log/messagesCentOS/RHEL系或者/var/log/syslogDebian/Ubuntu系。但是把所有机器的日志混在一起看会非常痛苦最好按主机名分目录存储。3.2 客户端配置Linux服务器如何发送日志Linux客户端要做的就是在/etc/rsyslog.conf或/etc/rsyslog.d/下的自定义配置文件里加一行转发规则*.* 192.168.1.200:514一个表示UDP两个表示TCP。比如用TCP发送就是*.* 192.168.1.200:514*.*表示所有设施的所有级别都转发。如果只想转发比较重要的日志可以写成*.warning或者kern.*这种形式。我见过不少生产环境因为图省事把所有日志全部转发结果日志服务器的磁盘一天就被灌满了。建议转发前想一想真的需要把debug级别的内核日志也传到中央服务器吗配置修改后重启rsyslog然后用logger命令测试一条消息logger -p local0.info test message from client再到服务端查看有没有收到tail -f /var/log/messages如果看到类似Oct 11 22:15:30 client-host local0.info test message from client的输出说明链路已经通了。3.3 交换机、路由器怎么配网络设备的syslog输出网络设备的配置方式和Linux不太一样但思路是一致的。以常见的思科交换机为例开启日志远程发送就三条命令configure terminal logging host 192.168.1.200 logging trap info第一行进入全局配置模式第二行指定日志服务器地址默认使用UDP 514端口第三行设置发送的日志级别门限info表示info及以上的级别都发送。如果要用TCP或者指定端口可以加logging host 192.168.1.200 transport tcp port 1514这样的参数。华为设备也类似system-view info-center loghost 192.168.1.200 info-center source default channel loghost log level informational不同厂商的命令细节有差异但底层都是把设备产生的日志封装成syslog消息发出去。遇到旧设备不支持TCP的情况建议规划好UDP丢包的风险重要设备的审计日志尽量用TCP或TLS或者本地存储加远程转发双保险。3.4 Windows怎么办用NXLog把Event Log转成syslog这里要特别说明Windows原生并没有syslog客户端它的事件日志格式是自家的EVTX。但如果公司已经有了一套基于syslog的日志中心想让Windows的登录日志、安全审计日志也接入进来就需要借助第三方工具。我用的比较多的是NXLog社区版免费配置也简单。安装完成后编辑C:\Program Files\nxlog\conf\nxlog.conf核心配置类似这样Extension _syslog Module xm_syslog /Extension Input internal Module im_msvistalog Query QueryListQuery Id0Select PathSecurity*/Select/Query/QueryList /Input Output tcp Module om_tcp Host 192.168.1.200 Port 514 Exec to_syslog_ietf(); /Output Route 1 Path internal tcp /Route这段配置的意思是通过Windows事件日志接口读取Security日志转换成RFC 5424格式的syslog消息然后通过TCP发送到192.168.1.200的514端口。特别提醒Windows安全日志中包含登录成功/失败、账户锁定、权限变更等关键审计信息在等保测评和日常安全运营中都是审计重点。接入syslog中心后建议在服务端单独建一个目录存Windows的日志不要和Linux的混在一起。另外Windows的日志量通常比Linux大不少尤其是域控机器要做好磁盘空间评估。3.5 传输安全TLS加密与RELP可靠传输默认的syslog协议是明文传输的日志内容在网络上可以被任何能抓包的人看到。如果你的日志里包含IP地址、用户名、文件路径甚至SQL语句明文传输就有泄露风险。内网环境还好跨公网传输就必须加密。rsyslog从8.x版本开始内置了TLS支持。服务端需要生成证书并加载TLS模块module(loadimtcp) input(typeimtcp port6514 TLSCertFile/etc/rsyslog-certs/server-cert.pem TLSKeyFile/etc/rsyslog-certs/server-key.pem TLSCACertFile/etc/rsyslog-certs/ca.pem)客户端配置对应的TLS参数然后使用加TLS选项的方式连接。这种做法在金融、政务行业比较常见因为监管要求日志传输本身也要是加密的。如果需要更可靠的传输保障可以考虑RELP协议。RELP是rsyslog团队设计的可靠事件日志协议解决了TCP方式下连接断开时日志丢失的问题。它内置了应用层确认机制发送方会缓存未确认的日志重连后自动补发。配置方式和TCP类似module(loadomrelp) *.* action(typeomrelp target192.168.1.200 port2514)服务端要对应加载imrelp模块。RELP唯一的“缺点”是它只能在rsyslog之间使用对端也必须是rsyslog。不过对于纯Linux环境来说这已经是我比较推荐的高可靠方案了。4. 存储、轮转与检索日志不只是存下来4.1 logrotate本地日志文件的分割与清理日志文件如果不做任何处理迟早会把磁盘写满。Linux下最常用的工具是logrotate它由cron定时触发负责对日志文件进行轮转、压缩和清理。系统自带的/etc/logrotate.conf和/etc/logrotate.d/目录下已经有了一些预设规则。举个例子假设我们要给/var/log/app.log配置轮转策略/var/log/app.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate }逐行解释daily表示每天轮转一次rotate 7表示保留7份旧日志也就是一周compress表示旧日志压缩成gzip格式delaycompress表示隔一次压缩方便当天还有进程在写missingok和notifempty是容错选项文件不存在或为空时不报错copytruncate对正在被进程写入的文件特别重要它先复制一份当前内容然后清空原文件避免因为移动文件导致进程句柄失效。logrotate的工作原理是先重命名现有日志文件比如从app.log变成app.log.1再让应用重新打开一个新的app.log。但不是所有应用都支持这种“重开文件”的操作所以copytruncate这种折中方案在实际中很常用代价是复制和清空之间的几条日志可能会丢失。在排查“日志文件越来越大但logrotate就是不生效”这类问题时先用logrotate -d /etc/logrotate.conf的调试模式看看有没有报错再手动执行logrotate -f强制轮转一次基本就能定位原因了。4.2 集中存储方案对比ELK、Loki、Graylog怎么选当服务器数量超过几十台之后再到每台机器上翻日志就太原始了。集中式日志平台的核心价值就体现出来了所有日志在一个地方支持全文检索、字段过滤、可视化报表和告警。目前主流方案有三类ELKElasticsearch Logstash Kibana是最经典的组合。Logstash负责接收和解析syslog消息Elasticsearch负责存储和索引Kibana负责可视化。这套方案功能最全关联分析能力强适合有专职运维人员的团队。缺点是组件多内存和磁盘消耗大维护成本高。Loki是Grafana团队推出的轻量级方案。它的设计理念比较巧妙只给日志打标签不做全文索引而是等查询时再扫描日志内容。配合Promtail采集日志Grafana直接展示。这套方案部署简单尤其适合已经用了Grafana监控体系的团队。Graylog是另一个值得关注的方案。它的日志接收端内置了syslog、GELF等多种输入方式Elasticsearch做后端存储Web界面开箱即用。相比ELKGraylog在日志接入的“最后一公里”做得更好比如接收、解析、告警规则的配置都很方便模板化的Pipeline能省不少事。不管是哪套方案接收端都是标准的syslog监听所以前面配置好的rsyslog客户端不用改只要把转发目标从原来的logs服务器改成日志平台的syslog入口地址就行。4.3 日志保留策略180天审计留存怎么做很多行业的合规性要求日志至少要保留180天甚至更长这个需求看似简单实际落地时有不少坑。先算一笔账假设一台服务器每天产生2GB日志180天就是360GB。一百台服务器就是36TB。这个数据量对存储来说并不小而且日志是写多读少的数据对存储的性能要求不高但容量要求很高。我的经验是先做容量规划再决定方案。如果每天的日志量在几十GB级别用Elasticsearch直接保留180天问题不大但注意磁盘I/O和内存分配如果每天有几百GB甚至上TB的日志建议走“热温冷分层”的路子最近7天放在ES里提供快速查询7天到180天的转发到对象存储或者Hadoop这类廉价存储需要时再拉出来检索。另外还有一个容易被忽略的点日志服务器的系统时间。syslog消息里的时间戳是客户端自己打的如果客户端时间不准日志的先后顺序就是乱的审计时会出现“时间倒挂”的现象。强烈建议所有产生日志的机器都同步NTP并且在日志平台里校验各主机的时间偏差。4.4 顺带说一说数据库慢查询日志的采集热搜词里提到了MySQL慢查询日志这里补充一点数据库的慢查询日志虽然本质上是数据库自己的文本日志但你同样可以把它接入syslog体系。思路是让mysqld通过log_outputFILE把慢查询写到文件然后由rsyslog或filebeat采集这个文件转发到中央日志平台。或者如果你的MySQL版本支持可以在my.cnf里配置slow_query_log1和long_query_time2把超过2秒的SQL记录下来。这样在日志平台里搜索“slowquery”就能统一查看所有数据库实例的慢查询情况对性能调优很有帮助。有人会问数据库日志能不能直接走syslog协议这个要看具体版本。MySQL本身不支持原生syslog输出但MariaDB部分版本有--syslog选项PostgreSQL可以通过logging_collectoron配合syslog_facility参数直接输出syslog。接不进去的用文件采集再转发的方案兜底即可。5. 常见问题与排查技巧实录5.1 服务端收不到日志该从哪里查起这是我被问得最多的问题。服务端收不到日志排查思路基本是自底向上一条条来第一先在服务端抓包确认tcpdump -i eth0 udp port 514看看有没有UDP包到达服务器。如果根本没有包说明问题出在网络链路或者客户端配置上如果有包但rsyslog没写入日志文件问题出在rsyslog配置上。第二检查客户端配置。用logger -d -n 192.168.1.200 -P 514 test手动发一条UDP日志排除rsyslog配置错误的可能。如果手动发送能成功自动转发不行多半是rsyslog规则写错了仔细看转发规则的设施和级别匹配。第三确认服务端的监听状态ss -unlp | grep 514。如果没监听检查imudp模块和input(typeimudp port514)有没有生效。另外注意如果服务端和客户端在同一台机器上还要检查rsyslog的imuxsock模块配置是否正确。第四看服务端的日志文件权限。rsyslog默认以root运行但如果用了某些发行版的安全模块或者手动改了rsyslog的用户运行参数$PrivDropToUser可能有写权限问题。这一点不容易想到但一旦中招表现就是进程在跑、端口在听、包也能抓到就是写不进文件。5.2 日志时间戳差8小时时区问题速查syslog老格式的时间戳只显示本地时间不携带时区信息。如果客户端时区是Asia/ShanghaiUTC8服务端时区是UTC客户端发送时打的时间戳是Oct 12 08:00:00但时间实际是UTC的Oct 12 00:00:00。如果接收方不做处理日志的时间就会“看起来”快了8小时。解决思路有两个一是让所有服务器的系统时间和时区保持一致统一用UTC或者统一用中国标准时间然后日志平台按统一时区展示二是升级为RFC 5424格式因为新格式的时间戳自带时区偏移量接收方可以正确换算。在rsyslog客户端里可以用下面这行模板强制让消息使用RFC 5424格式和UTC时间$ActionFileDefaultTemplate RSYSLOG_SyslogProtocol23Format这个模板本身就是RFC 5424格式时间戳会用ISO 8601加时区偏移解析时不会再出现歧义。但要注意如果对端比如某些老网络设备只兼容老格式换模板可能导致解析失败得先做好兼容性测试。5.3 日志文件无限增长磁盘被写满的应急处理某天登录服务器发现df -h显示根分区已经用了95%第一嫌疑就是日志。排查命令du -sh /var/log/* | sort -rh | head -20这条命令按目录大小排序能快速定位最大的日志文件。如果是某个服务的日志在疯狂增长先重启服务或者让进程重新打开文件句柄如果服务本身有切分日志的功能就开启切分。如果磁盘已经满了应急办法是先备份再清空cp /var/log/app.log /tmp/app.log.bak cat /dev/null /var/log/app.log注意这里必须用cat /dev/null file而不是rm file再新建。因为很多进程还持有原文件的文件描述符删掉文件后空间不会立即释放得有进程关闭句柄才释放。用清空的方式进程继续往同一个文件描述符写不会受影响。这个问题的根因通常是logrotate配置不对。很多网上流传的配置模板里默认rotate 4保留4份但实际业务日志量很大4份可能只够用一天。我的建议是结合自己的日志量按天估算保留天数比如每天生成2GB、想保留30天就设置rotate 30并且打开压缩。配置完之后手动执行一次logrotate -f免得等到下次cron触发才生效。5.4 数据库binlog日志能不能删热搜词里还有“binlog日志可以删除吗”简单说一下我的理解。binlog是MySQL的二进制日志用于数据恢复、主从复制和增量备份。它和syslog是两回事但都属于“日志”的范畴混在一起的问题经常有人问。结论是binlog不能像删普通日志文件那样删也不能为了图省空间全部清空。正确的清理方式是设置expire_logs_days参数让MySQL自动删除过期的binlog。比如设置expire_logs_days7表示保留7天的binlog更早的自动清理。手动清理时用PURGE BINARY LOGS BEFORE NOW() - INTERVAL 7 DAY;这种SQL语句别直接到磁盘目录里去rm文件否则会让主从同步出问题。5.5 日志内容乱码与字段丢失日志平台里看到中文乱码通常是因为发送方用了一种字符编码接收方用另一种解析。RFC 5424里有BOM标记UTF-8编码但老格式没有编码声明。如果客户端日志里有中文建议统一让rsyslog输出的消息使用UTF-8编码并在日志平台里设置全局UTF-8。如果发现字段丢失比如主机名消失了、进程名不见了多半是日志格式和解析规则不匹配。比如你配置了RFC 5424的解析器但实际收到的消息是老格式某些字段必然解析不出来。这种问题没有捷径只能对照抓包结果逐字段确认日志源头上到底发了什么再调整解析器配置。写在最后的一点个人体会做运维这行久了我对日志的感情挺复杂的。平时它安安静静地躺在那里你甚至感觉不到它的存在但一出事你才意识到没有它寸步难行。syslog作为日志体系里最基础的协议虽然已经存在了几十年但它的设计思想——生产与存储解耦、分级分类、远程集中——至今仍然影响着所有现代化日志系统。最后分享一个我在实际使用中的小习惯不要在日志产生之后才想着怎么分析而是提前把格式约定好、级别策略规划好、存储周期评估好。日志链路是典型的“建时容易、改时难”等日志量大了再调整格式和轮转策略往往会伴随数据丢失或索引重建的阵痛。宁可前期多花半天把规则配齐也别等到半夜被磁盘告警叫醒。