很多小服务一开始没有完整监控系统，但也需要知道一些基本状态：请求数、错误数、队列长度、缓存命中次数。Go 标准库里的 expvar 可以用很低成本暴露 JSON 指标。它不替代 Prometheus 这类监控体系，但很适合入门理解“服务应该给外界看哪些状态”。
expvar 默认通过 /debug/vars 暴露变量。只要导入并注册变量，就能看到 JSON。
最小示例
var requestCount = expvar.NewInt("requests_total")
func handler(w http.ResponseWriter, r *http.Request) {
requestCount.Add(1)
fmt.Fprintln(w, "ok")
}
如果你的程序使用默认 mux，并导入了 net/http/pprof 或使用 expvar，访问 /debug/vars 可以看到：
{
"requests_total": 12
}
实际服务中，建议把 debug 路由挂在内部端口或加认证，不要随便暴露到公网。
请求和错误计数
var (
requestsTotal = expvar.NewInt("http_requests_total")
errorsTotal = expvar.NewInt("http_errors_total")
)
func MetricsMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
requestsTotal.Add(1)
rec := &statusRecorder{ResponseWriter: w, status: http.StatusOK}
next.ServeHTTP(rec, r)
if rec.status >= 500 {
errorsTotal.Add(1)
}
})
}
type statusRecorder struct {
http.ResponseWriter
status int
}
func (r *statusRecorder) WriteHeader(status int) {
r.status = status
r.ResponseWriter.WriteHeader(status)
}
这段中间件记录请求总数和 5xx 错误数。指标不需要非常复杂，能回答关键问题就有价值：服务有没有流量？错误有没有增加？
队列长度
后台任务队列可以暴露长度：
var queueLength = expvar.NewInt("jobs_queue_length")
func enqueue(job Job) {
queueLength.Add(1)
jobs <- job
}
func worker() {
for job := range jobs {
queueLength.Add(-1)
process(job)
}
}
如果队列长度持续增加，说明消费速度跟不上生产速度。没有这个指标时，你可能只看到任务延迟变长，却不知道积压从什么时候开始。
自定义 JSON 指标
expvar.Func 可以动态生成值：
var startedAt = time.Now()
func init() {
expvar.Publish("uptime_seconds", expvar.Func(func() any {
return int(time.Since(startedAt).Seconds())
}))
}
也可以返回结构：
expvar.Publish("build_info", expvar.Func(func() any {
return map[string]string{
"version": version.Version,
"commit": version.Commit,
}
}))
注意不要在 expvar.Func 里做慢操作。它会在请求 /debug/vars 时执行，应该只读内存状态，不要查数据库或调用外部 API。
安全边界
/debug/vars 可能暴露 Go 运行时信息、变量名和业务状态。它应该放在内部网络、管理端口或认证后面。不要把用户隐私、token、数据库地址放进 expvar。指标是给机器和运维看的，不是配置转储。
可以单独启动内部服务：
go func() {
mux := http.NewServeMux()
mux.Handle("/debug/vars", expvar.Handler())
log.Println(http.ListenAndServe("127.0.0.1:9090", mux))
}()
绑定 127.0.0.1 比直接挂公网主 mux 更稳。
测试指标中间件
全局 expvar 不太适合大量单元测试，因为变量名全局唯一。更好的方式是把计数器抽象成接口，或者对中间件逻辑测状态 recorder。入门阶段至少要知道：全局指标会影响测试隔离，不要在很多测试里重复注册同名变量。
如果只是手动验证，可以运行服务后访问：
curl http://127.0.0.1:9090/debug/vars
观察请求数是否变化。
指标命名要稳定
指标名一旦被脚本、仪表盘或告警引用，就不要随便改。建议使用清楚的英文名，比如：
http_requests_total
http_errors_total
jobs_queue_length
cache_hits_total
计数器通常用 _total 结尾，当前状态用普通名。即使 expvar 没有强制规范，保持命名习惯也能降低后续迁移到 Prometheus 等系统的成本。
不要在指标里放高基数字段
expvar 的变量是全局暴露的，不适合为每个用户、每个订单、每个 URL 都创建一个变量。比如 user_123_requests 这类指标会让变量数量爆炸。小服务里指标应该少而关键：总请求、错误、队列长度、缓存命中、构建信息。需要高维度分析时，应该引入更合适的监控系统。
指标不是日志。日志记录事件，指标记录趋势。把这两个概念分清，观测体系会更干净。
给缓存加命中指标
一个常见实用指标是缓存命中和未命中：
var (
cacheHits = expvar.NewInt("cache_hits_total")
cacheMisses = expvar.NewInt("cache_misses_total")
)
func (s *Service) GetConfig(ctx context.Context, key string) (Config, error) {
if cfg, ok := s.cache.Get(key); ok {
cacheHits.Add(1)
return cfg, nil
}
cacheMisses.Add(1)
cfg, err := s.store.Load(ctx, key)
if err != nil {
return Config{}, err
}
s.cache.Set(key, cfg)
return cfg, nil
}
命中率能帮助你判断缓存是否真的有效。如果 miss 一直很高，可能 TTL 太短、key 设计不稳定，或者缓存根本没有覆盖热点路径。没有指标时，你只能凭感觉讨论缓存效果。
用 expvar 做临时排查
有时你还没来得及接完整监控，只想临时确认某个状态。expvar 很适合作为过渡工具。但临时指标也要有退出计划：问题排查完后，要么转成正式指标，要么删除。否则几年后 /debug/vars 里会堆满没人理解的变量。
保持指标少而明确，比堆很多“也许有用”的数字更好。
小结
expvar 是 Go 标准库提供的轻量指标工具，适合暴露请求数、错误数、队列长度、启动时间和构建信息。它简单、零依赖，但也有边界：全局变量、JSON 输出、没有复杂标签模型。
小服务可以先用 expvar 建立观测意识。等指标维度和告警需求变复杂，再接入更完整的监控系统。先知道服务内部发生了什么，比一开始追求完整平台更重要。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。