根本原因是目标服务未暴露符合要求的文本格式指标端点或抓取配置与实际地址/路径不匹配；需确保服务在/metrics返回标准Prometheus文本格式，且static_configs.targets填写真实可访问IP+端口。
为什么 prometheus.yml 里加了 job 却没采集到指标？
根本原因通常是目标服务没暴露符合 Prometheus 要求的文本格式指标端点，或者抓取配置和实际服务地址/路径不匹配。
-
scrape_configs中的static_configs.targets必须写容器或 Pod 的真实可访问 IP+端口（K8s 环境下别直接写localhost:8080） - 被监控服务必须在
/metrics（默认路径）返回纯文本、每行一个key{label=value} value timestamp格式的响应；用curl http://your-service:port/metrics能直接看到内容才算合格 - 如果服务用了自定义路径（如
/actuator/prometheus），得在metrics_path字段显式指定，不能只改target - 注意防火墙、Service Mesh（如 Istio）sidecar 拦截、Pod readiness probe 未就绪导致 endpoint 未注入等隐性拦截点
Go 微服务怎么暴露 http.Handler 供 Prometheus 抓取？
别自己拼字符串写指标输出——用官方 promhttp 处理器，它自动处理 Content-Type、gzip、HEAD 请求和错误响应。
- 引入
github.com/prometheus/client_golang/prometheus/promhttp - 在 HTTP 路由中注册：
http.Handle("/metrics", promhttp.Handler())（Go 1.22+ 可用http.HandleFunc+promhttp.Handler().ServeHTTP） - 避免把
promhttp.Handler()和其他中间件混用导致 header 冲突；尤其别在它前面加自定义 gzip 或 auth 中间件 - 如果服务用的是 Gin/Echo 等框架，需用对应适配器（如
ginprometheus.NewPrometheus），原生promhttp.Handler()无法直接挂载
自定义指标命名为什么总被 promtool check metrics 报错？
不是语法错，是违反 Prometheus 命名约定导致指标无法被正确识别或聚合。
- 名称必须全小写，用下划线分隔，不能含空格、点、破折号；
http_request_total✅，HttpRequestTotal❌，http-request-total❌ - 计数器（counter）必须以
_total结尾；直方图（histogram）必须带_bucket、_sum、_count后缀；否则rate()、histogram_quantile()函数会失效 - 不要给同一个逻辑指标起多个名字（比如同时用
api_latency_seconds和service_response_time），聚合查询时没法统一 - 标签（label）值别塞 JSON 或长路径；高频变动的 label（如 request_id）会导致 series 爆炸，查
prometheus_tsdb_head_series就能发现异常增长
微服务重启后历史指标断层，counter 类型重置怎么处理？
Counter 本身支持重置（比如进程 crash 后重启），但 Prometheus 的 rate() 和 increase() 函数能自动处理，前提是抓取间隔稳定、没有漏采。
- 确保
scrape_interval≤ 30s（默认 1m），且scrape_timeout留足余量（建议设为 interval 的 90%） - 别在客户端做“重置归零”逻辑；Counter 就该从 0 开始累加，靠服务端函数识别翻转
- 如果用了 Pushgateway，它是反模式：pushed 的 counter 不会自动处理重置，且无法反映实例生命周期，仅适用于批任务场景
- 验证是否真断层：查
changes(your_counter_total[1h])，结果为 0 表示完全没上报；查resets(your_counter_total[1h])看是否频繁重置（正常重启应只有 1 次）
最常被忽略的是 target 的 relabel_configs 里误删了 __address__ 或改错了 __metrics_path__，导致 scrape 目标静默失败——它不会报错，只是 quietly 不采集。
