prometheus有丰富的运算和函数，给我们带来了丰富的展现形式。

丰富的表达的好处

相比于一般的apm系统，prometheus的采集和展示是分开的。
例如一般的apm系统会采集gc的指标，一般会计算成gc次数，而不是gc总数。这样的好处是采集的数据和页面展示的数据一致，页面的压力很小，直接展示出数据库里的信息就行（这里一般都是时序数据库）。
prometheus提供了丰富的表达以后，就可以直接把gc总数采集过来，然后自己写表达式来展示。例如可以写5分钟的差值，也可以记录10分钟的差值，或者2分钟的速率等等。
这两者非常明显的一个区别是采集数据的类型。前者是已经计算好了的数据，例如程序就算好了2分钟的差值，然后就上报了，后者则是没有处理的原始数据，最后在引擎那边做统一处理，相当于写sql一样，随意的更改表达式，就可以展示出不一样的结果。

常用的表达式

• 时间偏移
  针对同环比的需要，有的时候需要看一个周期内的对比，常见的这周的访问量和上周的对比。

http_requests_total offset 5m

offset后面跟着偏移量，这个是可以自己写的，prometheus对时间的表达和我们平常一样。

• 计算差值
  delta计算一个时间内的最后一条数据和第一条的数据的差值。

delta(cpu_temp_celsius{host="zeus"}[2h])

这个计算会做线性的补全，例如数据是10分钟的一个点，你计算25分钟的一个差值，但是25分钟只有2个点，他会根据这两个点的情况，推断出25分钟的差值的情况。这个在表达的时候算是一个小坑点，我们经常计算1分钟的一个情况，往往会算出一个稍微多一些的不怎么合理的值，主要就是他的线性推断导致的。但是看趋势的话是不影响的，如果拿具体值就不怎么合适了。

idelta和delta类似，他计算的是一个时间段内的最后两个值的差值。这个使用的场景比较特殊，一般是根据时间来的，这个没有推断的过程，所以我们可以用来计算1个多采集周期的的结果，一个多，不到2个，这样就能避免上面的情况了。delta选2个周期的时候，其实是最多2个点，正好两个周期的间隔，那么最好的情况就是两个点分别在起始和最后，但是大部分情况是中间1个点，后面那个点的周期没到，为了保证一定能采集到2个点的话，一般那个时间会选择两个采集周期多一些，不到3个周期的时候，这样就保证了肯定不会采集到3个点的情况，那么就是有且只有2个点，因为不到3个周期，所以不会出现3个点，超过2个周期了，怎么画间隔都会包含2个点。
注意delta是有推断的，所以选择不到3个采集周期的时候，一定会存在推断的情况在里面，数据有预测值。idelta就避免了这个问题，不过暂时只有根据周期设置的用法，其他用法都不适合。尤其是4个周期的时候，还是算最好2个，前面的数据一点意义没有了。

• 速率
  rate和delta的表达接近，但是是算速率的。下面就是5分钟内的http请求的速率。

rate(http_requests_total[5m])

这里大家也猜到了，这个表达是有推断的。所有只能用来看趋势
既然有rate,一定有irate，表达的含义也是一个时间段内的最后两个值的速率。
irate其实是可以用来算类似cpu使用率这种时间类型的，他的计算方式就是差值除以时间差。正好也是cpu使用率的表达式，cpu的指标为cpu使用时长，正好是使用率的计算。这个对所有时间型的都适用。

• 平均值等
  xxx_over_time
  xxx
  以上的xx可以替换为avg，sum等
  这两个表达有个区别
  xxx_over_time是一个指标的一段时间的结果
  xxx则是一个指标名的一个时间点的所有值的结果
  前者是时间段，后者是时间点，前者是指标的部分，后面是指标名的部分。

常用的就这些，如果想仔细研究可以看官方文档
官方文档链接