零码改造!Go 语言应用上报观测云完整最佳实践

背景

Go 应用接入链路追踪时,常见方案是在代码中手动引入 OpenTelemetry SDK,并为 HTTP、gRPC、数据库、Redis、MongoDB 等组件逐一添加 instrumentation。这种方式可控性强,但对已有项目改造成本较高,也容易出现埋点不完整、上下文传播遗漏、依赖版本不兼容等问题。

loongsuite-go 是阿里巴巴开源的 Go 编译时自动插桩工具。它在 go build 阶段将 OpenTelemetry 埋点逻辑注入到应用中,应用运行后通过标准 OTEL 协议上报链路数据。对于希望快速把 Go 应用接入观测云的场景,loongsuite-go 的优势是:

  • 对业务代码侵入小,HTTP、gRPC、MySQL、Redis、MongoDB 等常见组件可以通过编译时插桩自动生成 span。
  • 使用 OpenTelemetry 标准协议,上报端可以直接对接观测云 DataKit 的 OTEL 接收端。
  • 适合容器化交付,把 otel 编译工具放进构建镜像,运行镜像只保留最终二进制。
  • 可以结合 JSON 日志,把 trace_id、span_id 写入日志字段,便于在观测云中实现日志和链路关联。

本文以 go-demo1 和 go-demo2 为例:

  • go-demo1:HTTP 服务,提供 POST /createOrder,通过 gRPC 调用 go-demo2。
  • go-demo2:gRPC 服务,处理支付逻辑,并调用 MySQL、Redis、MongoDB。
  • 两个服务均使用 loongsuite-go 编译时插桩。
  • 链路通过 OTEL gRPC 上报到主机上的 DataKit:192.168.0.245:4317。

前置条件

1. 使用 loongsuite-go 编译时插桩

loongsuite-go 的关键不是运行时代理,而是构建阶段使用:

otel go build -o app .

当前项目为避免构建时远程下载失败,提前把 otel-linux-amd64 和 install.sh 文件放在项目根目录。

install.sh 只负责把本地 otel-linux-amd64 安装到 /usr/local/bin/otel:

#!/bin/bash
set -e

install() {
    SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
    EXECUTABLE="${1:-${SCRIPT_DIR}/otel-linux-amd64}"
    INSTALL_DIR="${INSTALL_DIR:-/usr/local/bin}"

    if [ ! -f "$EXECUTABLE" ]; then
        echo "Executable $EXECUTABLE not found"
        exit 1
    fi

    echo "Installing $EXECUTABLE to $INSTALL_DIR"
    mkdir -p "$INSTALL_DIR"
    cp "$EXECUTABLE" "$INSTALL_DIR/otel"
    chmod +x "$INSTALL_DIR/otel"
}

install "$@"

这样 Docker 构建时不会再访问 GitHub 下载 otel 工具,适合网络不稳定或内网环境。

2. Dockerfile 推荐写法

以 go-demo2 为例:

FROM golang:1.26 AS builder

WORKDIR /src
ARG GOPROXY=https://goproxy.cn,direct

COPY go-demo2/go.mod ./
RUN --mount=type=cache,target=/go/pkg/mod \
    GOPROXY="${GOPROXY}" go mod download

COPY install.sh otel-linux-amd64 /tmp/
RUN chmod +x /tmp/install.sh && /tmp/install.sh /tmp/otel-linux-amd64

COPY go-demo2/ .
RUN --mount=type=cache,target=/go/pkg/mod \
    --mount=type=cache,target=/root/.cache/go-build \
    GOPROXY="${GOPROXY}" OTELTOOL_VERBOSE=true otel go build -o /out/go-demo2 .

FROM debian:bookworm-slim

WORKDIR /app
COPY --from=builder /out/go-demo2 /app/go-demo2

EXPOSE 9090
ENTRYPOINT ["/app/go-demo2"]

实践建议:

  • 构建阶段使用 golang 镜像,运行阶段使用更小的 debian:bookworm-slim。
  • go mod download 和 go build 使用 BuildKit cache,加快重复构建。
  • 使用 OTELTOOL_VERBOSE=true,便于确认哪些规则参与了插桩。
  • 生产环境建议固定 Go 版本、依赖版本和 otel-linux-amd64 版本,避免构建结果漂移。

3. 配置服务名和上报地址

每个服务必须设置独立的 OTEL_SERVICE_NAME,否则观测云中服务名会混乱。

  OTEL_SERVICE_NAME: "go-demo2"
  OTEL_EXPORTER_OTLP_ENDPOINT: "http://192.168.0.245:4317"
  OTEL_EXPORTER_OTLP_INSECURE: true
  OTEL_EXPORTER_OTLP_PROTOCOL: "grpc"
  OTEL_EXPORTER_OTLP_TRACES_PROTOCOL: "grpc"
  OTEL_TRACE_SAMPLER: "1.0"
    - name: OTEL_SERVICE_NAME
      value: xxxx
    - name: OTEL_EXPORTER_OTLP_ENDPOINT
      value: http://datakit-service.datakit:4317
    - name: OTEL_EXPORTER_OTLP_PROTOCOL
      value: grpc

4. Json日志与 trace_id 关联

loongsuite-go 可能会对日志做自动 trace 注入,输出类似:

trace_id=... span_id=...order_id=...

如果应用使用 JSON 日志,不建议依赖这种文本前缀式注入,因为它可能破坏 JSON 格式。更推荐在日志代码中从 context.Context 获取当前 span,再把 trace_id 和 span_id 写成 JSON 字段。

示例:

import (
    "context"
    "log/slog"
    "os"

    "go.opentelemetry.io/otel/trace"
)

var logger = slog.New(slog.NewJSONHandler(os.Stdout, nil))

func logAttrs(ctx context.Context, level slog.Level, message string, attrs ...slog.Attr) {
    spanContext := trace.SpanContextFromContext(ctx)
    if spanContext.IsValid() {
        attrs = append(attrs,
            slog.String("trace_id", spanContext.TraceID().String()),
            slog.String("span_id", spanContext.SpanID().String()),
        )
    }
    logger.LogAttrs(ctx, level, message, attrs...)
}

业务日志:

logAttrs(
    ctx,
    slog.LevelInfo,
    "支付完成",
    slog.String("order_id", req.OrderID),
    slog.String("pay_id", payID),
)

输出示例:

{
  "time": "2026-07-20 02:32:38.927",
  "level": "INFO",
  "msg": "支付完成",
  "order_id": "order-10001",
  "pay_id": "pay-82612a021dc38219",
  "trace_id": "d28d5c26510ce9d62827e5c3dcab2786",
  "span_id": "f73228669d3ccb53"
}

5. Pipeline

登录 观测云控制台,点击「日志」 -「Pipelines」 -「新建Pipeline」,按下图配置Pipeline。

解析规则内容如下:

json_data = load_json(_)
add_key(time,json_data["time"])
add_key(status,json_data["level"])
add_key(trace_id,json_data["trace_id"])
add_key(span_id,json_data["span_id"])
default_time(time,"Asia/Shanghai")

6. 效果展示

总结

Go 应用使用 loongsuite-go 接入观测云时,推荐采用以下实践:

  • 使用 otel go build 做编译时自动插桩。
  • 通过 OTEL gRPC 上报到 DataKit。
  • 每个服务明确设置 OTEL_SERVICE_NAME。
  • 容器内上报地址使用可达的宿主机 IP,而不是 127.0.0.1。
  • 日志使用 JSON 格式,并把 trace_id、span_id 作为结构化字段输出。
  • 构建阶段使用本地 otel-linux-amd64,减少外网依赖,提高构建稳定性。

相关推荐

技术实战:观测云告警到飞书群并精准@相关人

本文介绍观测云如何通过 Webhook 将告警推送至 DataFlux Func,完成消息格式转换并 @责任人,实现精准提醒。

观测云的博客 346

基于 OpenTelemetry 实现 LangChain 观测云全链路可观测

文章介绍基于 OpenTelemetry 为 LangChain 应用构建 Zero-Code 全链路可观测方案,无需修改业务代码即可自动采集工作流、Prompt 与模型调用链路,帮助快速定位性能瓶颈与故障,并分析模型输入输出及 Token 消耗。

观测云的博客 343

Spring AI + Spring AI Alibaba 接入观测云最佳实践

文章介绍 Spring AI 与 Spring AI Alibaba 应用接入观测云的实践方案,通过 OpenTelemetry 自动采集 Agent、LLM 与 Tool 调用链路,实现性能、Token、模型及工具调用的统一观测,提升 AI 应用故障排查与性能优化效率。

观测云的博客 462

观测云 Agent 输出质量评估上线!智能体答得好不好别再靠感觉

观测云上线Agent质量评估系统,支持Prompt Eval和Schema Eval,自动检测输出质量与结构,提升智能化服务可靠性。

观测云的博客 665

观测云产品更新 | Agent 监测、故障中心、应用性能监测、日志、基础设施等

观测云新增AI API计费、告警策略优化、Agent Skills提升、故障作战室、LangChain兼容、性能监测与日志优化等功能。

观测云的博客 361

AI时代的用户访问监测:观测云带你身临其境体验用户与前端UI交互旅程

观测云 RUM 通过真实用户访问数据呈现应用整体体验情况。在应用列表和分析看板中,团队可以查看用户访问量、页面性能、错误情况等关键指标,判断问题影响范围。

观测云的博客 297

观测云全新上线「全局工作区」:进一步统一数据查询

观测云全局工作区上线,支持多模块Tab切换,提升故障排查效率。

观测云的博客 412

Fastjson 高危 RCE(CVE-2026-16723):如何用观测云快速发现并完成修复

本文针对 Fastjson 高危 RCE 漏洞 CVE‑2026‑16723,剖析其影响与利用条件,指出 Maven 静态排查的局限。观测云依托 ddtrace 运行时数据,完成漏洞检测定位告警修复闭环,提供升级、应急防护、迁移 fastjson2 处置方案。

观测云的博客 449

观测云应用性能监测 :帮助团队定位性能瓶颈

观测云 APM 将应用运行过程中的关键性能信息连接起来,帮助团队从发现异常服务,到定位请求链路,再到深入分析代码性能,逐步还原问题发生的过程。

观测云的博客 354

基于 DataFlux Func 构建 Vibe Coding 运行底座

DataFlux Func 可以作为 Vibe Coding 的运行底座。Func 本身提供脚本管理、函数执行、定时任务、函数 API、连接器、环境变量和运行日志等能力;MCP 则让 AI Agent 能够以标准化方式连接 Func,把“写代码”和“运行代码”的链路打通。这套实践不限定某一个 AI 客户端。只要客户端支持 MCP 或具备等价的工具接入能力,例如 Cursor、Claude Desktop、OpenCode、Codex 等,都可以按相同思路接入 Func。

观测云的博客 303

AI时代日志分析:观测云让你从海量日志中找到关键线索

观测云日志围绕日志采集、处理、存储、查询分析以及异常定位等场景,将分散在不同来源的日志信息集中管理。通过 Pipeline 对日志进行解析和结构化处理,通过 GuanceDB 3.1 支撑海量数据存储与分析,帮助团队将原始日志转化为可查询、可分析的数据基础。

观测云的博客 198

AI时代基础设施监控:观测云让你的系统指标清晰可见

通过统一的数据视角,将基础设施、应用和业务信息连接起来,让工程团队从发现问题、分析原因到定位影响范围,形成更加完整的问题排查路径。

观测云的博客 182

观测云会话重放:把玩家游戏中的那一秒卡顿完整回放给研发团队

观测云 Browser SDK 3.3.7 WebGL / WebGL2 Session Replay,让游戏画面、用户操作、错误和性能数据回到同一条时间轴。

观测云的博客 335

观测云集成飞书 SSO 最佳实践

本文介绍如何基于 OIDC 协议,通过飞书集成平台、飞书开放平台两大渠道对接观测云实现 SSO 单点登录的完整方案,清晰区分了两大飞书平台的能力差异、适用场景与配置规范,形成了一套完整、可落地的跨系统身份集成流程。

观测云的博客 217

观测云 AI Agent Teams 安全能力漏扫与修复实践场景

一句话标准:这个 Agent 不能只是“会扫”,而要像一名资深 AppSec 工程师一样,知道问题在哪里、为什么危险、先修哪个、怎么安全地修、修完如何证明真的修好了漏洞扫描不是终点,修复闭环才是安全能力真正落地的标志。观测云 AI Agent Teams 的最佳实践,是让 Agent 在安全团队、研发团队和运维团队之间承担“证据整理、优先级判断、修复建议、协同跟踪、复测复盘”的工作,同时把扫描只读、修复审批、官方依据、脱敏输出和证据关闭作为治理底线。

观测云的博客 381

观测云产品更新 | Agent Teams、Agent 监测、日志、基础设施等

本期更新主要为观测云更新和 DataKit 更新。

观测云的博客 366

观测云 AI 智能体为什么能精准排查并修复故障?把排障经验写进 Runbook

立刻在观测云免费开通 Obsy AI 智能服务,体验 Obsy AI Copilot 和 AI Agent Teams 强大的故障排查能力;开通观测 Agent Teams,让 观测 AI 智能体团队 7×24 安全的在你生产环境里跑起来,

观测云的博客 543

万卡级算力集群 GPU 监控:基于观测云全链路观测实践

本文介绍如何通过观测云监控万卡级算力集群 GPU,与应用性能 Trace、业务日志、基础设施指标在统一平台中实现全栈关联与跨层下钻,真正构建起从硬件到业务的完整观测链路。

观测云的博客 489

观测云基于 AI Agent Teams 能力的场景实践

本文通过三个场景实践,介绍观测云 AI Agent Teams 如何将可观测性数据、智能分析与自动化运维能力深度结合,帮助用户更快发现问题、定位问题并解决问题。

观测云的博客 581

观测云产品更新 | Agent Teams、Agent 监测、统一目录、基础设施、应用性能监测等

观测云新增企业微信消息渠道、任务管理优化、容器化部署、Agent监测升级、分析看板改进、时间轴视图、联动变更、拓扑筛选、日志优化、性能监测等功能。

观测云的博客 238

观测云入选 OpenTelemetry 官方 Vendors

观测云面向 OpenTelemetry 构建的原生接入与可观测能力,正式进入全球 OpenTelemetry 生态视野。

观测云的博客 453

当 Agent 写代码快过人类审查:软件工程的信任链必须重建

下一阶段的软件工程,不是让人类追着每一行 AI 代码跑,而是让 Agent 提交证据,并让线上系统持续产生可用于纠错的信号。

观测云的博客 357

带你用观测 AI 智能体:自主分析与修复故障

观测云通过 Guance AI Agent Teams,为业务调查与恢复提供了统一的数据基座、受控的执行边界、结构化的证据输出。

观测云的博客 221

观测云正式支持 Qoder 可观测

在「观测云控制台」-「Agent 监测」,点击右上角「接入 Agent」,选择「Qoder」即可快速接入。

观测云的博客 296

带你用观测 AI 智能体:接入你的工作群聊

观测云通过 Guance AI Agent Teams,为生产侧的可观测 Agent 提供了统一的数据基座:日志、指标、Trace、事件,全部统一采集、统一标签、统一存储。

观测云的博客 204

观测云正式支持 Claude Code 可观测

在「观测云控制台」-「Agent 监测」,点击右上角「接入 Agent」,选择「Claude Code」即可快速接入。

观测云的博客 337

观测云产品更新 | Obsy AI、Agent Teams、Agent 监测、安全监测、故障中心等

本期更新主要为观测云更新和 DataKit 更新。详情见官网文档:https://docs.guance.com/release-notes/

观测云的博客 233

带你用观测 AI 智能体:与本地 Coding Agent 协作排障

观测云通过 Guance AI Agent Teams,为生产侧的可观测 Agent 提供了统一的数据基座日志、指标、Trace、事件,全部统一采集、统一标签、统一存储。

观测云的博客 383

观测云 6 月产品升级报告 | 观测 AI Agent Teams 全面升级、观测云安全功能强化、拨测与跨空间协同能力增强

2026 年 6 月,我们收到不少用户反馈。我们把这些声音,一条条变成了产品更新,以下是本月最值得关注的 9 大升级亮点,每一个都为了让你的观测体验更顺滑、更贴合实际业务场景。

观测云的博客 368

观测 AI 智能体入职指南

跟着步骤配置,5 分钟后,你的第一位可观测智能体队友即可正式上岗!

观测云的博客 433
上一篇: 观测云产品更新 | Agent Teams、Agent 监测、日志、基础设施等
下一篇: 观测云 AI Agent Teams 安全能力漏扫与修复实践场景
观测云
观测云 上海驻云信息科技有限公司官方账号 上海驻云信息科技有限公司官方账号
博客等级 码龄5年 2589粉丝 560原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值