Prometheus拉取指标前必须验证服务暴露/metrics端点，确保符合OpenMetrics规范，并通过Kubernetes服务发现动态配置scrape_configs，结合RED/USE方法论分层设计告警与看板。
用 Prometheus 拉取指标前，先确认服务是否暴露了 /metrics 端点
云原生监控不是“装上就跑”，第一步必须验证被监控目标是否真正可采集。很多新手部署完 Prometheus 却看不到数据，根本原因是应用没暴露符合 OpenMetrics 规范的 /metrics 端点。
- Go/Python/Java 应用需集成官方 client SDK（如
prometheus_client或io.prometheus:simpleclient），并在 HTTP 路由注册该端点 - Kubernetes 中常见错误：Pod 启动了，但未加注解
prometheus.io/scrape: "true"，或端口未通过prometheus.io/port: "8080"显式声明 - 用
curl http://:8080/metrics手动验证——返回内容应为纯文本、每行以# HELP或指标名开头，且无 404/500 错误 - 若用 Istio Sidecar，注意默认拦截所有流量；需在
DestinationRule或PeerAuthentication中放行/metrics路径，否则采集请求会被拒绝
配置 scrape_configs 时，别硬写 IP，要用 Kubernetes Service Discovery
云原生环境里 Pod IP 是临时的，写死 targets: ["10.244.1.5:9090"] 会导致几分钟后监控中断。Prometheus 原生支持动态发现，关键在正确配置 kubernetes_sd_configs。
- 优先使用
role: pod+relabel_configs过滤：只采集带prometheus.io/scrape="true"注解的 Pod，避免拉取系统组件或调试容器 - 别忽略
__address__重标：Kubernetes 默认把 Pod IP 写入该标签，但实际要访问的是podIP:port；需用replacement: "$1:$2"拼接端口，否则采集会连到 localhost - 对于 Headless Service 或 StatefulSet，可用
role: endpoints，它自动聚合同一 Service 下所有 Pod 的/metrics，更适合高可用服务 - 测试配置是否生效：进 Prometheus UI →
Status → Targets，看状态是否为UP，并检查 Labels 是否包含预期的job、namespace、service
告警规则写 for: 10m 不是拍脑袋，得结合指标波动性和业务容忍度
随便设个 for: 2m 容易产生毛刺告警，而 for: 30m 又可能错过故障窗口。云原生场景下，告警持续时间必须匹配指标特性与业务 SLA。
