openobserve 可直接替代 elk+prometheus+jaeger，但 golang 微服务接入需正确配置 otelhttp/otelgrpc 包装、唯一 service.name、匹配的 otlp endpoint（如 http://localhost:5080/v1/traces），并避免冗余 otel-collector。
OpenObserve 能直接替代 ELK + Prometheus + Jaeger 的组合，但 Golang 微服务接入时，关键不是“能不能连”，而是otelhttp、otelgrpc 和 resource 配置稍有偏差，trace 就会断在第一个 hop —— 这是 90% 新手卡住的地方。
用 otelhttp 和 otelgrpc 包裹客户端与服务端入口
OpenObserve 原生兼容 OpenTelemetry 协议（OTLP HTTP/gRPC），但 Golang 中必须显式包装：不包裹 http.Handler 或 grpc.Server，span 就不会自动注入 context；不包裹 http.Client 或 grpc.Dial，下游服务就收不到 traceparent header。
-
http.ServeMux必须用otelhttp.NewHandler封装，不能只给 handler 加中间件 -
grpc.Server初始化时要传入otelgrpc.UnaryServerInterceptor()和otelgrpc.StreamServerInterceptor() - 调用下游 gRPC 时，
grpc.Dial必须带grpc.WithUnaryInterceptor(otelgrpc.UnaryClientInterceptor()) - HTTP 客户端请求需用
otelhttp.DefaultClient.Do(req)，而非原生http.DefaultClient.Do(req)
resource 必须包含 service.name 且全局唯一
OpenObserve 按 service.name 聚合 traces 和 metrics，如果多个微服务共用同一个 name（比如都写 "backend"），它们的 trace 会混在一起，链路图完全不可读。更糟的是，若漏设 service.name，OpenObserve 默认归为 unknown_service:go，所有服务全挤在一个桶里。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须通过
resource.WithAttributes(semconv.ServiceNameKey.String("order-service"))显式声明 - 建议从环境变量读取：
os.Getenv("SERVICE_NAME")，避免硬编码 - 不要依赖
semconv.ServiceNamespaceKey或ServiceVersionKey来区分服务——OpenObserve 当前版本（v0.12+）主要靠service.name做 service map
OTLP exporter endpoint 指向 OpenObserve 且协议匹配
常见错误是本地跑着 OpenObserve（默认监听 http://localhost:5080/v1/traces），但 Golang 程序却往 http://localhost:4318/v1/traces（标准 OTLP HTTP 端口）发数据——OpenObserve 不监听 4318，也不转发到该端口。
- HTTP exporter endpoint 必须是
http://<openobserve-host>:5080/v1/traces</openobserve-host>（日志和指标同理，路径分别为/v1/logs、/v1/metrics） - 若用 gRPC exporter，则 endpoint 是
<openobserve-host>:5080</openobserve-host>，且 OpenObserve 启动时需加--grpc-port=5080参数（默认只开 HTTP） - 确认 OpenObserve 日志里出现
OTLP receiver started，否则 exporter 实际没生效
本地调试时 trace 不显示？先查 otel-collector 是否多余
OpenObserve 自带 OTLP 接收器，Golang 直连即可。很多团队习惯性加一层 otel-collector，结果配置错 export endpoint（指向 collector 而非 OpenObserve），或 collector 自身没配好 pipeline，反而成了单点故障和延迟源。
- 开发阶段跳过 collector，Golang 程序直连 OpenObserve，减少中间环节
- 只有需要采样、过滤、重写 attribute 时才引入 collector，且它的 exporter 必须指向
http://openobserve:5080/v1/traces - 检查 OpenObserve UI 的
Settings > Logs页面，看是否有近期traces写入记录；没有则问题一定出在 client 端或网络通路
真正麻烦的从来不是部署 OpenObserve，而是每个 Golang 服务里那几行 OTel 初始化代码——少一个 WithResource，漏一个 UnaryClientInterceptor，整个链路就断成碎片。调试时别急着翻文档，先 curl 一下 http://openobserve:5080/healthz，再看自己服务启动日志里有没有 OTLP exporter initialized，这两步能筛掉 80% 的连接类问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
