nebula-stats-exproter统计数量与stats命令结果数据对账不符

环境

nebula 版本:v.2.0.1
部署方式(分布式 / 单机 / Docker / DBaaS):分布式:3节点3副本
是否为线上版本:Y
硬件信息
单机配置: 32核+128G内存+2TSSD*2

问题

1、通过两次stats job,求差值获取一段时间新增边数A;通过http结果获取新增边数(num_add_edges.sum.3600)并叠加该时间段内的值,求得新增边数B,新增边数A和B两者数值相差较大,B只有A的一半。
2、获取某个时刻,新增边统计指标如下。 按照我的理解sum.3600不应该为0,必须大于等于sum.600的值

name=num_add_edges.sum.60
value=2
name=num_add_edges.sum.600
value=13522
name=num_add_edges.sum.3600
value=0

看起来 sum.3600 小于 sum.600 是不应该的, @kevin.qiao 麻烦帮忙看一下哈?

好的,这里需要确认一下

你把执行命令 curl -G "http://ip:19779/stats?stats"|grep num_add_edges.sum 结果截图下

1 个赞

sorry,我之前没注意到标题里的信息,所以您的问题是,从 server http 获得的值是正确的,只是 exporter 里收集上来的不对对么?

这个命令肯定是没结果的啊 ,k,v都在两行,grep肯定出来不了东西

热乎的结果

value=0
name=num_add_vertices.sum.60
value=0
name=num_add_vertices.sum.600
value=46584
name=num_add_vertices.sum.3600
value=0

我发现问题了。value在上一行,name在下一行 :joy:

那就是只有一个问题,一段时间内两次stats结果差值和grafana中的累加值不一样

server http的结果看上去也不对啊

OK,第二个问题不是问题了。

第一个问题是 job stats 统计的 edge delta 数 A大于 :19779 上的 num add edge sum— B.

这里我理解任何一个单独 storage 上都没有全貌的 edge count 数据,应该是意料之中的。如果只有一个space 所有storage上的B的加和,应该是 A 乘以 replica factor数(乘以2 考虑 in&out)。 我理解的不对,等 @dingding 来解释哈。

master的修改了格式,原来旧的格式误导你了,你可以看下这个pr https://github.com/vesoft-inc/nebula-common/pull/570 ,新的格式变成这样了:

slow_query_latency_us.avg.5=0
num_slow_queries.rate.5=0
num_slow_queries.rate.60=0
num_slow_queries.sum.600=0
num_slow_queries.sum.3600=0

现在 metric 统计的 edge 和 vertex 的数量是向storage批量写入的次数,所以当你插入的query含有batch的时候,这个统计就不是实际的点边数量,而是batch数量(当然,边点时候,还有包含每条边的反向边)。假如你每个insert 语句只包含一个点或者一条边,那么,你把集群所有storage统计出来的数据就是点的插入数量,边的话,需要用总数除以2(因为有反向边)

1 个赞

那stats是统计边时 一个单向边算一条?双向边算两条,还是一条呢

看这两条边是否落在同一个part上面,假如不同part,就算两条,同一个part,就是一条 :rofl:

好的,不细问,还真的不清楚这个点

一个单向边 A->B, A、B在不同分区应该就只算一条边了吧 :joy:

是的,但是你通过这个指标拿,拿的是不同storage收到的处理。所以你会看到两个storage有这个统计。这个统计还是放在graphd统计比较准

不好意思, 我上面没有问清楚。stats命令的结果中,一个单向边 A->B, A、B在不同分区应该就只算一条边了吧 :joy:

引用 一个单向边 A->B, A、B在不同分区应该就只算一条边了吧 :joy:

job stats 是的

1 个赞

该话题在最后一个回复创建后7天后自动关闭。不再允许新的回复。

浙ICP备20010487号