Prometheus查询及接口服务

目录

1.查询语句

1.1 直接使用metrics的name进行查询

1.2 使用标签查询

2.使用记录

2.1 查询语句有加上时间限制

2.2 聚合分组查询

2.3 对区间向量求聚合

2.4 关于Prometheus的api

3 其他

3.1 采集到重复数据

3.2 丢失更新数据

3.3 时区问题

参考文献

---

1.查询语句

1.1 直接使用metrics的name进行查询

例如我定义如下几个度量

CONST.GAUGE0 = Gauge.build()
		.name(CONST.HOST_NAME+"_a")
		.labelNames("prov","label")
		.help(CONST.HOST_DES)
		.register();
CONST.GAUGE1 = Gauge.build()
		.name(CONST.HOST_NAME+"_s")
		.labelNames("host_ip","process_port","label")
		.help(CONST.HOST_DES)
		.register();
CONST.GAUGE2 = Gauge.build()
		.name(CONST.HOST_NAME+"_c")
		.labelNames("host_ip","process_port","label","d_label","to_ip","to_port")
		.help(CONST.HOST_DES)
		.register();

其中CONST.HOST_NAME="online_access_host_1"

在Graph中，直接输入 online_acces_host_1_a，就能看到如下向量集

1.2 使用标签查询

使用label查询是非常方便的，我们可以通过如下的查询获取所有label=2.1.1的向量。

{label="2.1.1"}

其他的标签也是一样的效果。

其实比较重要的是如何进行聚合查询，例如sum的使用、avg的使用。参考文献1中对这方面有比较好的讲解。

这里记录下我自己在使用过程中的一些体会。

2.使用记录

2.1 查询语句有加上时间限制

{label="2.1.2"} [5m]

它的结果类型是“matrix”，就是一个数据集，不是向量集。是不能用sum聚合的。sum进行聚合是对向量的聚合，结果还是向量集。

2.2 聚合分组查询

场景：在GAUGE1这个度量中，存在这样情况，一台设备有4个process_port，对应标签50个。

• 我们想查询某台设备不同端口号下标签等于1.2.1的数据向量集，我们可以如下写：

{host_ip="192.168.1.1",label="1.2.1"}

按照上面这样写，可以直接出来四条记录如下：

• 我想看设备192.168.1.1每个process_port产生的所有数据量，即不考虑指标值了。这时候，我们可以如下写：

sum({host_ip="192.168.1.1"}) by (process_port)

使用 by关键字进行分类聚合，结果如下：

• 我们想按照主机ip分组查询所有标签等于1.6.1的数据情况，即：想获取每一个设备的1.2.1指标的数据向量集

sum({label="1.6.2"})  by  (host_ip)

灵活的运用标签进行筛选，结合聚合函数，Prometheus能提供非常强大的数据查询效果。

2.3 对区间向量求聚合

例如：求某一个指标一小时内的最大值，这是对向量的某个固定区间求最大值，而不是不同纬度的最大值。

max_over_time({label='1.4.1'} [3h])

类似用法的还有如下函数

2.4 关于Prometheus的api

先看下一下代码

    public static void main(String[] args) throws Exception
    {
        String query = URLEncoder.encode("{label=\"2.1.2\"} [5m]","utf-8");
        String url = "http://localhost:9090/api/v1/query?query="+query;
        String ret = HttpKit.get(url);
        System.out.println(ret);
    }

这段代码的意思，就是模拟请求Prometheus的api接口，将查询语句直接传递过去，就能获取对应的数据。我们可以自己定制化的开发对应的展示效果。

出参如下：

{
	"status": "success",
	"data": {
		"resultType": "matrix",
		"result": [{
			"metric": {
				"__name__": "online_accse_host_1_a",
				"instance": "sp1-exp",
				"job": "bis-sp1",
				"label": "2.1.2",
				"prov": "yunnan"
			},
			"values": [
				[1552558929.044, "3903089"],
				[1552559214.044, "3903089"]
			]
		}]
	}
}

这是一个标准的JSON串。一般情况下，我们在使用Prometheus的时候，都会配套的使Grafana等其他数据展示的工具，但其实，我们也可以自己开发自定义的panel。通过访问Prometheus的接口服务，来获取对应的数据。

3 其他

在使用的过程中，还有以下小细节问题记录。Prometheus通过配置scrape_interval和evaluation_interval参数来设置向exporter采集数据的间隔时间。采集数据的间隔和数据生成的时间间隔大小不同，会对数据采集结果有影响。

3.1 采集到重复数据

假如采集的间隔时间小于数据生成的间隔时间，就会采集到重复的数据。

即：假设Prometheus是每5秒采集一次，但是exporter是每11秒生成一次数据，那么第一次采集成功后，第二次采集的数据还是之前的历史数据，并未更新。

3.2 丢失更新数据

假如采集的时间间隔大于数据生成的时间间隔，那么就会丢失更新数据。上一次的数据还未被采集，就被新的数据覆盖了。

简而言之：Prometheus每次向exporter获取数据的时候，都是获取的当前值，不会取到历史数据。

同样的：在使用pushgetway做中转的时候，也有同样的问题，并不能获取到历史数据，或者避免重复数据。

3.3 时区问题

通过prometheus的UI查询界面查询的到数据在查看graph的时候会发现时间对不上，经过观察比对，会发现时间永远是比当前时间小8个小时。检查Prometheus所在主机的时区以及业务bis_exporter的主机的时区以及时间都相同，但是查看的时候时间数据时间对不上，不过，最怪异的是通过Grafana展示的数据曲线却是正确的，时间也正确。

最后经过搜索发现，Prometheus为了保证时序的准确性，内部所有组件都是会用UTC时间，查了下出的日志文件时间也是少8个小时，这就对的上了。

时间戳必须使用UTC时间么？

是的。为了避免时区的混乱，prometheus所有的组件内部都强制使用Unix时间，对外展示使用UTC时间。如果想改变时区，可以在UI改为合适的时区时间。

参考文献

【1】Prometheus 查询语言

【2】Prometheus监控系统简介(2.1.0)

【3】Prometheus FAQ