Golang日志在CentOS上的传输方式

在CentOS上跑Golang应用，日志怎么传出去？这几乎是每个线上服务都会碰到的问题。说简单也简单，说复杂，里面涉及的工具链和权衡点还真不少。下面把这几种主流方案拆开聊聊。

先看最直接的几种路径——文件留底、网络直传、集中式管理、引入消息队列做缓冲。每一条路都有它最合适的场景。

一、日志传输的四种常见方式

1. 文件日志 + 系统服务采集

这是最“传统”的手法：Golang 程序用标准库 log 把日志写到本地文件。然后交给操作系统级别的日志服务——rsyslog 或 syslog-ng——去监听、收集和转发。好处是入侵性最低，程序只管写文件，后续的路由、过滤、压缩都由服务层完成，解耦得很干净。

2. 网络直传

如果不想走文件缓冲区，程序可以直接通过 TCP/UDP、gRPC 或者 HTTP 把日志推到远程服务器。Golang 的 net 包就能搞定，当然社区里 logrus、zap 这类日志库也内置了远程输出 hook，用起来更顺手。这种方式实时性高，但一旦远程服务不可用，日志就可能丢，需要自己加重试或本地缓冲。

3. 集中式日志管理

典型代表是 ELK Stack（Elasticsearch、Logstash、Kibana）以及 Fluentd。它们负责收集、清洗、存储和可视化。Golang 程序只需要把日志按标准格式（比如 JSON）输出到指定源，后面的流水线交给这些工具。适合多节点、大规模的场景，排查问题时 Kibana 上一条查询就出来，效率非常高。

4. 消息队列做中间层

当日志吞吐量巨大，或者有多消费者需求时，Kafka、RabbitMQ 这类消息队列就派上用场了。Golang 作为生产者将日志发送到队列，后端任意数量的消费者从队列拉取数据做持久化或分析。这层缓冲能扛住瞬时峰值，也便于解耦日志生产与消费逻辑。

二、一个网络直传的快速示例

先看一段最基础的代码——Golang 通过 TCP 连接把日志直接发到远程服务器。逻辑很清晰：拨号、创建 logger、写入。

package main

import (
    "log"
    "net"
)

func main() {
    serverAddr := "remote-server:12345"
    conn, err := net.Dial("tcp", serverAddr)
    if err != nil {
        log.Fatalf("Failed to connect to server: %v", err)
    }
    defer conn.Close()

    logger := log.New(conn, "", log.LstdFlags)
    logger.Println("This is a log message")
}

远程那头自然需要跑一个接收服务，否则数据来了没人接。这个例子只演示了“发送”端，实际生产环境中远程端通常会用 rsyslog、Logstash 或自建 TCP server 来承接。

三、用 rsyslog 搭一条完整的日志管道

如果你倾向让系统来管日志流转，rsyslog 是 CentOS 上默认就有的工具，配置得当后非常稳定。下面走一遍完整流程。

安装与启动

sudo yum install rsyslog
sudo systemctl start rsyslog
sudo systemctl enable rsyslog

配置 rsyslog 接收 TCP 日志

编辑 /etc/rsyslog.conf 或者新建一个配置文件（比如 /etc/rsyslog.d/50-default.conf），打开 TCP 输入模块，并指定日志落地路径：

module(load="imtcp")
input(type="imtcp" port="12345")

*.* /var/log/golang-logs.log

重启 rsyslog 让配置生效：

sudo systemctl restart rsyslog

Golang 程序向本地 rsyslog 写日志

程序端可以不再直接连接远程，而是把日志发到本机的 12345 端口（即 rsyslog 监听的端口）。当然，这里也可以改为写本地文件让 rsyslog 自己来 tail，但既然要走 TCP，那就用 socket 直送。下面是一个简单的接收端示例——其实就是一个 TCP server 把收到的内容打到标准日志里，实际使用时你可以让 rsyslog 直接接管转发。

package main

import (
    "log"
    "net"
)

func main() {
    localAddr := "localhost:12345"
    listener, err := net.Listen("tcp", localAddr)
    if err != nil {
        log.Fatalf("Failed to listen on %s: %v", localAddr, err)
    }
    defer listener.Close()
    log.Printf("Listening on %s", localAddr)

    for {
        conn, err := listener.Accept()
        if err != nil {
            log.Printf("Failed to accept connection: %v", err)
            continue
        }
        go handleConnection(conn)
    }
}

func handleConnection(conn net.Conn) {
    defer conn.Close()
    buf := make([]byte, 1024)
    for {
        n, err := conn.Read(buf)
        if err != nil {
            log.Printf("Failed to read from connection: %v", err)
            return
        }
        log.Printf("Received log: %s", string(buf[:n]))
    }
}

这段代码监听本地 12345 端口，每收到一条日志就打印出来。真实场景中你可以在这里把数据写入 rsyslog 的 socket 或直接写到文件，再由 rsyslog 做后续路由。

四、选型小结

没有“最好”的方式，只有“最合适”。单机调试时文件日志 + tail -f 就够了；多节点、要搜索的场景优先考虑 ELK 或 Fluentd；对可靠性要求极高且吞吐量大的场景，消息队列是更稳妥的选择。关键在于根据你的日志量、可用资源、运维习惯来定，没必要一上来就上重型架构。

希望这些思路和代码片段能帮你把 Golang 日志在 CentOS 上的传输管道搭起来。欢迎在实际操作中调整参数，毕竟环境和需求总是微妙的。