Prometheus不直接标记异常主机，需通过PromQL查询暴露问题，如up==0表示目标失联，具体阈值（如CPU空闲率、磁盘IO等待）需按场景自定义。
如何用Python请求Prometheus的/api/v1/query获取异常主机
Prometheus本身不直接标记“异常主机”，得靠查询语句暴露问题——比如up == 0表示目标失联，irate(node_cpu_seconds_total{mode="idle"}[5m]) 可能暗示CPU满载。Python脚本的核心就是构造这类查询，发GET请求，解析JSON响应。
关键点：Prometheus API要求query参数是URL编码后的PromQL，且需处理分页和时间范围（time参数决定查哪个时刻的快照）。
- 用
requests.get()发请求，务必加timeout=10，避免API卡住整个脚本 - 如果Prometheus启用了Basic Auth，必须在
auth参数里传(user, passwd)，光靠header会401 - 响应体是JSON，但错误时
response.status_code != 200并不总触发异常，得手动检查response.json().get("status") == "error"
解析up == 0结果时，为什么result里没有主机名
查up == 0返回的是时间序列列表，每条含metric字段（字典），真正主机名藏在metric["instance"]里，不是value[1]那个字符串值——那个是数值（0.0）。
常见误操作：直接遍历result取value[1]，结果拿到一堆"0.0"，漏掉所有instance标签。
立即学习“Python免费学习笔记（深入）”；
- 正确路径：
for item in data["data"]["result"]:→host = item["metric"].get("instance", "unknown") - 如果目标用了
job或__name__等其他标签区分环境，记得一并提取，比如item["metric"].get("job") - 注意
instance格式可能是"10.1.2.3:9100"，如需清洗成IP，用host.split(":")[0]即可
脚本里怎么安全传入Prometheus地址和超时配置
硬编码"http://localhost:9090"会导致迁移困难，也容易泄露敏感地址。推荐用环境变量+默认回退，比命令行参数更适配定时任务场景。
- 读取地址：
os.getenv("PROM_URL", "http://localhost:9090")，本地测试设export PROM_URL=http://dev-prom:9090 - 超时值别写死：
timeout = float(os.getenv("PROM_TIMEOUT", "8.0"))，避免某些慢查询拖垮cron job - 如果Prometheus启用了TLS且用自签名证书，必须显式加
verify=False，否则requests.exceptions.SSLError直接中断
为什么脚本跑通了但没输出任何主机
最常踩的坑是Prometheus服务端根本没采集到目标——up == 0只对已配置的target生效，如果某台主机压根没加进scrape_configs，它不会出现在结果里，更不会被标为“0”。
另一个隐蔽原因：查询时间点（time参数）早于最近一次抓取时间，导致返回空result数组。
- 先人工验证：curl -G "http://your-prom/api/v1/query?query=up" --data-urlencode "time=$(date -u +%Y-%m-%dT%H:%M:%SZ)"，看是否真有
up == 0的数据 - 脚本里建议默认不带
time参数，让Prometheus用当前时间，除非你明确需要历史快照 - 加一行日志：
print(f"Query URL: {url}, Response status: {resp.status_code}")，快速区分是网络问题、认证失败还是逻辑空结果
复杂点在于Prometheus的“异常”定义是业务相关的——内存使用率>95%算异常？磁盘IO等待>10s算异常？这些阈值没法通用，每次换监控指标都得重调PromQL和告警逻辑。
