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://<pod-ip>: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。
Zenlink - Node SDK for ZenHeart
下载
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
- CPU 使用率这类高频抖动指标，建议
for: 5m~10m，并叠加avg_over_time(cpu_usage{job="app"}[5m]) > 80防止瞬时尖峰误报 - 服务可用性（如
up == 0）可设for: 1m，因为宕机无需等待——但务必配合静默期（inhibit_rules），避免一个节点挂掉引发整个集群告警风暴 - RED 方法论下的
rate(http_requests_total[5m])类指标，for时间应 ≥ 查询区间（如 [5m]），否则语义不一致 - 用
ALERTS{alertstate="firing"}在 Grafana 里画告警触发热力图，回溯过去一周真实触发频率，再反向调优for和阈值
Grafana Dashboard 别堆砌图表，按 USE/RED 分层组织指标卡片
一个 Dashboard 放 30 个面板，等于没监控。云原生运维需要的是“一眼定位根因”的信息密度，不是数据展览。
- 基础设施层（USE：Utilization, Saturation, Errors）：单个节点卡片只放 3 行——CPU/Mem 利用率（利用率）、
node_load1（饱和度）、node_disk_io_now（错误/阻塞信号） - 应用层（RED：Rate, Errors, Duration）：每个微服务卡片固定结构——QPS 曲线 + 5xx 错误率饼图 + p95 延迟热力图（按 endpoint 分组）
- 隐藏低价值指标：比如单个容器的
container_cpu_usage_seconds_total瞬时值，不如看sum by (pod) (rate(container_cpu_usage_seconds_total[5m]))的聚合趋势 - 给所有图表加
Legend: {{instance}} - {{job}}标签，避免多个命名空间同名服务混在一起无法区分
最常被忽略的一点：Dashboard 的 Refresh every 别设成 1s——Prometheus 查询压力会指数级上升；生产环境推荐 30s 起步，高频诊断时手动刷新更安全。
