可观测rpc服务构建需关注指标、日志与追踪。1. 指标方面：使用prometheus/client_golang库，为各rpc接口注册调用次数与耗时统计，采用histogram记录延迟分布，并通过http接口暴露指标数据，便于prometheus抓取；2. 日志方面：选用logrus或zap等结构化日志库，记录请求id、方法名、状态等上下文信息，便于问题排查与流程串联；3. 追踪方面：引入opentelemetry sdk并配置exporter，利用grpc拦截器记录span信息，自动注入trace id与span id至日志和指标中，打通三者关联，实现完整调用路径分析。设计时应预留扩展空间，逐步完善三位一体的可观测性。
在写一个可观测的RPC服务时，指标（Metrics）、日志（Logs）和追踪（Tracing）是三个不可或缺的部分。Golang作为高性能后端语言，在构建微服务系统中广泛使用。要想让服务“看得见、摸得着”，就得在这三方面下功夫。
下面从实际开发角度出发，讲讲怎么用Golang搭建一个具备基本可观测能力的RPC服务，不追求炫技，只求实用。
指标：记录关键行为
指标是最直观的监控方式，比如请求次数、响应时间、错误率等。Golang生态里最常用的库是
prometheus/client_golang，它提供了很多现成的指标类型，如Counter、Gauge、Histogram等。
立即学习“go语言免费学习笔记（深入）”；
建议做法：
- 给每个RPC接口注册调用次数和耗时统计
- 使用Histogram来记录延迟分布，方便看P95/P99
- 把指标暴露为HTTP接口，供Prometheus抓取
举个例子：
http.Handle("/metrics", promhttp.Handler())
go http.ListenAndServe(":8080", nil)这样就能通过访问
/metrics拿到当前所有指标数据了。
关键细节：
- 为不同方法打标签（label），比如
method="SayHello"
，便于分组统计 - 记录失败次数的时候最好单独用一个Counter，别混在总调用量里
日志：结构化输出更清晰
传统文本日志虽然能看，但不好分析。结构化日志（比如JSON格式）可以被Logstash、Fluentd等工具自动解析，再配合Kibana查看就非常方便。
推荐做法：
- 使用像
logrus
或zap
这样的结构化日志库 - 在每条日志里带上请求ID、方法名、状态等上下文信息
- 分级别记录日志，避免生产环境刷屏
例如在处理RPC请求前生成一个request ID，并在整个调用链路中传递：
logger.WithFields(logrus.Fields{
"request_id": id,
"method": method,
}).Info("start processing request")这样查问题时就能按request_id把整个流程的日志串起来。
追踪：看清调用路径
分布式追踪的核心是把一次请求经过的所有服务串联起来，形成完整的调用树。OpenTelemetry是目前主流的解决方案，支持自动注入trace ID和span信息。
实现要点：
- 引入OpenTelemetry SDK并配置exporter（比如导出到Jaeger或OTLP）
- 自动注入中间件（如gRPC拦截器）来记录每个RPC的span
- 将trace ID注入到日志和指标中，打通三者之间的关联
以gRPC为例，可以加一个server interceptor来创建span：
grpc.UnaryInterceptor(otgrpc.OpenTelemetryServerInterceptor())
这样每次调用都会自动生成一个span，包含开始时间、持续时间、标签、事件等信息。
小贴士：打通三者更有效
要真正实现三位一体的可观测性，关键是把这三个部分的数据打通：
- 所有日志带上trace_id和span_id
- 指标也可以根据trace上下文做聚合
- 前端展示时可以从Prometheus看到某个接口异常，跳转到对应trace查看具体请求路径
这一步不一定一开始就要做全，但心里要有这个目标，设计代码结构时留好扩展空间。
基本上就这些。用Golang写可观测RPC服务不算难，但要把指标、日志和追踪都用上，确实需要一点规划和积累。不复杂，但容易忽略细节。
