你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!
发现
分享
文章
活动
登录
The requested URL was not found on this server. 不管你信不信,反正我是没找到
为什么kibana的visualize中Average计算数值有问题?
Kibana
| 作者
ljh
| 发布于2017年12月01日 | 阅读数:
6338
分享到:
QQ空间
新浪微博
微信
QQ好友
印象笔记
有道云笔记
对某一字段(number类型)进行计算,average的值明显不符合事实(明显偏大),请问这是为什么?
没有找到相关结果
已邀请:
与内容相关的链接
提交
2 个回复
kennywu76
-
Wood
赞同来自:
ljh
这个差异是多方面因素影响的结果。
首先ES的aggregation从性能方面考虑,并非全局精准计算,而是在各个shard分别计算,然后根据size设置,分别返回给自的TOP N,汇集到协调结点上,再做一个全局的Top N。 某个bucket的统计值在某个shard可能进入到TOP N,在另外一个shard却可能落在TOP N外面,所以得到的全局数据不是100%精准的,只是一个近似值。
其次,这个近似值的精度有多高,取决于所统计的bucket包含的文档数量。 文档数量越多,差异越小;文档数量越少,差异越大。
拿你这个具体的例子来说,你统计的是client ip的平均响应时间最长Top 5。 通常来说,对于一个访问量很大的网站,client ip的基数会很高,而单个client访问量不会很大。 这样按照client ip分bucket的时候,也许每个bucket里的文档数量比较少,可能只有几个或者几十个。 如果索引又划分了几个shard,某个client ip落在不同shard上的文档数量更加稀少。 当做平均响应时间统计时,因为要求取top 5,可能这个client ip有部分响应时间很快的请求落在某些shard上,没有进入这个shard的top 5,被舍弃掉了。 导致汇总后统计出来的结果偏大。 但是如果加了过滤条件,因为每个shard都只需要统计单个client ip的统计数据,就不再有数据被丢弃的问题, 之前没有进去top 5的响应时间也加入到统计里,拉低了整体的平均响应时间,实际上这时的统计数据是完全精准的。
想更清晰了解这个差异,可以在kibana上查看这个面板的原始request/response,可以看到,加了过滤器以后, bucket里的doc count比不加要多一些。
一般来说,对于基数不那么高的字段,比如http status code,或者server id进行同类统计,误差会非常非常小。
对于terms aggregation为什么是近似值的问题,参考:
search-aggregations-bucket-terms-aggregation-approximate-counts
ljh
赞同来自:
点击增加过滤条件后
这两个数值不相同是为什么?
要回复问题请先
登录
或
注册
发起人
ljh
活动推荐
Aug
15
2025 Zabbix 中国峰会
上海
·
8-15 周五
·
报名中
Oct
17
第27届 GOPS 全球运维大会暨研运数智化技术峰会 · 上海站
上海
·
10-17 周五
·
报名中
相关问题
kibana是否可以画关系网图?
kibana配置elasticsearchurl选项 怎么才能配置灵活。
kibana分析nginx日志,还在纠结用filebeat还是logstash
kibana中的Script Fields如何写?去判断已经有的一个字段,如果是1显示A,如果是2显示B。
kibana怎样配置向多个ES请求
docs.count与hits.total数值不一致,是什么原因导致
Kibana中如何查询展现非重复信息的数量???例如访问日志的IP地址数量
elasticsearch 如何聚合后计算,聚合后的值作为计算的条件
kibana界面汉化问题
我要对两个字段进行计算,然后对计算出来对新字段进行聚合
大家可以讲讲使用ELK架构吗?我打算大家kafka+rsyslog+logstash+elasticsearch+kibana,这个架构可行吗
问题状态
最新活动:
2017-12-01 11:28
浏览:
6338
关注:
4
人
2 个回复
kennywu76 - Wood
赞同来自: ljh
首先ES的aggregation从性能方面考虑,并非全局精准计算,而是在各个shard分别计算,然后根据size设置,分别返回给自的TOP N,汇集到协调结点上,再做一个全局的Top N。 某个bucket的统计值在某个shard可能进入到TOP N,在另外一个shard却可能落在TOP N外面,所以得到的全局数据不是100%精准的,只是一个近似值。
其次,这个近似值的精度有多高,取决于所统计的bucket包含的文档数量。 文档数量越多,差异越小;文档数量越少,差异越大。
拿你这个具体的例子来说,你统计的是client ip的平均响应时间最长Top 5。 通常来说,对于一个访问量很大的网站,client ip的基数会很高,而单个client访问量不会很大。 这样按照client ip分bucket的时候,也许每个bucket里的文档数量比较少,可能只有几个或者几十个。 如果索引又划分了几个shard,某个client ip落在不同shard上的文档数量更加稀少。 当做平均响应时间统计时,因为要求取top 5,可能这个client ip有部分响应时间很快的请求落在某些shard上,没有进入这个shard的top 5,被舍弃掉了。 导致汇总后统计出来的结果偏大。 但是如果加了过滤条件,因为每个shard都只需要统计单个client ip的统计数据,就不再有数据被丢弃的问题, 之前没有进去top 5的响应时间也加入到统计里,拉低了整体的平均响应时间,实际上这时的统计数据是完全精准的。
想更清晰了解这个差异,可以在kibana上查看这个面板的原始request/response,可以看到,加了过滤器以后, bucket里的doc count比不加要多一些。
一般来说,对于基数不那么高的字段,比如http status code,或者server id进行同类统计,误差会非常非常小。
对于terms aggregation为什么是近似值的问题,参考: search-aggregations-bucket-terms-aggregation-approximate-counts
ljh
赞同来自:
点击增加过滤条件后
这两个数值不相同是为什么?