CentOS syslog-ng高级日志处理怎么配置？多源采集与日志转发实战详解

系统日志、应用日志、安全审计日志分散在几十台机器上，一旦线上出问题，运维人员只能一台台登录服务器去翻/var/log/messages，这种排查方式既低效又容易遗漏关键线索。syslog-ng在CentOS上提供了比传统rsyslog更灵活的日志处理能力，它把日志的采集、过滤、解析、存储、转发抽象成四类配置语句，组合起来几乎能应对所有日志管理场景。本文从配置结构讲起，逐步展开过滤规则、模板定制、缓冲队列和加密转发这些进阶技巧，并给出一份集中式日志收集的完整配置示例。

一、syslog-ng的安装与配置文件结构

CentOS 7以上的版本可以直接通过EPEL仓库安装syslog-ng，安装前先确认系统已启用EPEL源。需要注意的是，syslog-ng和rsyslog默认都监听514端口，两者不能同时以服务端模式运行，切换前建议先停掉rsyslog服务，否则端口冲突会导致启动失败。

yum install -y epel-release
yum install -y syslog-ng
systemctl stop rsyslog
systemctl disable rsyslog
systemctl enable --now syslog-ng

syslog-ng的主配置文件位于/etc/syslog-ng/syslog-ng.conf，开头一行@include指令会把conf.d目录下所有以.conf结尾的文件全部加载进来。生产环境推荐把自定义配置全部写在conf.d目录中，避免直接改动主文件，这样软件升级时自定义配置也不容易被覆盖。

整个配置体系由四种语句构成：source定义日志从哪里来，可以是本地文件、UDP/TCP网络、Unix套接字，甚至某个程序的输出；destination定义日志到哪里去，可以是本地文件、远程服务器、数据库或消息队列；filter定义匹配条件，支持按设施、优先级、主机名、正则表达式过滤；log语句则是把前三者串起来，声明一条完整的日志管道。理解了这个逻辑，再看任何复杂配置都不会发懵。

二、source与destination的高级配置技巧

先看source的写法。除了最常见的系统日志，syslog-ng还支持tail任意文本文件，这对采集Nginx、Tomcat这类自己写日志文件的应用特别有用。

source s_system {
    system();
};

source s_nginx_access {
    file("/var/log/nginx/access.log" flags(no-parse));
};

source s_network {
    network(transport("tcp") port(514) max-connections(100));
};

上面三个source分别对应系统日志、文件跟踪和网络接收。flags(no-parse)告诉syslog-ng不要把文件内容当作标准syslog报文解析，而是整行当作原始消息处理，这样才能用后续的parser去解析JSON或自定义格式。network driver里还可以指定transport("tls")启用加密接收，后面会单独讲。

destination同样灵活，最常用的是按模板写文件，以及转发到远程中心服务器：

destination d_by_host {
    file("/var/log/remote/$HOST/$YEAR-$MONTH-$DAY.log"
         create-dirs(yes)
         owner("logadmin") group("logadmin") perm(0640));
};

destination d_center {
    network("192.168.10.20" transport("tcp") port(514)
            disk-buffer(
                mem-buf-size(10000)
                disk-buf-size(200000000)
                reliable(yes)
                dir("/var/spool/syslog-ng/")
            ));
};

第一个destination用宏变量按主机名和日期自动分目录存储，create-dirs(yes)保证目录不存在时自动创建，perm(0640)收紧了文件权限。第二个destination的关键在于disk-buffer：当网络中断或中心服务器宕机时，日志会先写入本地磁盘缓冲区，恢复后自动重传，reliable(yes)确保消息不丢失。这个缓冲机制是生产环境转发日志时必配的选项，很多人忽略了它，结果网络一抖动日志就永久丢失。

三、filter过滤与rewrite重写的组合应用

filter是syslog-ng的灵魂，支持多条件组合。比如想把所有包含error或critical关键字的应用日志单独收集，同时排除掉调试类消息，可以这样写：

filter f_errors {
    level(emerg..err) or message("error|critical");
};

filter f_apps {
    program("nginx|java|sshd") and not level(debug);
};

filter f_exclude_noise {
    not message("health check") and not host("monitor-agent");
};

level()支持范围写法，emerg..err表示从最严重到err级别的全部消息。program()按产生日志的进程名匹配，message()内部走的是正则匹配，注意特殊字符需要转义。多个filter之间可以用and、or、not自由组合，语法非常接近编程语言里的布尔表达式。

rewrite则用于改写日志内容。典型场景是脱敏：把日志里的IP地址替换成掩码，或者统一消息格式。下面这个例子用正则把IPv4地址最后一段替换为星号：

rewrite r_mask_ip {
    subst("([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.)[0-9]{1,3}", "\1***",
          value("MESSAGE"), type("pcre"));
};

这里用了PCRE正则，捕获组通过\1引用保留前三段。类似手法还可以用来删除敏感的手机号、身份证号，或者给缺少主机名的消息补全$HOST字段。rewrite放在log语句链里执行，改写完成后再走destination，落盘的就是脱敏后的内容。

log语句负责把这一切串起来，一条完整链路的写法如下：

log {
    source(s_system);
    filter(f_errors);
    rewrite(r_mask_ip);
    destination(d_center);
    flags(final);
};

flags(final)表示匹配到这条链路的消息不会再进入后续链路，避免同一份日志被重复处理。多条log链路按配置文件中的顺序依次匹配，合理利用final标记可以让配置逻辑更清晰。

四、搭建一套集中式日志收集方案的完整示例

最后把前面的知识点串成一个可落地的方案：Web服务器作为客户端采集nginx日志并转发，日志中心负责接收、按主机分目录存储，并在传输层启用TLS加密。日志中心端的配置如下：

source s_tls {
    network(transport("tls") port(6514)
        tls(key-file("/etc/syslog-ng/tls/server.key")
            cert-file("/etc/syslog-ng/tls/server.crt")
            peer-verify(optional-untrusted)));
};

destination d_hosts {
    file("/data/logs/$HOST/$PROGRAM/$YEAR-$MONTH-$DAY.log"
         create-dirs(yes));
};

log { source(s_tls); destination(d_hosts); };

客户端转发端的配置把transport换成tls，并指定CA证书验证服务端身份：

destination d_center_tls {
    network("log-center.internal" transport("tls") port(6514)
        tls(ca-file("/etc/syslog-ng/tls/ca.crt")
            key-file("/etc/syslog-ng/tls/client.key")
            cert-file("/etc/syslog-ng/tls/client.crt"))
        disk-buffer(reliable(yes) disk-buf-size(512000000)
                    dir("/var/spool/syslog-ng/")));
};

证书可以用openssl自签，把CA证书分发到所有客户端即可完成双向认证。配置完成后用syslog-ng -s做语法检查，再用syslog-ng-ctl reload平滑重载配置，不会中断正在处理的日志流。日常排查时查看stats计数非常直观：syslog-ng-ctl stats能实时看到每条链路处理了多少条消息，判断过滤规则是否生效一目了然。

整体来看，syslog-ng的配置思路就是搭积木：source收进来，filter筛一遍，rewrite改一改，destination送出去。掌握了这四类语句的组合方式，无论是简单的日志归档还是多级日志中心级联，都能用同一套方法解决。如果环境规模继续扩大，还可以在destination端接入Kafka或Elasticsearch，把syslog-ng当作统一的日志采集入口来使用。

syslog-ng配置CentOS日志管理日志转发修改时间：2026-09-04 02:05:12