Go service如何搭建自己的可观测性？-平芜编程栈

那天凌晨两点，支付服务又开始报超时了。我打开 Kibana，熟练地输入"error"，回车。三千条结果。再输入"timeout"，一千二。然后我开始了那场熟悉的“猜谜游戏”：翻日志、对时间戳、开另一个窗口看监控、切回来继续翻、怀疑是数据库、怀疑是网络、怀疑是缓存、怀疑人生。

三个小时后，我终于找到了根因——一个上游依赖的慢查询。但其实前半个小时，所有的信息都已经躺在日志里了。我只是没法把碎片拼起来。

那一刻我不得不面对一个尴尬的事实：我们的服务有日志、有监控、甚至还有追踪，但遇到问题时，这些东西并没有让我更快地找到答案。

我们把“可观测性”当成了一堆工具的集合，而不是一种回答问题的能力。

第一步：别打“叙事日志”了，打“结构化日志”

把 Go 的日志从自由文本换成结构化日志，是性价比最高的升级之一。

像这样的日志：

log.Printf("failed to fetch order: %v",err)

人看着还行，但排查问题的时候基本没用。换成这样就好多了：

logger:=slog.New(slog.NewJSONHandler(os.Stdout,nil))logger.Info("request completed","service","order-api","route","/v1/orders/{id}","status_code",200,"duration_ms",34,"request_id","req_123",)

这一个改动会改变后续所有事情：你现在可以按request_id过滤、按route分组、按status_code搜索，跨服务用统一的属性把日志串起来。

我的原则很简单：每行生产日志，首先得能让机器查，其次才是让人读。

第二步：请求关联——日志孤岛就是事故现场的噩梦

日志在事故期间感觉没用，最大的原因是它们彼此孤立。你有了完美的结构化日志，但如果不能把它们和请求、追踪、上游调用关联起来，依然是在浪费时间。

所以我现在会标准化一组关联字段：

trace_id
span_id
request_id
service
route
需要的话再加user_id

在 Go 里，就是在请求边界把 trace context 拽进日志：

funcLoggerWithTrace(ctx context.Context,logger*slog.Logger)*slog.Logger{span:=trace.SpanFromContext(ctx)sc:=span.SpanContext()if!sc.IsValid(){returnlogger}returnlogger.With("trace_id",sc.TraceID().String(),"span_id",sc.SpanID().String(),)}

一旦你稳定地这么做，调试就从“搜报错信息”变成了“跟着请求走”。后者要舒服太多了。

第三步：追踪要能解释“时间去哪了”，不只是“有没有”

很多团队说自己“有追踪”，其实就是一个请求一个根 span，下面啥也没有。这不够。

对于后端系统，最有价值的 span 通常是：

入站 HTTP 请求
数据库查询
出站 HTTP/RPC 调用
消息队列发布/消费
耗时的内部计算

比如追踪一个支付调用：

funccallPaymentService(ctx context.Context,client*http.Client,urlstring)(*http.Response,error){ctx,span:=tracer.Start(ctx,"payment_client.charge")deferspan.End()req,_:=http.NewRequestWithContext(ctx,http.MethodPost,url,nil)span.SetAttributes(attribute.String("http.url",url))resp,err:=client.Do(req)iferr!=nil{span.RecordError(err)returnnil,err}span.SetAttributes(attribute.Int("http.status_code",resp.StatusCode))returnresp,nil}

关键不是“追踪一切”，而是“追踪能解释延迟和失败的那部分”。

如果事故期间我打开一个 trace，我希望很快看到一个明确的答案：延迟是在我们的 handler、数据库，还是支付服务？如果 trace 回答不了这个问题，它就是装饰品。

第四步：指标要反映“服务行为”，而不是“实现细节”

这地方最容易搞臃肿。团队加了几十个 counter 和 gauge，因为“加上又不费事”，然后发现没有一个能回答有意义的运维问题。

我一般从一小套稳定的指标开始：

请求总数
请求耗时分布（histogram）
正在处理的请求数（in-flight）
错误数/错误率
依赖延迟和依赖错误
相关的时候再加队列深度或 worker 饱和度

用 Prometheus 的话大概是这样：

var(httpRequests=prometheus.NewCounterVec(prometheus.CounterOpts{Name:"http_requests_total"},[]string{"route","method","status_code"},)httpDuration=prometheus.NewHistogramVec(prometheus.HistogramOpts{Name:"http_request_duration_seconds",Buckets:prometheus.DefBuckets,},[]string{"route","method"},)inFlight=prometheus.NewGauge(prometheus.GaugeOpts{Name:"http_requests_in_flight"},))