inversionhourglass commented on issue #10092: URL: https://github.com/apache/skywalking/issues/10092#issuecomment-1339091116
> That doesn't make sense. The precision relies on MAL, has nothing related to float or long. If the precision is completely controlled by MAL/OAL, then it is more appropriate to display the integer milliseconds of the latency (response time) on the UI, because the unit of latency itself is milliseconds and `readMetricsValue` returns a Long type value, so the decimal place has no value when displaying in milliseconds. Or latency increases the multiple when aggregated like sla and apdex to ensure the accuracy of average calculation, and finally divides by the multiple when visualizing. sla and apdex is multiplied by 10000 when aggregated https://github.com/apache/skywalking/blob/d6fa688ff8022c766cfaf3681c3b5f9113fc877f/oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/analysis/metrics/PercentMetrics.java#L64-L66 https://github.com/apache/skywalking/blob/d6fa688ff8022c766cfaf3681c3b5f9113fc877f/oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/analysis/metrics/ApdexMetrics.java#L92-L94 And then divided by 100 and 10000 when [visualizing](https://github.com/apache/skywalking-booster-ui/blob/1f98619a5b4ddbac4ac990dc5465b9b59bfa3349/src/hooks/useMetricsProcessor.ts#L473-L487) ```ts case Calculations.PercentageAvg: data = (val / 100).toFixed(2); break; case Calculations.Apdex: data = (val / 10000).toFixed(2); break; ``` The latency is collected and calculated in milliseconds of Long type, and displayed in milliseconds with two decimal places. Although there is no problem with the data, it feels a bit strange that a data without decimal places always displays these two decimal places. https://github.com/apache/skywalking/blob/d6fa688ff8022c766cfaf3681c3b5f9113fc877f/oap-server/server-starter/src/main/resources/oal/core.oal#L20 https://github.com/apache/skywalking/blob/d6fa688ff8022c766cfaf3681c3b5f9113fc877f/oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/analysis/metrics/LongAvgMetrics.java#L64-L66 From the previous description, it seems that this should be regarded as a visualization problem. However, if an API like `readMetricsValue` that calculates the average value can directly return a Float type value instead of rounding the average value, then the precision control can be more free. https://github.com/apache/skywalking/blob/f1c7e939831d6a2286c0f3108cddb9241898ec1a/oap-server/server-storage-plugin/storage-elasticsearch-plugin/src/main/java/org/apache/skywalking/oap/server/storage/plugin/elasticsearch/query/MetricsQueryEsDAO.java#L95-L98 `((Number) agg.get("value")).longValue()` will round the floating-point average value. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
