go日志归集需组合设计：k8s用daemonset监听/var/log/pods/，裸机集成zap推送，docker改用syslog/gelf驱动；禁用log.setoutput直连网络，须用带缓冲、重试、超时的结构化日志推送模块。
Go语言本身不提供跨平台日志归集能力，必须靠组合设计实现：采集端适配不同部署环境（容器/K8s/裸机），传输层统一协议（HTTP/gRPC/OTLP），分析端对接标准后端（Loki、ES、ClickHouse）。没有“开箱即用”的框架能覆盖全部场景，关键在选型时明确边界。
如何让日志从K8s Pod、Docker容器和物理机三端统一采集
根本矛盾在于日志来源形态不同：Pod内应用通常写stdout，裸机服务多写/var/log/app.log，而Docker容器可能挂载宿主机目录或使用json-file驱动。不能指望一个Agent吃遍所有路径。
- K8s环境优先用DaemonSet部署
fluent-bit或vector，监听/var/log/pods/下符号链接——这是Kubelet写入stdout的落盘位置，不是直接读容器内部 - 裸机服务需在Go程序中主动集成日志推送逻辑，比如用
zap搭配loki-client或自建HTTP endpoint，避免依赖文件轮转机制 - Docker部署时禁用
json-file驱动（默认），改用syslog或gelf驱动直发远端，否则docker logs命令会成为性能瓶颈 - 所有端都要加
host、service_name、env等固定字段，否则归集后无法区分来源
为什么直接用Go标准库log或log/slog做归集会出问题
它们只负责格式化输出，不处理传输、重试、背压、序列化这些归集必需环节。强行用log.SetOutput写网络连接，会在连接失败时阻塞整个应用goroutine。
-
log包无级别控制，log.Printf和log.Fatal混用会导致日志级别语义丢失，后续过滤失效 -
log/slog虽支持Handler，但内置slog.Handler不带异步缓冲，net/httpHandler里调用slog.Info仍会同步阻塞 - 结构化日志必须用
zap或zerolog，且要启用With预置字段（如zap.String("service", "api")），否则归集后字段缺失 - 别在日志里打敏感信息——
zap.String("token", token)这种写法一旦进Loki，就等于裸奔
Go程序内嵌日志推送模块的三个硬性约束
如果不想依赖外部Agent，必须自己实现推送，那以下三点绕不开：
- 必须用
chan *LogEntry做缓冲队列，容量设为1024或2048，防止日志暴增时panic；不能用无缓冲channel - 推送协程要带重试+退避，比如第一次失败后
time.Sleep(100 * time.Millisecond)，三次失败后丢弃（不存磁盘） - HTTP推送必须设
context.WithTimeout，超时时间建议≤3s；gRPC推送要配KeepaliveParams，否则长连接被LB断开后不重连 - 日志体大小限制：单条≤1MB（Loki限制），超长内容必须截断，否则整条被拒收
归集后分析阶段最容易被忽略的兼容性坑
日志进了Loki或ES，不代表能查——字段类型错位、时间戳解析失败、标签键名冲突，这三个问题占线上排查耗时的70%以上。
- Loki要求
timestamp字段必须是Unix纳秒整数，Go里得用time.Now().UnixNano()，用Format("2006-01-02T15:04:05Z")会解析失败 - ES索引mapping若未预设
status_code为integer类型，后续status_code > 400查询会返回空 - 多个服务共用同一
job标签名（如都叫go-app），Loki里rate({job="go-app"}[5m])就失去服务维度区分能力 - 别信“自动发现schema”——Loki不推断字段类型，ES的dynamic mapping容易把数字当字符串建索引
真正难的不是把日志从A送到B，而是确保每条日志在B端能被准确识别、过滤、聚合。字段命名规范、时间戳精度、错误容忍策略，这些细节定稿前没对齐，后期补救成本远高于初期设计投入。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
