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
好的，这里需要确认一下
你把执行命令 curl -G "http://ip:19779/stats?stats"|grep num_add_edges.sum 结果截图下
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在下一行 
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（因为有反向边）
那stats是统计边时 一个单向边算一条？双向边算两条，还是一条呢
看这两条边是否落在同一个part上面，假如不同part，就算两条，同一个part，就是一条 
好的，不细问，还真的不清楚这个点
一个单向边 A->B, A、B在不同分区应该就只算一条边了吧
是的，但是你通过这个指标拿，拿的是不同storage收到的处理。所以你会看到两个storage有这个统计。这个统计还是放在graphd统计比较准
不好意思， 我上面没有问清楚。stats命令的结果中，一个单向边 A->B, A、B在不同分区应该就只算一条边了吧 
引用 一个单向边 A->B, A、B在不同分区应该就只算一条边了吧
job stats 是的
该话题在最后一个回复创建后7天后自动关闭。不再允许新的回复。