直接暴露/metrics端点并配置抓取仅能获取运行时指标，无法反映业务健康；必须手动埋点业务指标（如service_db_up、cache_hit_ratio）、增强/health与/ready探针、合理设置scrape_timeout和sample_limit、并基于业务语义设计告警规则。
直接暴露 /metrics 端点 + 配置 Prometheus 抓取，就能监控微服务状态；但只做这一步，90% 的服务会漏掉关键健康信号，比如数据库连不上、下游超时、缓存失效——这些不会体现在 go_goroutines 或 http_request_duration_seconds 里。
暴露 /metrics 端点但不埋业务指标，等于只看体温不查血常规
很多团队以为注册 promhttp.Handler() 就算完成监控，结果上线后发现告警全是“内存涨了”“goroutine 太多”，却对“订单创建失败率突增 20%”毫无感知。根本原因是：默认运行时指标（go_gc_duration_seconds、process_cpu_seconds_total）反映的是 Go 自身状态，不是业务健康。
- 必须手动定义并注册业务相关
CounterVec或Gauge，例如：service_db_up、cache_hit_ratio、third_party_api_latency_seconds -
CounterVec的 label 要做模板化处理：用c.FullPath()（Gin）或r.URL.Path替换动态 ID，避免/user/123和/user/456生成不同指标导致 cardinality 爆炸 - 别在 HTTP handler 函数里调用
prometheus.MustRegister()，否则每次请求都 panic 报错"duplicate metrics collector registration attempted"
/health 和 /ready 不是可选功能，是 Kubernetes 生存前提
Kubernetes 的 livenessProbe 和 readinessProbe 默认只检查 HTTP 200，但一个返回 200 的服务可能正卡在 DB 连接池耗尽、Redis 响应超时的状态。单纯返回 {"status":"up"} 会掩盖真实问题。
-
/health应检查核心依赖：DBPing()、RedisGet("test")、关键下游 HTTPHead()（带短 timeout） -
/ready需额外验证：配置是否加载完成、gRPC client 是否已连接、本地缓存是否 warm-up 完毕 - HTTP 状态码必须真实反映结果：依赖异常时返回
http.StatusServiceUnavailable (503)，而不是统一 200 + JSON 里写"status":"degraded"
Prometheus 抓取配置里最容易被忽略的两个字段
很多人把 targets 写对就以为完事，但实际线上环境经常出现“指标存在但告警不触发”，根源常在这两个配置项上：
立即学习“go语言免费学习笔记（深入）”；
-
scrape_timeout：默认 10s，但如果你的/metrics端点因锁竞争或 GC STW 卡住 12s，这次抓取就失败，且不会重试——建议设为scrape_interval的 80%，例如 interval=30s → timeout=24s -
sample_limit：当自定义指标过多（尤其 label 组合爆炸）时，Prometheus 会 silently drop 超限样本，并在日志里打 warning；生产环境务必显式设置，比如sample_limit: 50000
Alertmanager 规则里写 up == 0 只能发现进程挂了，不能发现服务“假活”
up{job="my-service"} == 0 这类规则只能捕获进程崩溃或端口监听失败，但现实中更常见的是：服务还在响应 /metrics，却因依赖不可用而持续返回 500——此时 up 是 1，但业务已中断。
- 必须搭配业务级指标告警，例如：
rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05（错误率超 5%） - 对
Gauge类健康指标（如service_db_up），告警条件要加offset避免瞬时抖动误报：service_db_up offset 1m == 0 - 所有告警规则必须加
for持续时间，比如for: 2m，防止网络采样毛刺触发通知
真正难的不是把指标暴露出来，而是判断哪些指标组合起来才能代表“服务可用”——这需要你站在调用方视角，想清楚“我依赖这个服务的什么能力”，再反推要监控什么。比如支付服务，DB 连通只是基础，真正要盯的是“扣减库存接口的 P99 延迟是否突破 800ms”，因为这才是用户感知到的失败。
