Created attachment 1258244 [details] Screenshot of the metrics inconsistent CPU rendering Description of problem: On Web console pod metrics graph, if there is no CPU usage at given data point, the graph shows noting. For network we can see 0 is rendered so this is not a consistent behavior. Version-Release number of selected component (if applicable): atomic-openshift-3.4.1.7-1.git.0.81b9a4a.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. Open pod metrics graph on web console 2. Generate some load to the pod and stop the load 3. Monitor pod metrics graph. 0 CPU is not rendered Actual results: 0 CPU usage is not rendered, no on-mouse popup at the 0 CPU usage data point Expected results: 0 CPU usage is rendered as 0 CPU usage, on-mouse popup at the data point like network metrics Additional info:
Are you sure that the data point should be 0 or if there is no data point for that location? Can you inspect into the browser and get the network result being returned by Hawkular Metrics? To see if this is a problem with rendering in the console or a problem where the data does not exist in Hawkular Metrics
Yes it should be 0, I already attached screenshot including "CPU 0 network 0 usage data point". As we can see in the screenshot, the network graph goes down to 0 value but the CPU is just not rendered. I think this is web console graph rendering issue, not a Metrics data issue.
The console gets a list of values from Hawkular Metrics and uses those to populate the graph. It can either return a value or specify that there is no data entry for that particular segment. If there is no entry for that particular segment, then what the console is doing is correct. It has no information available to it, so it can't graph anything. The value at the point is unknown and setting it to 0 would be incorrect On the other hand, it could be that the console is considering a 0 value for the CPU to mean that there is no information available for that segment. Which would be incorrect as well. @tkimura the screenshot itself does not let us know what exactly is happening here, which is why I requested additional information.
@spadgett: do you know if the console is considering a 0 value for CPU to mean there is no information and so there is nothing graphed for that segment? Or is it properly looking at the empty=true attribute that Hawkular returns?
@mwringe We should be differentiating between null and 0 values, but I'll investigate further. We're not looking specifically at `empty`, however. https://github.com/spadgett/origin-web-console/blob/15ba89f164629cecc51a48721b805eaf3631695f/app/scripts/services/metricsCharts.js#L6-L9
I see the problem. This is a web console bug.
PR for master branch: https://github.com/openshift/origin-web-console/pull/1312 PR for enterprise-3.5: https://github.com/openshift/origin-web-console/pull/1313
Commit pushed to master at https://github.com/openshift/origin-web-console https://github.com/openshift/origin-web-console/commit/0f996755bf80967ad53cef1b35211a94501e7a03 Bug 1427360 - Correctly handle 0 values in MetricsService Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1427360
This has been merged into ocp and is in OCP v3.5.0.38 or newer.
I'm trying to reproduce the bug on OCP 3.4 and check the fix on OCP 3.5. Unfortunately, my env broke before I finished the checking, I will continue to test the bug tomorrow.
Checked on OCP 3.4, when value is 0, there is no line indicating the value, it's gaps between 0 with other value, refer to attachment "metrics-3.4". Checked on OCP 3.5, when value is 0, there is line indicating the value, and the chart would rise up from 0 to other value or drop down to 0 with line. But there is a small gap without line before/after the valley bottom, refer to attachments "metrics-3.5-one" and "metrics-3.5-two". Is the gap normal?
Created attachment 1260404 [details] metrics-3.4
Created attachment 1260405 [details] metrics-3.5-one
Created attachment 1260406 [details] metrics-3.5-two
The OCP 3.5 version I checked is v3.5.0.39
You're seeing this bug, which is an unrelated side effect of using a spline chart: https://bugzilla.redhat.com/show_bug.cgi?id=1375676
According to Comment12 and Comment17, the bug has been fixed, so move it to Verified.
Another minor display issue about unit. The unit preciseness is not consistent in one Y-axis. E.g. in comment 16's attachment, CPU preciseness is 4-digit decimal .0001, but it also displays 3-digit decimal .001. Is it intended or is consistent preciseness better?
This seems to be the c3.js default for tick formatting. I think it's reasonable. When we start changing the format of the ticks, it is easy to run into bugs where some ticks get cut off because there's not enough space or tick values appear to be repeated because we haven't given enough precision. I've found that we typically get the best results letting the charting library choose the values and format them.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:0884