Go日志集中收集的核心是输出结构化JSON日志并交由专业采集器处理，而非自建日志服务器；需使用zerolog/zap输出RFC3339时间戳、字段化信息、固定上下文，并通过stdout/文件暴露，由Fluentd、Vector等采集器按协议拉取或监听。
用 Go 实现日志集中收集，核心不是“自己造轮子做日志服务器”，而是让 Go 应用产生的日志能被主流日志系统（如 Loki、ELK、Fluentd、Vector）稳定、可靠、结构化地采集。重点在于：输出格式可解析、传输不丢日志、支持上下文与分级、适配采集器协议。
输出结构化日志（JSON 格式）
默认的 log 包输出纯文本，难以被自动解析。推荐使用 zerolog 或 zap，它们默认或轻松支持 JSON 输出，字段名统一、时间戳标准、支持 level 字段，便于采集器过滤和索引。
示例（zerolog）：
import "github.com/rs/zerolog/log"
func main() {
log.Logger = log.With().Timestamp().Logger()
log.Info().Str("service", "api").Int("user_id", 1001).Msg("user login success")
}
// 输出：{"level":"info","time":"2024-06-15T10:23:45Z","service":"api","user_id":1001,"message":"user login success"}
- 确保
time字段为 RFC3339 格式（zerolog/zap 默认满足） - 避免在 message 中拼接结构化信息，全部走字段（如不用
Msgf("user %d logged in", id)，而用Int("user_id", id).Msg("user logged in")） - 添加固定字段如
service、env、host，方便多服务区分
避免日志丢失：同步写入 + 错误降级
日志写入文件或 stdout 是常见出口，但磁盘满、管道阻塞、stdout 被重定向失败都可能导致日志丢失。Go 应用需主动应对：
立即学习“go语言免费学习笔记（深入）”；
- 使用带缓冲的 writer（如
bufio.Writer）+ 定期 flush，平衡性能与实时性 - 对 stdout/stderr 写入加简单错误检查，失败时尝试 fallback 到本地文件（避免全丢）
- 若对接日志代理（如 Vector），优先走 TCP/HTTP 协议并配置超时与重试（zerolog 支持自定义
Writer，可封装带重试的 HTTP client）
注入请求/调用上下文（TraceID、RequestID）
集中查询时，靠时间范围查日志效率低。给每条日志打上唯一追踪 ID，就能串联整个请求链路。
常见做法：
- HTTP 中间件中生成
X-Request-ID或从上游透传，并存入 context - 用
zerolog.Ctx(r.Context())或zap.With(zap.String("trace_id", tid))将 ID 注入日志 - 全局 logger 可包装成带 context 的函数，避免每个地方手动传
这样一条 API 请求的日志，无论经过 handler、DB 层、cache 层，只要共享同一 context，日志里都有相同 request_id，Loki 或 Kibana 中直接搜 ID 即可聚合。
对接采集器：按协议暴露，不硬编码远端
Go 应用本身不直连 Elasticsearch 或 Loki。正确姿势是：只负责把结构化日志写到标准位置（stdout / 文件 / Unix socket），由外部采集器负责拉取或监听。
- 容器部署：直接
log.Printf或 zerolog 输出到 stdout，Docker/K8s 自动捕获，再由 Fluentd/Vector DaemonSet 收集 - 物理机部署：写入指定 JSON 文件（如
/var/log/myapp/app.json），配置 Vector 监听该文件尾部（filesource） - 需要主动推送：启用 Vector 的
http或tcpserver，Go 端用 HTTP POST 发送 JSON 日志（注意批量、压缩、认证）
关键原则：Go 进程不维护连接、不处理重试失败队列、不存储日志副本——这些交给专业采集器做更可靠。
