go连接elasticsearch应选用olivere/elastic/v7（es 7.x）或v8（es 8.x），需配置tls、鉴权、超时及自定义http客户端；日志写入须批量、结构统一、带日期索引；查trace_id全链路日志应跨索引term查询并排序；kibana不可见日志多因时间戳格式、索引模式或time filter问题。
Go 连接 Elasticsearch 用什么客户端？别选错
官方推荐且维护活跃的是 olivere/elastic/v7（对应 ES 7.x）或 olivere/elastic/v8（ES 8.x）。spf13/cobra 或 go-elasticsearch 官方客户端也可用，但 olivere/elastic 的 DSL 封装更贴近日常查询习惯，错误处理也更明确。注意：ES 8 默认启用 TLS 和基于角色的鉴权，连接时必须配 SetScheme("https") 和 SetHttpClient，否则会卡在 401 Unauthorized 或直接 timeout。
常见错误现象：elastic: Error 401 (Unauthorized) —— 多半是没传 BasicAuth，或者 ES 启用了安全模块但 Go 客户端没配证书信任链；context deadline exceeded —— 很可能是没设 SetHealthcheck(false)（尤其在 K8s initContainer 中健康检查失败导致启动阻塞）。
实操建议：
Elasticsearch 9.4.1 Linux 版本现已开放下载，这是官方最新发布的分布式搜索与分析引擎。Linux 版本全面支持 x86_64 与 aarch64 架构，提供 .tar.gz、.deb 及 .rpm 多种安装包格式，可灵活适配 Ubuntu、CentOS、Debian 等主流发行版。该版本延续了 9.4 系列的核心特性，包括原生 Prometheus 支持、正式版 Elast
- ES 7.x 用
go get github.com/olivere/elastic/v7，ES 8.x 必须用v8分支，二者 API 不兼容 - 初始化 client 时显式设置超时：
SetURL("https://es:9200").SetSniff(false).SetHealthcheck(false).SetBasicAuth("elastic", "xxx") - 若用自签名证书，需构造自定义
http.Client并传入SetHttpClient，不能只靠InsecureSkipVerify: true
日志写入要批量、带时间戳、避免 mapping conflict
微服务日志通常由多个服务并发写入同一 index，比如 logs-2024.06.15。直接用 Index API 单条写入吞吐极低，且易触发 ES 的 bulk queue 拒绝；更麻烦的是，不同服务字段类型不一致（例如 service_name 有时是 string，有时是 object），会导致 mapping conflict 报错：illegal_argument_exception: mapper [service_name] cannot be changed from type [text] to [object]。
实操建议：
- 用
bulkProcessor批量提交，设置Workers(4)、FlushInterval(1s)、FlushBytes(5e6)（5MB），避免小包频繁请求 - 日志结构必须统一：顶层字段如
timestamp（time.Time）、service_name（string）、level（keyword）、message（text）、trace_id（keyword）——所有服务发日志前先做结构体校验 - index name 必须带日期后缀，用
logs-{yyyy.MM.dd}格式，并提前创建 ILM policy 或 template，确保message是text、trace_id是keyword，禁止 ES 自动 mapping
聚合分析怎么查 trace_id 关联的全链路日志？
微服务排查最常见需求：给一个 trace_id，查它在所有服务中产生的全部日志，并按时间排序。不能只靠 match 查询，因为要跨多个 index（比如 logs-2024.06.14 和 logs-2024.06.15），还得控制返回字段、排序、高亮。
实操建议：
- 用
Search+MultiSearch要谨慎——实际应直接查通配符 index：logs-2024.06.*，ES 7+ 支持跨 index 查询，比手动拆 query 更稳 - query 用
term而非match查trace_id（keyword 类型），避免分词干扰 - 加
Sort("timestamp").SortOrder("asc")，并用SourceContext().Include("service_name", "level", "message")控制返回字段，减少网络开销 - 如果要高亮
message中的关键词，必须在 mapping 中开启"highlight": {"require_field_match": false}，否则默认只高亮匹配字段
为什么 Kibana 看不到新日志？排查三步走
日志写进去了，但 Kibana Discover 里刷不出来，90% 是 time filter 或 index pattern 匹配问题，不是代码 bug。
实操建议：
- 先 curl 查 ES：
curl -XGET 'http://localhost:9200/logs-2024.06.15/_search?q=trace_id:abc123'，确认数据真实存在且timestamp字段值是 ISO8601 格式（如"2024-06-15T14:23:01.123Z"）——Go 里必须用time.RFC3339Nano格式序列化 - Kibana 中检查 index pattern 是否已刷新：Settings → Index Patterns → 选中 logs-* → Reload field list；若没看到
timestamp字段，说明 mapping 没生效或字段名拼错 - 确认 Kibana time filter 范围是否覆盖日志时间戳——默认是最近 15 分钟，而你的日志可能落在昨天，得手动调宽
真正难搞的是 timestamp 时区和精度：Go 的 time.Now().UTC() 写入后，ES 默认按 UTC 解析，但 Kibana 显示时会转成本地时区。如果服务日志时间戳没强制设为 UTC，或者用了 UnixMilli() 却没映射成 date 类型，后续所有聚合都会错乱。
