Influxdb 如何使用XDB非负导数获得一致的值?

Influxdb 如何使用XDB非负导数获得一致的值?,influxdb,grafana,Influxdb,Grafana,使用grafana和influxdb,我试图显示某个计数器值的每秒速率。如果我使用非负导数(1s)函数,则速率的值似乎会根据grafana视图的时间宽度发生显著变化。我使用的是last选择器(但也可以使用max,因为它是一个计数器,所以值相同) 具体而言,我使用: 从…中选择非负导数(最后(“我的计数器”),1s 根据报告: InfluxDB计算按时间顺序排列的字段值之间的差异,并将这些结果转换为每单位的变化率 所以对我来说,这意味着在扩展时间视图时,给定点的值不应该有太大的变化,因为该值应该是

使用grafana和influxdb,我试图显示某个计数器值的每秒速率。如果我使用
非负导数(1s)
函数,则速率的值似乎会根据grafana视图的时间宽度发生显著变化。我使用的是
last
选择器(但也可以使用
max
,因为它是一个计数器,所以值相同)

具体而言,我使用:

从…中选择非负导数(最后(“我的计数器”),1s

根据报告:

InfluxDB计算按时间顺序排列的字段值之间的差异,并将这些结果转换为每单位的变化率

所以对我来说,这意味着在扩展时间视图时,给定点的值不应该有太大的变化,因为该值应该是每单位的变化率(在上面的查询示例中为1s)

在graphite中,它们具有特定的
perSecond
功能,该功能工作得更好:

perSecond(consolidateBy(我的计数器,'max'))


你知道我在上面的inflow查询中做错了什么吗?

如果你想要每秒的结果不变,你需要
按时间分组(1s)
。这将为您提供准确的
perSecond
结果

考虑以下示例:

假设计数器的值在每秒钟都发生这样的变化

0s → 1s → 2s → 3s → 4s
1  → 2  → 5  → 8  → 11
根据我们对上述序列的分组方式,我们将看到不同的结果

考虑这样一种情况,我们将事物分组为
2s
bucket

 0s-2s   →    2s-4s
(5-1)/2  →  (11-5)/2
   2     →      3
相对于
1s
bucket

 0s-1s  →  1s-2s  →  2s-3s  →  3s-4s
(2-1)/1 → (5-2)/1 → (8-5)/1 → (11-8)/1
   1    →    3    →    3    →    3
寻址

所以对我来说,这意味着在扩展时间视图时,给定点的值不应该有太大的变化,因为该值应该是每单位的变化率(在上面的查询示例中为1s)

每单位的
变化率
是一个标准化因子,与
分组时间单位无关。当我们将导数间隔更改为
2s
时,解释前面的示例可能会提供一些见解

确切的方程式是

∆y/(∆x/tu)
考虑这样一种情况,我们将事物分组到
1s
桶中,其导数间隔为
2s
。我们应该看到的结果是

 0s-1s    →  1s-2s    →  2s-3s    →  3s-4s
2*(2-1)/1 → 2*(5-2)/1 → 2*(8-5)/1 → (11-8)/1
   2      →    6      →    6      →    6
这似乎有点奇怪,但是如果你考虑一下这句话,它应该是有意义的。当我们指定一个
2s
的导数区间时,我们要求的是
2s
的变化率对于
1s
分组依据
桶的变化率

如果我们将类似的推理应用于衍生间隔为
2s
2s
桶的情况,则

 0s-2s     →    2s-4s
2*(5-1)/2  →  2*(11-5)/2
   4       →      6

这里我们要问的是
2s
的变化率对于
2s
组的变化率是多少,在第一个区间内
2s
的变化率是
4
,第二个区间内
2s
的变化率是
6
@Michael Desa给出了一个极好的结论解释

我想用我们公司感兴趣的一个非常常见的指标的解决方案来补充这个答案:“特定测量字段上的最大“每秒操作”值是多少?”

我将使用我们公司的一个真实例子

情景背景 我们将大量数据从RDBMS发送到。传输数据时,我们会跟踪5个计数器:

  • TipTrgUp
    ->通过业务触发器(存储过程)进行更新
  • TipTrgRm
    ->通过业务触发器(存储过程)删除
  • TipRprUp
    ->通过无人值守自动修复批处理进行更新
  • tiprrm
    ->通过无人值守的自动修复批处理删除
  • TipDmpUp
    ->通过批量转储进程进行更新
  • 我们制作了一个度量收集器,以1秒的间隔(可配置)将这些计数器的当前状态发送到XDB

    Grafana图1:低分辨率,无真正的最大操作 下面是grafana查询,它很有用,但在缩小时不会显示真正的最大操作数(我们知道,在正常工作日,当没有进行特殊转储或维护时,它将达到大约500个操作数,否则将达到数千个操作数):

    选择
    非负导数(最大(TipTrgUp),1s)为“更新/TipTrgUp”
    ,非负导数(最大值(TipTrgRm),1s)为“移除/TipTrgRm”
    ,非负导数(最大(TipRprUp),1s)为“自动修复向上/TipRprUp”
    ,非负导数(最大(TIPRRM),1s)为“自动修复rm/TIPRRM”
    ,非负导数(最大(TipDmpUp),1s)为“dump/TipDmpUp”
    从“$rp”.“redis\u flux\u transid-d-s”
    哪里
    主机=~/$server$/
    和$timeFilter
    按时间分组($间隔),*填充(空)
    
    旁注:
    $rp
    是保留策略的名称,以grafana为模板。我们使用CQ将样本缩减为保留策略,保留时间更长。还要注意作为派生参数的
    1s
    :它是必需的,因为使用GROUP BY时默认值是不同的。这在XDB文档中很容易被忽略

    24小时后看到的图表如下所示:

    如果我们只使用1s的分辨率(如@Michael Desa所建议的),那么大量数据将从XDB传输到客户端。它工作得相当好(大约10秒),但对我们来说太慢了

    Grafana graph 2:低分辨率和高分辨率,真正的最大运算量,低性能 但是,我们可以使用子查询将真正的maxops添加到此图中,这是一个轻微的改进。传输到客户机的数据要少得多,但XDB服务器必须进行大量的数字运算。系列B(别名中带有
    maxops
    前缀):

    选择
    最大值(subTipTrgUp)作为最大值
    ,max(subTipTrgRm)作为maxopsTipTrgRm
    ,max(subTipRprUp)作为maxopsRprUp
    ,max(subtiprrm)作为maxopstiprrm
    ,max(subTipDmpUp)作为maxopsTipDmpUp
    从(
    s
    
    SELECT derivative(mean("mem.gc.count"), $__interval) FROM "influxdb"
    WHERE $timeFilter GROUP BY time($__interval) fill(null)