关于如何在夜莺上报业务监控指标数据问题

[dulio]

我们这边打算把业务指标打点数据（像接口调用量、交易次数等）上报到夜莺系统。具体的方法是把指标数据使用http post方法推送到categraf的opentsdb协议接口上（/api/push/openfalcon），再通过n9e-server存储到后端prometheus里。

在上报单个metric时（如trade_num{type="pintuan"}），数据没有问题。
在上报多个用tag区分的metric里（如trade_num{type="single"}、trade_num{type=“pintuan"}）等，数据就会出现问题：在做sum(trade_num)操作时，将对2条曲线的的值进行合并，prometheus的数据曲线会出现问题，上报的点会多计算，导致最终出来的sum结果大于真正业务上报的值。

目前看这个问题主要出在prometheus的数据存储机制上（push 1个点时，拉取了多次，导致聚合计算时不准确），我们之前用influxdb的时候都没有出现类似问题（因为influxdb存储时，上报1个点就是一个点），不知道理解正确不正确。

请问各位大佬怎么处理类似业务指标上报场景的？

[UlricQin]

截个图提供一下现场

[dulio]

下面这个现场主要证明prometheus和influxdb统计数据的差异：
测试方法： prom/prometheus:v2.40.6容器部署的prometheus配置remotewrite到influxdb:1.8容器部署的influxdb实例上。
再用以下代码上报指标到prometheus的remote write接口上（排除中间组件干扰），并循环1s执行1次，rpm就是60：

String ip = "test" + new Random().nextInt(300); //随机生成0~300的tag值 
Types.Label inNameLavble = Types.Label.newBuilder().setName("__name__").setValue("z_bandwitdh_in_guage").build();//metrics name

Types.Label ipLabel = Types.Label.newBuilder().setName("ip").setValue(ip).build(); //放进tag标签里
Types.Label snmpIdLabel = Types.Label.newBuilder().setName("snmp_id").setValue("1").build();
Types.Label identLabel = Types.Label.newBuilder().setName("ident").setValue("thinkbook").build();

Types.Sample inSample = Types.Sample.newBuilder().setTimestamp(System.currentTimeMillis())
        .setValue(1.0D).build();

下面是具体的曲线：
prometheus的曲线

influxdb的曲线

非常明显，influxdb的曲线才是正确的数据

[UlricQin]

prometheus 的启动命令里增加这么一个参数：--query.lookback-delta=5s 看看效果如何

[dulio]

我直接调整完在原来曲线上看了，

这是调成5s的：

这是调成60s的：

好像还是有点点不太对

[UlricQin]

你是想计算一分钟总共有多少次调用？试试 sum(sum_over_time(z_bandwitdh_in_guage)[1m])

[dulio]

是的，果然可以了！

大佬能科普一下吗？小弟对prometheus的特性不是很熟悉

[UlricQin]

我也不太熟，应该是有一些数据外推的逻辑导致的，sum_over_time没有数据外推

[xiaoziv]

可以考虑原生的prometheus-sdk推送到categraf
falcon/influx的指标模型和prometheus指标模型差别很大
对于你的场景（像接口调用量、交易次数等）这种，以每15秒一次调用举例
在falcon/influx中，记录的时序指标(不经过聚合)应该是(t,1),(t+15s,1),(t+30s,1),(t+45s,1),(t+60s,1)...
此时的查询应该是sum_over_time(xxx[1m]),sum_over_time表示一分钟的时间维度上使用sum来聚合每个数据点,得到的数据是
(t,4),(t+1m,4)...

如果使用prometheus原生的counter统计，counter是累加的，记录的时序指标是(t,1),(t+15s,2),(t+30s,3),(t+45s,4),(t+60s,5)...
此时的查询应该是increase(xxx[1m])，表示一分钟的增量，查询到的数据也是(t,4),(t+1m,4)...

如果不加任何查询函数的话，prometheus不会知道查询到多条数据如果处理，印象中只展示step中最后一个查到的数据
对于你的场景，应该只会查到(t,1),(t+1m,1)...

prometheus counter这种设计有非常多的优势...具体可以自己研究下

[dulio]

我也找了一下相关资料，确实sum和sum_over_time的计算逻辑不同，还得继续加深prometheus的认识啊。感谢大哥普及