up 是什么
up 是 Prometheus 为每个抓取目标自动生成的合成指标：本次抓取成功为 1，失败为 0。它不需要目标自己暴露，只要目标被纳入某个抓取任务就存在，因此是最常用的基础健康信号，也是排查采集链路问题的起点。
up 不等于服务健康
抓取成功只说明端点可访问并返回了数据，并不代表业务正常：服务可能返回全量失败，也可能因依赖故障而性能骤降，这些情况下 up 依然是 1。它是采集健康信号，业务健康要靠请求类指标判断。
目标消失与抓取失败
目标被删除或服务发现不再返回它时，对应的 up 序列会整体消失，此时按取值等于 0 写的告警不会触发。要覆盖这种静默失效，需要用缺失检测函数补充告警，或对在线目标数量设置下限。
基本信息
| 取值 | 1 表示抓取成功，0 表示抓取失败 |
|---|---|
| 标签 | 携带 job、instance 以及目标上的其他标签 |
| 产生方式 | 抓取时自动生成，无需目标暴露 |
| 相关指标 | 抓取耗时与采样数可辅助判断采集质量 |
典型使用场景
- 采集健康看板：按任务统计在线目标数与失联清单
- 目标掉线告警：实例失联时立即通知，往往早于用户感知
- 批量故障判定：大批目标同时失联通常是网络或服务发现问题
- 长期可用率：用时间窗口内的平均值近似目标在线比例
- 接入验证：新目标加入后确认在线，避免只改了配置没有生效
常用写法
常用写法
up{job="node"} # 按实例查看 1 或 0
up{job="node"} == 0 # 只看失联目标
count by (job) (up == 0) # 按任务统计失联数量
sum(up) / count(up) # 整体在线比例
avg_over_time(up{job="api"}[30d]) # 长期可用率近似取值与含义
| 取值 | 含义 | 下一步动作 |
|---|---|---|
| 1 | 本次抓取成功 | 确认返回的数据是否合理 |
| 0 | 本次抓取失败 | 查看抓取错误信息与目标进程状态 |
| 序列不存在 | 目标未纳入或已被移除 | 检查服务发现与配置是否被改动 |
常见失联原因
| 原因 | 表现 | 排查方式 |
|---|---|---|
| 进程退出 | 端口无响应 | 登录主机检查服务状态与日志 |
| 网络隔离 | 连接超时 | 从 Prometheus 所在机器测试连通性 |
| 鉴权失败 | 返回未授权状态 | 用相同凭据手工请求端点验证 |
| 路径或端口变更 | 返回 404 或连接被拒 | 核对配置与目标实际监听端口 |
| 抓取超时 | 耗时逼近超时阈值 | 查看抓取耗时并优化端点响应 |
补上静默失效的告警
补上静默失效的告警
# 抓取失败的告警
up{job="api"} == 0
# 目标整体消失时的兜底：序列不存在也会触发
absent(up{job="api"})
# 在线目标数量低于预期下限
count(up{job="api"}) < 3使用时的三个注意
- 失联判定依赖超时设置：超时越长，掉线被发现得越晚
- 多副本抓取同一目标时 up 会按副本区分，聚合前先明确视角
- 把 up 当作对外可用性指标会失真，对外承诺应按真实请求统计
排查顺序是先看目标页面确认状态与错误信息，再回头核对表达式：采集层面的问题在表达式里是查不出来的。
只写 up 等于 0 的告警会漏掉目标被整组删除的情况：序列消失时表达式没有任何输入，自然不会告警，必须配合缺失检测。
与采集配置的配合
- 抓取间隔决定掉线被发现的粒度，间隔越长发现越慢
- 超时设置要留出余量：端点耗时逼近超时时会出现间歇性失败
- 目标数量上限可做兜底告警，防止配置误删导致覆盖面骤减