导语 ：Prometheus是一个开源的完整监控解决方案，本文将从指标抓取到查询及可视化展示，以及最后的监控告警，对Prometheus做一个基本的认识。

监控神器：Prometheus 轻松入门，真香！（上篇）_ITPUB博客 (知识点：一至四)

五、PromQL

刚刚提到了Prometheus中指标有哪些类型以及如何导出我们的指标，现在指标导出到Prometheus了，利用其提供的PromQL可以查询我们导出的指标。

PromQL是Prometheus为我们提供的函数式的查询语言，查询表达式有四种类型：

• 字符串：只作为某些内置函数的参数出现；
• 标量：单一的数字值，可以是函数参数，也可以是函数的返回结果；
• 瞬时向量：某一时刻的时序数据；
• 区间向量：某一时间区间内的时序数据集合。

（一）瞬时查询

直接通过指标名即可进行查询，查询结果是当前指标最新的时间序列，比如查询Gc累积消耗的时间：

我们可以看到查询出来有多个同名指标结果 可以用 {}做标签过滤查询：比如我们想查指定实例的指标： 而且也支持则表达式，通过 =~ 指定正则表达式，如下所示：查询所有 instance 是 localhost 开头的指标。

（二）范围查询

范围查询的结果集就是区间向量，可以通过[]指定时间来做范围查询，查询5分钟内的Gc累积消耗时间：

注意：这里范围查询第一个点并不一定精确到刚刚好5分钟前的那个时序样本点，他是以5分钟作为一个区间，寻找这个区间的第一个点到最后一个样本点。

时间单位：

同样支持类似SQL中的offset查询，如下：查询一天前当前5分钟前的时序数据集：

（三）内置函数

Prometheus内置了很多函数，这里主要记录下常用的几个函数的使用：

rate和irate函数：rate函数可以用来求指标的平均变化速率。

一般rate函数可以用来求某个时间区间内的请求速率，也就是我们常说的QPS。

但是rate函数只是算出来了某个时间区间内的平均速率，没办法反映突发变化，假设在一分钟的时间区间里，前50秒的请求量都是0到10左右，但是最后10秒的请求量暴增到100以上，这时候算出来的值可能无法很好的反映这个峰值变化。

这个问题可以通过irate函数解决，irate函数求出来的就是瞬时变化率。

可以通过图像看下两者的区别：irate函数的图像峰值变化大，rate函数变化较为平缓。

rate函数

irate函数

聚合函数：Sum() by() without()

也是上边的例子，我们在求指定接口的QPS的时候，可能会出现多个实例的QPS的计算结果，如下是存在多个接口，三个服务的QPS。

利用sum函数可以将三个QPS聚合，即可得到整个服务该接口的QPS：其实Sum就是将指标值做相加。

但是这样直接的相加太笼统抽象了，可以配合by和without函数在sum的时候，基于某些标签分组，类似SQL中的 group by

例如，我可以根据请求接口标签分组：这样拿到的就是具体接口的QPS：

也可以不根据接口路径分组：通过without指定：

可以通过 histogram_quantile函数做数据统计：可以用来统计百分位数：第一个参数是百分位，第二个histogram指标，这样计算出来的就是中位数，即P50。

分享之前和同事一起发现的坑：

在刚刚写的自定义 exporter上新增几个 histogram的样本点：

histogram的桶设置：

如果这样的话，所有指标都会直接进入到第一个桶，即0到2.5这个桶，如果我要计算中位数，那么这个中位数按照数学公式来算的话，肯定是在0到2.之间的，而且肯定是0.3到0.5之间。

我用 histogram_quantile函数计算下：计算结果是1.25，其实已经不对了。

我在计算下P99，等于2.475：

我的指标都是不大于1的，为啥算出来的P50和P99都这么离谱呢？

这是因为 Prometheus他是不保存你具体的指标数值的，他会帮你把指标放到具体的桶，但是他不会保存你指标的值，计算的分位数是一个预估的值，怎么预估呢？

就是假设每个桶内的样本分布是均匀的，线性分布来计算的，比如刚刚的P50，其实就是算排在第50%位置的样本值，因为刚刚所有的数据都落在了第一个桶，那么他在计算的时候就会假定这个 50%值在第一个桶的中点，他就会假定这个数就是0.5_ 2.5，P99就是第一个桶的99%的位置，他就会假定这个数就是 0.99 _ 2.5。

导致这个误差较大的原因就是我们的bucket设置的不合理。

重新定义桶：

上报数据：

重新计算 P50，P99：

桶设置的越合理，计算的误差越小。

六、Grafana可视化

除了可以利用 Prometheus提供的webUI可视化我们的指标外，还可以接入 Grafana来做指标的可视化。

第一步，对接数据源：

配置好 prometheus的地址：

第二步：创建仪表盘

编辑仪表盘：

在 metrics处编写PromQL即可完成查询和可视化：

仪表盘编辑完后，可以导出对应的 json 文件，方便下次导入同样的仪表盘：

以上是我之前搭建的仪表盘：

七、监控告警

AlertManager是 prometheus提供的告警信息下发组件，包含了对告警信息的分组，下发，静默等策略。配置完成后可以在webui上看到对应的告警策略信息。告警规则也是基于PromQL进行定制的。

编写告警配置：当 Http_srv这个服务挂了， Prometheus采集不到指标，并且持续时间1分钟，就会触发告警。

在 prometheus.yml中配置告警配置文件，需要配置上 alertmanager的地址和告警文件的地址。

配置告警信息，例如告警发送地址，告警内容模版，分组策略等都在 alertmanager的配置文件中配置：

当我kill进程：

prometheus已经触发告警：

在等待1分钟，如果持续还是符合告警策略，则状态为从 pending变为 FIRING会发送邮件到我的邮箱

此时我的邮箱收到了一条告警消息：

alertmanager也支持对告警进行静默，在 alertmanager的 WEBUI中配置即可：

间隔了4分钟，没有收到告警，静默生效：

一个小时没有收到告警信息：

参考资料：