go微服务监控需基于metrics、logs、traces三大支柱，结合运行时指标（goroutine数、gc、内存分配、线程）与业务黄金指标（qps、延迟分布、错误率、依赖健康度、缓存命中率），并遵循低基数标签原则。
Go微服务监控不能只看CPU或响应时间，得从可观测性的三个支柱出发，结合Go语言特性和业务实际，选对维度才能真正发现问题。
核心指标维度：Metrics、Logs、Traces缺一不可
单一维度无法覆盖故障场景。比如：
- Metrics（指标）：用于发现“什么出了问题”，如HTTP请求P99延迟突增、goroutine数持续上涨、GC暂停时间超过10ms
- Logs（日志）：用于回答“为什么出问题”，需结构化（JSON格式）、带trace_id和request_id，便于与指标/追踪对齐
- Traces（链路追踪）：用于定位“问题在哪一环”，尤其在gRPC或HTTP跨服务调用中，能直观看到耗时瓶颈落在数据库、缓存还是下游服务
Go运行时必须暴露的4类关键指标
很多团队只监控业务接口，却忽略Go自身运行状态，这是线上goroutine泄漏、内存抖动等问题难以发现的主因：
-
Goroutine数量：用
expvar或runtime.NumGoroutine()暴露为Gauge，持续高于2k需预警 -
GC统计：包括
go_gc_duration_seconds（官方指标）、go_memstats_heap_alloc_bytes，关注每分钟GC次数与pause时间趋势 -
内存分配速率：
go_memstats_alloc_bytes_total配合rate计算，突增往往预示对象频繁创建或泄漏 -
线程与系统调用：
go_threads和go_goroutines对比，若线程数远高于goroutine数，可能有阻塞式IO未适配异步
业务接口层应聚焦的5个黄金指标
不是所有HTTP指标都有价值，优先采集能直接驱动决策的：
-
请求量（QPS + PV）：按
method、path、status_code打标，区分成功/失败/重定向流量 -
响应延迟分布：用Histogram暴露
http_request_duration_seconds，必须保留0.01s～1s+分桶，P90/P95/P99要可查 -
错误率：不只是5xx，也包含业务错误码（如订单服务返回
err_code=1003），建议单独定义business_errors_total - 依赖调用健康度：对外部服务（Redis、MySQL、其他gRPC服务）的调用成功率、平均延迟、超时次数，避免故障被上游掩盖
-
缓存命中率：对Redis或本地缓存，用
cache_hits_total / (cache_hits_total + cache_misses_total)计算，低于85%需告警
标签设计原则：避免高基数，兼顾可下钻
标签（label）用得好是利器，滥用则让Prometheus存储爆炸、查询变慢：
- 禁止将
user_id、request_id、ip等唯一值设为标签 - 推荐组合：
service（固定）、env（prod/staging）、region（cn-east/cn-west）、endpoint（/api/v1/translate） - 业务维度如
source_lang、target_lang可保留，但总数控制在10种以内 - 所有自定义Counter/Gauge/Histogram注册前，先用
prometheus.NewRegistry().MustRegister(...)做隔离验证
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
