Zap 输出 JSON 日志需禁用颜色与缩进，改用 zapcore.NewJSONEncoder；固化 service_name、trace_id、host、timestamp 字段；trace_id 应从 HTTP header 或 OTel context 提取；避免 defer 中 sync；弃用 Filebeat 文件采集，改用异步 OTLP gRPC 上报至 OpenTelemetry Collector。
zap 输出 JSON 日志必须禁用颜色和缩进
默认 zap.NewProduction() 用的是 ConsoleEncoder，带 ANSI 颜色和多行缩进，采集器（如 Fluent Bit、Promtail）会把换行当多条日志切碎，导致字段丢失或解析失败。
- 务必改用
zapcore.NewJSONEncoder，并显式关闭EncodeLevel的颜色、EncodeTime的 ISO8601 格式需对齐后端要求（比如 Loki 要 RFC3339） - 关键字段必须固化：至少含
service_name、trace_id、host、timestamp；trace_id建议从 HTTP header（X-Trace-ID）或 OpenTelemetry context 提取，而非随机生成 - 避免在
defer中调用阻塞日志，比如logger.Sync()不该放在 handler 结束处——它会等刷盘，拖慢响应
日志上报不该依赖 Filebeat 拉取本地文件
写文件再让 Filebeat 读，时间戳易错乱（内核缓冲、采集延迟）、上下文丢失（goroutine 信息、HTTP 请求 body 等无法附带），且部署耦合：每台机器都要配 agent、路径权限、logrotate。
- 更可控的做法是服务内嵌异步上报客户端，用
otlpgrpc.NewClient()直连 OpenTelemetry Collector（otelcol） - 上报必须走独立 goroutine + 内存 channel（建议 buffer size
1024），满时用select { case ch 丢旧日志，绝不阻塞业务 - grpc 连接要封装指数退避重连：初始间隔
100ms，上限5s，失败时缓存最近100条日志防丢失
OpenTelemetry Collector 配置容易漏掉的关键项
自己手写接收服务投入大、稳定性差，otelcol 是事实标准，但配置稍有偏差就收不到日志。
-
receivers.otlp.protocols.grpc必须显式启用，否则 grpc 流被静默拒绝 - 对接 Loki 时，
exporters.loki.endpoint必须带完整路径/loki/api/v1/push，漏掉就返回404 - 对接 Elasticsearch 时，默认字段扁平化：
trace_id会变成attributes_trace_id，Kibana 查询得写attributes_trace_id: "xxx"，不是直接trace_id
trace_id 关联全链路日志的前提是透传一致
光在日志里打 trace_id 不够，它必须和 OpenTelemetry 的 span 生命周期对齐，否则 Kibana 或 Grafana 里搜不到关联日志。
立即学习“go语言免费学习笔记（深入）”；
- HTTP 中间件或 gRPC UnaryInterceptor 是注入点，从 header 提取
X-Trace-ID并塞进 context，后续所有logger.With(...)都应基于该 context 构建 - 避免跨 goroutine 丢失 context：启动新 goroutine 时用
ctx = context.WithValue(ctx, key, val)显式传递，别靠闭包捕获 - 如果用了 go-zero，它的
logx默认已集成 trace_id 和 service_name，但需确认LogConf.Encoding == "json"且未被中间件覆盖
实际跑通的关键不在组件堆叠，而在每个环节的字段对齐和错误兜底：日志字段命名是否全局统一、上报通道是否真异步、otelcol 是否真收到原始结构、trace_id 是否从入口到出口全程不变。漏掉任一环，查问题时就会卡在“日志有，但串不起来”。
