为什么Prometheus的increase()函数未按预期处理counter重置

直方图自动生成的maf_http_req_time_sum属于标准counter类型，不存在类型不符合increase()函数要求的问题，查询结果偏低的常见原因如下：

• 消失的时间序列增量漏算
  当前使用的sum(increase(maf_http_req_time_sum[7d]))是先对每个带独立标签的时间序列计算7天增量再求和，如果该指标的标签值发生变更、对应实例下线等情况，导致部分时间序列在7天窗口内停止上报，这部分序列的最后一段增量不会被计入increase结果，直接拉低总统计值。
• 查询窗口未完整覆盖重置前后采样点
  increase()仅计算查询时间范围内的采样点增量，若7天窗口的首个采样点已经是counter重置之后的数值，重置前从0到741的全量增量就会被完全漏算，最终结果只会包含重置后的87以及窗口内部分未被覆盖的旧增量。
• 单采样点序列增量被丢弃
  Prometheus的increase()函数要求时间范围内至少存在2个采样点才会执行增量计算，如果某条时间序列在7天窗口内仅上报过1次，该序列的增量会被直接判定为0，进一步导致统计值偏低。
• counter重置未被正确识别
  如果指标采样间隔过长，重置前后的采样点间隔超出判定阈值，或是指标本身存在主动下调数值的逻辑，也会导致重置时的增量未被计入最终结果。

• 执行increase(maf_http_req_time_sum[7d])查询所有维度的增量，手动求和后与sum()返回值对比，确认是否存在消失序列漏算的问题
• 执行sum(resets(maf_http_req_time_sum[7d]))查看Prometheus识别到的counter重置次数，与实际观察到的重置次数对比，若次数不符可适当拉长查询窗口，确保窗口覆盖重置前的最早采样点和重置后的最新采样点
• 可改用手动补全逻辑计算总增量，参考语句：sum(maf_http_req_time_sum) - sum(maf_http_req_time_sum offset 7d) + sum(resets(maf_http_req_time_sum[7d]) * <重置前峰值>)，其中<重置前峰值>替换为实际观察到的重置前数值即可

内容的提问来源于stack exchange，提问作者jhnclvr