prometheus 查询30d数据出现query processing would load too many samples问题

问题现象：prometheus查询长时间段的数据时出现query processing would load too many samples的问题，导致数据查询不出来。

问题原因：prometheus为了对自身进程进行保护，进行了限制，默认为50000000.可以通过--query.max-samples参数进行调整。

解决方式：

1.根据实际内存，对query.max-samples参数进行调整，谨慎操作。

2.进行record rule规则的配置。

在此对record rule规则配置进行详解：

2.1 先查看scrape_interval的值，默认为1m

2.2 进行设置record rule，可以看到使用name进行规则的命名，使用expr代表具体的规则信息。其中要注意的点为interval，默认值为全局的抓取间隔。

假设需要对metric http_status 进行统计，那么此时的规则应为sum by(统计维度) increase(http_status[time])。其中time的选取规则应至少为抓取间隔的两倍以上。

为什么聚合周期time应至少为抓取间隔的两倍以上呢？

假设抓取间隔为45s，如果使用1m的聚合周期，那么会造成数据的丢失，具体如下：

可以看到在第一次和第二次抓取间隔中都只有一个data point点，此时使用increase函数计算时返回为空，当第三次抓取间隔时会有两个data point的数据，所以此时会有正确的值。综上所述，会丢第一次和第二次的数据。

  

当time是抓取间隔的2倍为2m时，interval为全局的默认值1m，会是如下的情况：可以看到每个data point都统计了两次会导致最终的数据会重复统计两次，所以此时应该将interval修改为与time相同。

 2.3 通过配置的record rule规则进行积累一部分时间数据，使用grafana进行图表的展示

此时又会发现另外一个问题，在grafana中会频繁修改时间范围来查看数据趋势信息，grafana为了保证图的平滑性和查询的性能，会修改步长，如果聚合周期写死，当步

长远大于聚合周期时，选择大的查询范围会丢失很多的数据，此时的图表仅仅只剩趋势图的意义。

当step大于聚合周期时，会出现如图所示的情况，会漏掉一些data point点，导致漏掉数据。 

grafana显然已经考虑到了这种情况，定义了一个全局变量$__interval来解决此问题。当选择不同的范围时，聚合周期 $__interval和step会动态变化而解决问题。

建议使用

sum_over_time(metric{维度}[$__interval])

最后要注意另外一个问题，因为record rule设置的聚合周期为2m，所以设置grafana的min interval为2m。