普罗米修斯 -- HTTP API 调用 PromQL

简介

Prometheus API 使用了 JSON 格式的响应内容。 当 API 调用成功后将会返回查询结果。所有的 API 请求均使用以下的 JSON 格式:

{
  "status": "success" | "error",
  "data": <data>,

  // Only set if status is "error". The data field may still hold
  // additional data.
  "errorType": "<string>",
  "error": "<string>"
}

我们可以通过如下的 get 请求向普罗米修斯发送查询请求:

http://promurl:port/api/v1/query?query=kube_pod_container_info&time=1636457100
  • api 路径都是/api/v1/query
  • 有两种查询类型, 这里面我们用的查询类型就是 query 类型(还有另一个叫 query_range)
  • 在路径和查询类型后跟着的就是 PromQL 语句了。
  • 最后的 time 是时间戳, 代表着查询的时间基线。 就是我们的 PromQL 是以哪个时间点为基准查询的。 我们说过普罗米修斯本身就是一个时序数据库。它默认保存 14 天的数据, 超过 14 天就会自动删除。 所以这个时间戳可以让我们以过去某个时间点为基础进行查询。如果在 UI 上查询的话,只能以当前时间为基线进行查询。

下面贴一个例子看一下我们查询的 json 结果是什么样子的:

$ curl 'http://localhost:9090/api/v1/query?query=up&amp;time=2015-07-01T20:10:51.781Z'
{
   "status" : "success",
   "data" : {
      "resultType" : "vector",
      "result" : [
         {
            "metric" : {
               "__name__" : "up",
               "job" : "prometheus",
               "instance" : "localhost:9090"
            },
            "value": [ 1435781451.781, "1" ]
         },
         {
            "metric" : {
               "__name__" : "up",
               "job" : "node",
               "instance" : "localhost:9100"
            },
            "value" : [ 1435781451.781, "0" ]
         }
      ]
   }
}

响应数据类型

当 API 调用成功后,Prometheus 会返回 JSON 格式的响应内容,格式如上小节所示。并且在 data 节点中返回查询结果。data 节点格式如下:

{
  "resultType": "matrix" | "vector" | "scalar" | "string",
  "result": <value>
}

PromQL 表达式可能返回多种数据类型,在响应内容中使用 resultType 表示当前返回的数据类型,包括:

  • 瞬时向量:vector

当返回数据类型 resultType 为 vector 时,result 响应格式如下:

[
  {
    "metric": { "<label_name>": "<label_value>", ... },
    "value": [ <unix_time>, "<sample_value>" ]
  },
  ...
]

其中 metrics 表示当前时间序列的特征维度,value 只包含一个唯一的样本。

  • 区间向量:matrix

当返回数据类型 resultType 为 matrix 时,result 响应格式如下:

[
  {
    "metric": { "<label_name>": "<label_value>", ... },
    "values": [ [ <unix_time>, "<sample_value>" ], ... ]
  },
  ...
]

其中 metrics 表示当前时间序列的特征维度,values 包含当前事件序列的一组样本。

  • 标量:scalar

当返回数据类型 resultType 为 scalar 时,result 响应格式如下:

[ <unix_time>, "<scalar_value>" ]

由于标量不存在时间序列一说,因此 result 表示为当前系统时间一个标量的值。

  • 字符串:string

当返回数据类型 resultType 为 string 时,result 响应格式如下:

[ <unix_time>, "<string_value>" ]

字符串类型的响应内容格式和标量相同。

区间数据查询

使用 QUERY_RANGE API 我们则可以直接查询 PromQL 表达式在一段时间返回内的计算结果。

GET /api/v1/query_range

URL 请求参数:

  • query=: PromQL 表达式。
  • start=: 起始时间。
  • end=: 结束时间。
  • step=: 查询步长。
  • timeout=: 超时设置。可选参数,默认情况下使用-query,timeout 的全局设置。

当使用 QUERY_RANGE API 查询 PromQL 表达式时,返回结果一定是一个区间向量:

{
  "resultType": "matrix",
  "result": <value>
}

需要注意的是,在 QUERY_RANGE API 中 PromQL 只能使用瞬时向量选择器类型的表达式。

例如使用以下表达式查询表达式 up 在 30 秒范围内以 15 秒为间隔计算 PromQL 表达式的结果。

$ curl 'http://localhost:9090/api/v1/query_range?query=up&amp;start=2015-07-01T20:10:30.781Z&amp;end=2015-07-01T20:11:00.781Z&amp;step=15s'
{
   "status" : "success",
   "data" : {
      "resultType" : "matrix",
      "result" : [
         {
            "metric" : {
               "__name__" : "up",
               "job" : "prometheus",
               "instance" : "localhost:9090"
            },
            "values" : [
               [ 1435781430.781, "1" ],
               [ 1435781445.781, "1" ],
               [ 1435781460.781, "1" ]
            ]
         },
         {
            "metric" : {
               "__name__" : "up",
               "job" : "node",
               "instance" : "localhost:9091"
            },
            "values" : [
               [ 1435781430.781, "0" ],
               [ 1435781445.781, "0" ],
               [ 1435781460.781, "1" ]
            ]
         }
      ]
   }
}

实战演示

最近做了一个资源优化专项,目的是实际了解一下业务运行时产品 160+ 的服务每个服务所使用的 cpu 和内存情况。 并对比他们申请的 request 和 limit 的值,计算服务是否申请了过多的资源导致资源浪费。 所以我们要通过 HTTP PromQL 把相关的数据查询出来。

prom_url = 'http://1.117.219.41:30778'
start_time = str(int(datetime.strptime("09/11/2021 19:25:00", "%d/%m/%Y %H:%M:%S").timestamp()))
end_time = str(int(datetime.strptime("09/11/2021 21:25:00", "%d/%m/%Y %H:%M:%S").timestamp()))
result = {}

r = requests.get(
    url='{prom_url}/api/v1/query_range?query=sum(node_namespace_pod_container%3Acontainer_cpu_usage_seconds_total%3Asum_rate%7Bcluster%3D%22cls-hchrqyex%22%7D)%20by%20(pod)&amp;start={start}&amp;end={end}&amp;step=30'.format(
        start=start_time, end=end_time, prom_url=prom_url))
datas = r.json()['data']['result']

for data in datas:
    pod_name = data['metric']['pod']
    cpu_usages = []
    for c in data['values']:
        cpu_usages.append(float(c[1]))
    max_value = max(cpu_usages)
    avg_value = statistics.mean(cpu_usages)
    result[pod_name] = {
        'cpu_max_usage': max_value,
        'cpu_avg_usage': avg_value
    }

上面代码中的 PromQL 是sum(node_namespace_pod_container:container_cpu_usage_seconds_total:sum_rate) by (pod) 首先 node_namespace_pod_container:container_cpu_usage_seconds_total:sum_rate 是一个预定义的查询别名。 有些查询语句过于复杂,所以我们可以给复杂的语句一个别名, 这样在使用 的时候就比较方便了。 而我们使用的这个别名就如同它的名字一样, 是查询每个容器的 cpu 使用率的。 因为一个 pod 里可能会有多个容器, 所以需要使用 sum by (pod) 的方式统计出每个 pod 的 cpu 使用率总和。 这里我们使用的就是一个 query_range 的查询类型。 因为我们希望查询在测试期间的 2 个小时内 cpu 使用率的最大值和平均值。 所以我们在请求最后使用step=30这个参数来指定每隔 30s 计算一次指标,然后我们在使用 start 和 end 参数指定了一个时间范围。所以在指定的这 2 个小时内,每隔 30s 就会使用 PromQL 查询一次,这样返回结果里我们就有了很多个采样数据, 反应了随着时间变化 CPU 使用率的情况。 这时候我们再编写 python 代码把返回的 json 取出来计算最大值和平均值即可。

更多技术文章

<think>嗯,用户问的是“普罗米修斯报执行错误”,首先我需要确定这个普罗米修斯指的是什么。普罗米修斯在技术领域通常指的是Prometheus,一个开源的监控和警报工具。所以用户可能在用Prometheus时遇到了执行错误。 接下来,我需要考虑常见的Prometheus错误类型。比如配置错误、服务不可达、存储问题、资源不足、版本兼容性,还有查询语句的问题。这些都是常见的原因。 首先,用户可能需要检查日志。Prometheus的日志通常会给出错误的具体信息,比如配置文件哪里出错,或者连接失败的目标。要告诉用户查看日志的方法,比如通过systemctl或者docker logs。 然后是配置文件的验证。Prometheus的配置文件如果格式不对,或者缩进错误,会引发问题。可以用promtool工具来检查,这样可以快速定位配置错误。 目标抓取失败也是一个常见问题。可能的原因包括网络问题、目标服务未运行,或者安全组/防火墙的设置。建议用户检查Prometheus的target页面,看看端点是否健康。 存储问题方面,如果磁盘满了或者权限不对,Prometheus可能无法写入数据。需要检查数据目录的权限和磁盘空间,必要时调整启动参数中的存储路径。 资源不足的话,内存或CPU不够会导致Prometheus崩溃,尤其是在处理大量指标时。建议监控资源使用情况,可能需要优化配置或扩容。 版本兼容性方面,如果用户升级了Prometheus或者Exporters,可能会有兼容性问题,需要确认版本是否匹配。 查询错误的话,PromQL写错了会导致执行错误,这时候需要检查查询语句,用Prometheus的表达式验证功能来调试。 最后,重启服务和查看官方文档也是常用的解决步骤。如果用户的问题依然存在,可能需要更详细的日志或配置信息来进一步分析。 总结下来,我需要分步骤解释这些可能的原因和解决办法,帮助用户逐步排查问题,确保回答结构清晰,易于理解。同时,注意使用正确的中文术语,避免技术术语的混淆,确保用户能够按照指引操作。</think>以下关于普罗米修斯(Prometheus)执行错误的排查思路及解决方案分步骤说明: 1. **查看日志定位根源** - 执行命令获取详细日志: ```bash journalctl -u prometheus.service -f # 系统服务日志 或 docker logs -f prometheus_container # Docker容器日志 ``` - 日志中常见关键词: * `error loading configuration` → 配置文件错误 * `connection refused` → 目标服务不可达 * `out of memory` → 内存不足 2. **验证配置文件** - 使用官方工具检查语法: ```bash promtool check config prometheus.yml ``` - 典型配置错误示例: ```yaml # 错误示例(缩进错误) scrape_configs: - job_name: 'node' static_configs: # ← 此处缩进不足 - targets: ['localhost:9100'] ``` 3. **检查目标服务可达性** - 访问Prometheus Web界面 → Status → Targets - 确认Endpoint列的HTTP状态码: * `200 OK` → 正常 * `Connection refused` → 检查目标服务端口开放状态 ```bash telnet target_ip 9100 # 测试端口连通性 ``` 4. **存储问题排查** - 检查数据目录权限: ```bash ls -ld /var/lib/prometheus/data ``` - 验证磁盘空间: ```bash df -h /var/lib/prometheus ``` - 启动参数调整示例: ```bash --storage.tsdb.path=/mnt/prometheus_data # 指定大容量存储路径 ``` 5. **资源优化建议** - 内存限制调整(Docker示例): ```bash docker run -d --name prometheus \ --memory=4g \ # 限制内存 -p 9090:9090 \ prom/prometheus ``` - 配置优化方向: * 减少`scrape_interval`采集频率 * 使用`metric_relabel_configs`过滤无用指标 6. **版本兼容性检查** - 查询版本信息: ```bash prometheus --version ``` - 确认Exporter版本兼容性(如node_exporter ≥1.0需Prometheus ≥2.21) 7. **PromQL调试技巧** - 使用Web界面验证查询: ```promql # 错误示例(缺少聚合函数) sum(rate(http_requests_total[5m])) # 正确 rate(http_requests_total[5m]) # 可能返回过多时间序列 ``` - 表达式验证API调用: ```bash curl -X POST http://localhost:9090/api/v1/query \ -d 'query=up{job="node"}' \ -d 'time=1628880000' ``` **典型错误案例解决流程**: 1. 观察日志发现`error="context deadline exceeded"` 2. 检查目标服务发现响应时间超过`scrape_timeout`(默认10s) 3. 解决方案: ```yaml scrape_configs: - job_name: 'high_latency_service' scrape_timeout: 30s # 延长超时时间 static_configs: - targets: ['service:8080'] ``` 如问题仍未解决,建议提供: 1. Prometheus版本信息 2. 错误日志片段 3. 相关配置文件(脱敏后) 4. 对应Exporter版本信息 注:以上时间参数(如`scrape_timeout`)需根据实际业务场景调整,生产环境建议设置监控告警规则: ```yaml groups: - name: prometheus_health rules: - alert: PrometheusTargetDown expr: up == 0 for: 5m ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值