Blackbox Exporter的up是1，为什么网关探测仍然失败

Exporter的up为1，只说明Prometheus成功抓到了Exporter；probe_success才回答它对目标的探测是否成功。目标返回503时两者可以分别为1和0，Exporter停止以后up才会变成0。

画出Prometheus到探针到目标两跳

多目标探测有两跳：Prometheus到Blackbox，以及Blackbox到被测网关。排查时要保留目标身份与模块参数，避免看着导出器自己的正常抓取误以为全部上游正常。也不能只看probe_success而忽略它已经很久没有新样本的情况。

配置本地http探测模块

实验启动独立Blackbox0.26.0与Prometheus3.5.0，两个假路径分别返回200和503。成功路径probe_success为1，失败路径为0，而失败任务的up仍为1；停止本实验启动的Exporter后，失败任务up变为0。状态来自真实两跳抓取，没有向公网网关发送探测流量。

失败探测任务的up为1时，Exporter连通性已经得到本次抓取证据，下一步应检查probe的阶段指标与目标响应。up变为0时则先恢复抓取链路，避免沿着目标业务错误继续排查。两类告警可以同时存在，但通知说明应指向各自失败的一跳，帮助接手者从正确位置开始。

限定探测成功不等于真实模型可用

探测模块定义了什么成功，决定结果代表什么。一个无需认证的健康页200只代表该路径符合模块条件，不等同于真实模型、数据库或付费接口可用。正式告警通常还需要持续时间与缺失检测，避免单次波动或Exporter自身故障造成错误解释。目标标签也要沿两跳保留，否则多条探测结果可能只显示同一个Exporter地址，值虽然正确却难以定位失败对象。交接时应把探测目标、模块名、状态码要求和观测时间一起保存，让接手者知道每个零值究竟描述哪条路径。

适用范围：仅回环HTTP，不向真实上游探测；不把200健康页等同付费模型调用成功。

配套样本与复核入口

• run.py：独立运行程序，包含合成输入、操作和正反例断言。
• case.json：输入说明、预期任务与适用范围，便于保存和交接。
• observed.json：本次实际执行输出；临时路径、进程号和计时可能随运行变化。

先准备Prometheus和Blackbox两个官方二进制，按依赖说明设置路径。程序只探测自己创建的200与503回环地址，依次观察成功探测、失败探测与Exporter停止三种状态。good_probe、bad_probe、bad_exporter_up与stopped_exporter_up是不同阶段的值，不能拿停机后的缺样去解释停机前的探测失败。

Linux、Python3.8以上与官方Prometheus3.5.0，设置PROMETHEUS_BIN为可执行文件绝对路径；本题另需Blackbox Exporter0.26.0，设置BLACKBOX_BIN。程序只监听127.0.0.1动态高端口，并为新进程使用独立配置、日志和数据目录，结束时只停止自己启动的进程。

python3 -B run.py

阅读输出时，先按case.json中的任务逐项核对网关黑盒探测up与probe_success，再与observed.json比较。非零退出表示依赖或断言需要处理，应保留实际错误。

一手依据1（导出器可被抓取时，probe_success仍可能为0；多目标探测须保留目标身份。）。

继续阅读：网关监控图突然归零，是没有请求还是抓取已经断了；网关还可调用却被监控判为down，怎样验证metrics抓取超时；容器已启动不代表网关可服务：怎样核对依赖就绪条件。