[ZBX-5077] Calculation error in 95th percentile Created: 2012 May 27 Updated: 2017 May 30 Resolved: 2014 Dec 01 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Frontend (F) |
Affects Version/s: | None |
Fix Version/s: | 2.0.14rc1, 2.2.8rc1, 2.4.3rc1, 2.5.0 |
Type: | Incident report | Priority: | Critical |
Reporter: | Attilla de Groot | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 3 |
Labels: | graphs, percentile | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Attachments: | dump.txt graph_percentile.png |
Description |
Hi, I'd like to use the 95th percentile for billing purposes, but since the api or frontend doesn't support getting the value directly I have to calculate it mysql. But no matter how I calculate the value, it is always high than the value displayed in the graph. As you can see in the attached graph, the 95th percentile is 5,72Gb/s. But when I calculate (n=95/100*550+1/2) the percentile from the mysql data: mysql> select count(*) from history_uint where itemid = 39167; +----------+ | count(*) | +----------+ | 550 | +----------+ 1 row in set (0.00 sec) mysql> select * from history_uint where itemid = 39167 order by value desc limit 25,5; +--------+------------+------------+-----------+ | itemid | clock | value | ns | +--------+------------+------------+-----------+ | 39167 | 1337971067 | 5959796816 | 567141320 | | 39167 | 1337977367 | 5933375808 | 808058345 | | 39167 | 1337969567 | 5923229816 | 167354372 | | 39167 | 1337978567 | 5916897936 | 794447090 | | 39167 | 1337968967 | 5890801240 | 184057883 | +--------+------------+------------+-----------+ 5 rows in set (0.05 sec) You can have a discussion if you should the number up or down, but if I use my calculation to get the value displayed in the graph, it would actually be ~90th percentile: mysql> select * from history_uint where itemid = 39167 order by value desc limit 52,5 -> ; +--------+------------+------------+-----------+ | itemid | clock | value | ns | +--------+------------+------------+-----------+ | 39167 | 1338055967 | 5743761168 | 738804166 | | 39167 | 1338114768 | 5727882896 | 184340026 | | 39167 | 1338062867 | 5723286872 | 31496589 | | 39167 | 1338060467 | 5723070512 | 802785945 | | 39167 | 1338061667 | 5718211304 | 693634107 | +--------+------------+------------+-----------+ 5 rows in set (0.05 sec) This would create problems for people that display graphs to customers including the 95th percentile, but as in my case, bill on a higher value. I've included a dump of the data for this item. |
Comments |
Comment by Attilla de Groot [ 2012 May 30 ] |
Did anyone have a look at this issue to see if it is an incorrect calculation? |
Comment by Cristian [ 2013 Oct 21 ] |
Maybe your issue has to do with ? |
Comment by Attilla de Groot [ 2013 Oct 21 ] |
That is indeed the same issue. Nonetheless, still no response. |
Comment by Arvids Godjuks (Inactive) [ 2014 Nov 27 ] |
After a thorough review of the code and investigation into the data and graphs, I came to conclusion that this is not an error. Percentile calculation is done on a combined data set of all items present on the graph. In clients instance he is doing his calculation only by outgoing traffic, but the graph calculates the percentile on a combined data set of in and out traffic. This is why client gets a higher percentile than displayed in the graph - he does not take into account the "in" traffic data. We either document it, or implement the ZBXNEXT-1095 |
Comment by Attilla de Groot [ 2014 Nov 27 ] |
Arvids, "Percentile calculation is done on a combined data set of all items present on the graph", this is exactly the problem. If you want to do billing in a service provider setup, you would want yo have percentile only on the highest of the two values. Brian Talley explains this very well in 1095. |
Comment by Arvids Godjuks (Inactive) [ 2014 Nov 28 ] |
Fixed in dev branch svn://svn.zabbix.com/branches/dev/ZBX-5077 Calculation formula was fixed to use the "Nearest rank" method, but we are not changing the way we combine item data and calculate percentile by them, at least not as a bug report.
|
Comment by Arvids Godjuks (Inactive) [ 2014 Nov 28 ] |
(1) No translation changed sasha CLOSED |
Comment by Arvids Godjuks (Inactive) [ 2014 Dec 01 ] |
Merged into 2.0.14rc1 (r50929), 2.2.8rc1 (r50930), 2.4.3rc1 (r50931) and 2.5.0 (trunk) (r50932) |