Go微服务中需用zap+OpenTelemetry在中间件提取trace_id/span_id并作为结构化字段注入日志，确保单行JSON输出、Filebeat启用keys_under_root、ES中trace_id映射为keyword类型。

Go 微服务里怎么让日志带上 trace_id 和 span_id

不加 trace 上下文，ELK 里查日志就是一堆散点，根本串不起来。Go 标准库 log 不带上下文，必须用支持 OpenTracing 或 OpenTelemetry 的日志库，或者手动把 trace 信息塞进日志字段。

• 推荐用 go.opentelemetry.io/otel/log（OTel 日志提案已进入实验阶段）或更现实的方案：用 zap + opentelemetry-go 注入 context
• 在 HTTP 中间件或 gRPC UnaryInterceptor 里从 context.Context 提取 trace.SpanFromContext(ctx)，拿到 span.SpanContext().TraceID() 和 span.SpanContext().SpanID()
• 把这两个 ID 作为结构化字段传给 zap.Logger.With()，比如 logger.With(zap.String("trace_id", tid.String()), zap.String("span_id", sid.String()))
• 别用字符串拼接日志（如 fmt.Sprintf("trace:%s %s", tid, msg)），会丢结构、难过滤、占空间

Logstash 或 Filebeat 怎么识别 Go 服务输出的 JSON 日志

Go 服务输出的 JSON 日志如果没对齐 Logstash / Filebeat 的期待格式，就会被当纯文本吞掉，@timestamp 乱、trace_id 变成嵌套字符串、甚至整条日志进 message 字段里出不来。

• 确保 Go 日志库输出的是「单行 JSON」——每条日志严格一个 JSON object，不能换行、不能有前导空格，否则 Filebeat 的 json 解码器会失败
• Logstash 里用 filter { json { source => "message" } }，但前提是 message 字段确实是合法 JSON；如果原始日志已经由 Filebeat 解析过，就别重复解析，直接用 processors 提取字段
• Filebeat 配置中必须启用 json.keys_under_root: true 和 json.overwrite_keys: true，否则 trace_id 会藏在 json.trace_id 下，Kibana 里搜不到
• 测试方法：用 filebeat test output + filebeat -e -d "publish" 看实际发出去的 event 结构是否含平级 trace_id 字段

ELK 里 trace_id 搜不到？检查这三个地方

Kibana 里输入 trace_id: "0123456789abcdef0123456789abcdef" 没结果，大概率不是 Go 发得不对，而是索引映射或查询方式卡住了。

Colly Golang Web Scraper and Crawler Framework

Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。

下载

• Elasticsearch 索引模板里，trace_id 字段类型必须是 keyword，不是 text —— 否则会被分词，精确匹配失效
• Kibana 查询语言默认走全文检索，要查精确值得加引号，或改用 trace_id.keyword: "..."（如果字段映射没设 fields: { keyword: { type: keyword } } 就没这个子字段）
• Logstash 如果用了 date filter 做时间解析，但 Go 日志里时间字段名不是 @timestamp 或 time，会导致事件时间戳为 0，被 ES 丢进 .kibana 索引或拒收

为什么 Span 之间的时间差在 Kibana 里对不上

同一个 trace 下不同服务的日志时间戳差几秒，不是网络延迟问题，而是各服务本地时钟没同步，或者日志时间字段没统一用 trace 开始时间做基准。

立即学习“go语言免费学习笔记（深入）”；

• Go 服务里别用 time.Now() 打日志时间，要用 span 的 StartSpanOptions{StartTime: ...} 记录起点，再基于它算相对时间（如 elapsed_ms）
• 所有服务必须 NTP 同步，误差控制在 50ms 内，否则 span.duration 在 UI 上错位严重
• ES 索引的 @timestamp 字段应来自日志中的 time 字段（ISO8601 格式），而不是 Logstash 接收到事件的时间 —— 后者反映的是日志落地延迟，不是业务发生时刻

事情说清了就结束。最常漏的是 Filebeat 的 json.keys_under_root 和 ES 字段 mapping 类型，调通前先抓一条原始日志，从 Filebeat 输出一直看到 Kibana Discover 里的字段层级，比看文档快得多。