1，前言

最近在做监控功能， 需要统计cdn用量，存储，数据库请求次数的需求，使用的方案是Prometheus push方法。有个功能获取一段时间内，按照指定step，将这个step中的数据汇聚（sum，min，max，avg，count），然后返回出去。目前的做法是<aggregation>_over_time()，然后指定时间段[60s]再指定时间点time，这个可以用来计算一小个step的值，但是从start到end有许多个小段，重复计算小段，然后再返回数据。很low，但是没有更好的办法了，先记录一下，也许以后再后头看就是很简单的问题了。

2，部署prometheus和pushgateway

3，简单介绍一下prometheus的pull和push模式

pull模式：客户端使用library，变成exporter，然后prometheus server定时从exporter pull数据。

push模式：使用pushgateway，所有客户端push数据到pushgateway，然后prometheus server定时从pushgateway pull数据。

比较：

push模式的缺点：采用pushgateway的方式，如果某一个上报方挂了，pushgateway无法感知上报方的状态，所以这时候如果不做任何操作，那么prometheus依旧会从pushgateway中获取到旧的、不正确的数据。

pull的优点：采用exporter的方式，如果某一个exporter挂掉了，那么prometheus就pull不到数据，那么时序数据库没有新的数据产生。这是正确的。

所以pull模式是prometheus的推荐模式。

至于为啥我要采用push模式呢，原因很简单：因为上报方很多，各个模块的代码不是很友好。

4，对pushgateway的认知

pushgateway算是一个缓冲区的角色，当prometheus从pushgateway pull走数据后，prometheus就会把这些数据存储在prometheus中，pv(PersistentVolume)或者本地磁盘中。所以如果pushgateway意外重启。那么可能会丢失一部分数据，不过这个可以通过配置pushgateway的存储来减少丢失的量。并且，如果pushgateway挂了，那么所有上报方的数据就都丢了。

5，还要注意的点

（1），prometheus从pushgateway pull数据的间隔，要和上报到pushgateway的间隔保持相同。如果不同，如果prometheus pull数据过于频繁，那么总是会拉取到重复的数据，如果上报到pushgateway过于频繁，那么会丢失数据，因为prometheus会以最后一次数据为准，而相同名称的数据会被替换掉。如果间隔相同，定时的时间偏移，最多只会丢失一次数据，是可以接受的。

（2），prometheus使用的是tsdb，也就是时序数据库，对同一个name的value不停的修改，就会在时间上产生一系列时序，prometheus就可以拿来统计这个时序的信息，比如rate，increase，<aggregation>_over_time()等。

（3），prometheus总是认为pushgateway的数据为新的，可用的数据，所以保证数据准确性的任务就交给了pushgateway。那么如果这时有个上报方挂了，并且不做任何操作的话，那么prometheus还是会从pushgateway那里获取到旧的，不正确的数据。所以当某客户端挂掉的时候，需要及时从pushgateway中删除此客户端上报的所有指标数据。或者把这个上报方的所有指标的value都设置为0也可以。至于如果判断客户端挂掉了，可以使用当前时间-减去最后一次上报时间是否大于上报间隔来判断。