Go容器日志需确保可靠采集、不丢、带上下文、可过滤:强制换行防缓冲丢失,用JSON结构化(小写下划线字段),禁用敏感信息与网络Hook,仅输出到os.Stdout/Stderr。
Go 程序在容器中运行时,默认 log 输出到 os.Stdout 和 os.Stderr,这本身已是日志聚合的前提——只要容器运行时(如 Docker、containerd)配置正确,日志就会被采集到宿主机的 /var/log/containers/ 或通过 journalctl -u containerd 可查。真正的难点不在“怎么输出”,而在“怎么让输出能被可靠采集、不丢、带上下文、可过滤”。
Go 的 log 包默认使用 bufio.Writer,若写入未满缓冲区且程序退出,日志可能丢失;容器启动后立即崩溃时尤其明显。
log.SetOutput(os.Stdout) 显式绑定,避免意外写入文件或 ioutil.Discard
log.SetOutput(&logWriter{w: os.Stdout}) 自定义 writer,或更简单——直接用 fmt.Fprintln(os.Stdout, ...)(但会丢失时间戳和级别)log.Writer().(io.WriteCloser).Close()(仅当使用 log.New 且底层是 bufio.Writer 时需要)Fluentd、Filebeat、Loki 等采集器依赖结构化字段做路由和过滤。纯文本日志无法被高效解析,level=info msg="started" 这类 key=value 形式虽可 parse,但不如 JSON 稳定。
package main
import (
"encoding/json"
"log"
"os"
"time"
)
type LogEntry struct {
Timestamp time.Time `json:"timestamp"`
Level string `json:"level"`
Msg string `json:"msg"`
Service string `json:"service"`
TraceID string `json:"trace_id,omitempty"`
}
func main() {
entry := LogEntry{
Timestamp: time.Now(),
Level: "info",
Msg: "server started",
Service: "api-gateway",
TraceID: os.Getenv("TRACE_ID"), // 从环境继承
}
enc := json.NewEncoder(os.Stdout)
enc.Encode(entry) // 自动换行,无需手动加 \n
}
trace_id),与 Loki/Prometheus 生态对齐user_id、request_id
fmt.Println("debug")),会污染日志流容器日志通常持久化到中心存储(如 ES、S3),且可能被多个团队访问。硬编码密码、token、完整 request body 都会带来合规风险。
"user_id": "u_abc123" 而非 "user": {"id":"u_abc123","em
ail":"a@b.c","password":"..."}
len 和 sha256(payload[:min(1024, len(payload))]),而非全文log.Printf("DB_URL=%s", os.Getenv("DB_URL")) 是严重错误标准库 log 无法动态改 level 或加字段,生产环境应换结构化日志库。但要注意:Hook(如写文件、发 HTTP)在容器里极易引发阻塞或失败。
logrus:轻量,支持 logrus.WithField("service", "auth"),但默认 JSON formatter 不带毫秒级时间戳,需自定义zap:性能更好,zap.String("service", "auth") 开销更低,推荐用于高吞吐服务logrus_slack、logrus_syslog),容器内 DNS 不稳定、网络策略可能拦截 outboundos.Stdout 和 os.Stderr —— 把日志交给平台层去投递最容易被忽略的一点:Kubernetes 中 Pod 的 terminationGracePeriodSeconds 必须 ≥ 日志刷盘耗时。如果程序收到 SIGTERM 后立刻退出,而日志还在 bufio 缓冲区里,那最后几条日志就永远消失了。