背景
如下，我司的订单服务的支付和订单业务采用Prometheus配合Alertmanager来做报警处理。业务方会挑选一些比较重要的支付方式来做报警处理。大致就是一段时间内的支付量低于某一个阈值的时候就报警。
写成promql表达式如下
#pay_metrics就是支付的指标名称，pay_way就是支付方式
sum(increase(pay_metrics{pay_way="weixin"}[30m])) < 0
上面表达式的意思就是：如果微信这种支付方式的支付量在过去5分钟内的增量为0，那么就报警。业务方给了我们很多这种类似的报警规则，然后跑了很长一段时间，报警都工作得很好。
问题
某天业务收到某条报警信息，说是某某支付方式的报警有问题，他们说那个报警时间段内，他们是有支付成功的订单的，你这个报警有问题。然后我就会默默地查询了up指标(Prometheus中探活指标)，发现他们最近一段时间发布代码了。而他们的实例又是多实例的，发布的时候是一台台发布的，发布之后停留在内存中的指标数据都会丢失。然后在计算报警规则的时候可能会出现误报的情况。
然后我很自豪地跟他们的研发确认了发布的事情，然后很愉快地就去泡咖啡去了。
然后还没等我喝完咖啡，业务又找上我了，说还是有问题。但是这次没有发布。下面就开始了我得苦逼调查之旅。
调查
首先，我们明确一下问题的本质：业务在他们自己的订单存储中看到有支付订单的，但是还是报警了。其实就是业务数据和监控报警数据不一致。那这样的不一致就有可能是两面的原因
- 订单服务的研发在埋点支付数据的时候有bug
- Prometheus在计算报警规则的时候有问题
第一个问题，我让研发排查了，他们只有一个入口，而且不太可能会有问题。那我们先假设不是第一个问题。我们接着排查第二个问题。
Prometheus在计算的时候有问题。
下面我们来审视一下下面这个函数
#pay_metrics就是支付的指标名称，pay_way就是支付方式
sum(increase(pay_metrics{pay_way="weixin"}[5m])) < 0
我们只用了两个函数：sum和increase函数。sum比较简单，就是把指标相加，没什么好说的。但是increase()函数没有想象中那么简单，至少它要处理重启的情况。所以我就去prometheus中的issue搜搜了下。果然被我发现了一个类似的issue
increase() should consider creation of new timeseries as reset
如下
大概意思就是：如果一个时间序列之前不存在然后以值1出现，那么这时候Prometheus就不知道计数器是实际上是增加还是第一次被简单抓取到。那么increase()在处理的时候就直接返回0 了。
如下图，在T1时间计算increase()的时候,m1的增量为11，m2由于向前没有找到对应的指标数据，所以increase()直接返回0 了，这样在使用sum()函数计算增量和的时候就会丢失数据。
下面我们来看一下实际线上的情况，我画了两张图，左边的表达式是这样的（就是报警规则中的promql）
sum(increase(pay_metrics{pay_way="weixin"}[30m]))
右边的表达式是这样的(计算每个时间点的累计量)
sum(pay_metrics{pay_way="weixin"})
从上左边可以看到大概3点17分钟左右数量为0 ，这时候报警了，但是我们再看右边的图，在3点17分钟的时候向前推30分钟，这30分钟内实际是有数量变化的。由此可见，prometheus的这两种计算方式的计算结果是不一样的。直接sum的结果更接近于真实数据。
解决方案
那有没有什么好的解决方案呢？很多issue提倡能不能提供一个zero_increase()函数，或者加一个可以带默认值的increase()函数，让用户自己处理这种情况。我翻了下所有的issue，发现到目前为止官方还没有给出一个正式的解决方法。大家有兴趣可以翻看一下有关的issue
Proposal for improving rate/increase
那我们自己有没有可能通过各种骚操作得到我们想要的效果呢？反复查询后得到一种比较容易理解且相对比较精确的解决方案。如下
(sum(pay_metrics{pay_way="weixin"} or pay_metrics{pay_way="weixin"}*0) by(payMethod)-
sum(pay_metrics{pay_way="weixin"} offset 30m or pay_metrics{pay_way="weixin"}*0) by(pay_way))
思路也很简单就是sum(当前指标)-sum(30分钟之前的指标)就OK，然后再加上获取不到指标的情况下使用默认值0来代替。
但是这种解决方案也不是完美的，在重启的情况下有可能导致最终计算的差值是负数。不过在报警这种场景下完美只要不对这种情况下报警就可以了。
总结
increase()函数其实在大多数场景下是没啥问题的，只在下面两种场景下有可能有问题。
- 重启时间有点长
- 重启后很长时间某种label的指标数据才开始增加为0
解决方案：
- 在label组合比较少的情况下，可以都初始化所有label组合的指标数据为0
- 使用我们上面提到的promql表达式来解决（但是要注意重启后计算结果为负数的情况）
