thanos是独立部署的云原生监控组件，非go sdk；go服务只需合规暴露/metrics端点、合理设计label，并通过prometheus抓取+thanos-sidecar上传至对象存储，由thanos-query统一聚合查询。
Thanos 不是 Go 语言的库，也不是直接“集成”进 Go 应用代码里的 SDK；它是一套独立部署、基于 gRPC/HTTP 协议通信的云原生监控组件。你在 Golang 项目里写业务逻辑时，不需要 import thanos 包、也不调用 thanos.Store() 这类函数——它和你的 Go 服务之间是松耦合的基础设施层关系。
真正要做的，是让 Go 服务暴露符合 Prometheus 规范的指标，并确保这些指标能被 Prometheus 抓取，再经由 thanos-sidecar 推送到对象存储，最终通过 thanos-query 统一查询。整个链路里，Go 服务只负责「产出生效指标」这一个环节。
Go 服务必须暴露 /metrics 端点且格式合规
Prometheus 只认文本格式的指标暴露，不是 JSON，也不是自定义协议。Golang 服务若用 promhttp，必须确保：
• 返回 Content-Type 是 text/plain; version=0.0.4; charset=utf-8（不是 application/json）
• 每行以 # 开头的是注释或类型声明，如 # TYPE http_requests_total counter
• 指标行格式为 metric_name{label="value"} value timestamp，timestamp 可省略
• 所有 label 值必须是双引号包裹的字符串，不能含空格或非法字符（如 service="order-api" ✅，service=order-api ❌）
http.Handle("/metrics", promhttp.Handler())
如果用了 go.opentelemetry.io/otel/exporters/prometheus，注意它默认输出的是 OpenMetrics 格式（带 # TYPE ... 和 # UNIT），而老版本 Prometheus（
Label 设计直接影响 Thanos 查询效率和存储膨胀
thanos-store-gateway 和 thanos-compactor 对高基数 label 极其敏感。Go 服务里若把 user_id、request_id、ip 直接打成 label，会导致时间线爆炸，对象存储 Block 数量激增，thanos-query 聚合变慢甚至 OOM。
• 必须收敛 label 维度：只保留聚合有意义的维度，如 env、service、method、status_code
• 避免动态值 label：用 path="/api/v1/order" 而非 path="/api/v1/order/12345"
• 若需追踪单次请求，走 tracing（Jaeger/OTLP），别塞进 metrics
• 可在 Go 初始化时注册静态 label：promauto.NewCounterVec(prometheus.CounterOpts{...}, []string{"env", "service", "method"})
错误示例（会拖垮 Thanos）：
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
counter.WithLabelValues(r.URL.Query().Get("uid"), r.RemoteAddr)
正确做法：
counter.WithLabelValues(os.Getenv("ENV"), "order-api", r.Method)
Thanos Sidecar 与 Go 服务共 Pod 时的网络配置要点
thanos-sidecar 容器和 Go 服务容器同属一个 Pod，共享 localhost 网络命名空间，但默认不自动打通端口。常见问题：
• --prometheus.url=http://localhost:9090 失败 → Go 服务没监听 0.0.0.0:9090，只监听 127.0.0.1:9090（Docker 默认 bind 到 loopback）
• Sidecar 启动报错 connection refused → Go 服务启动慢于 Sidecar，Sidecar 默认不重试（需加 --reloader.interval=30s 或用 initContainer 等待）
• /metrics 路径被拦截 → Go 服务用了反向代理或中间件，导致 /metrics 返回 404 或重定向（Sidecar 不跟 redirect）
检查方式：
kubectl exec -it <pod-name> -c thanos-sidecar -- curl -v http://localhost:8080/metrics</pod-name>（假设 Go 服务监听 8080）
Query 层聚合跨集群 Go 服务指标时的 label 冲突风险
多个 Kubernetes 集群里部署相同的 Go 服务（如都叫 payment-service），若未注入唯一标识，thanos-query 会把它们的指标混在一起，无法区分来源集群。
• 在 Prometheus 的 scrape_configs 中，给每个 job 加 relabel_configs 注入集群名：
replacement: "prod-us-west"
target_label: cluster
• Go 服务本身无需改代码，但部署 YAML 里应透传该 label（例如通过环境变量 + relabel）
• Grafana 查询时必须带上 {cluster="prod-us-west"}，否则查到的是所有集群叠加结果
这点容易被忽略：你看到的“全局视图”，其实是靠 label 隔离出来的，不是自动智能识别。
Thanos 的“全局”是人工 label 维护出来的全局，不是魔法。漏掉集群维度 label，等于把三张不同医院的体检报告叠在一起看——数据都在，但没法分清谁是谁的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
