#Finding missing of latency break-down metrics (qos_latency_from) - Not present in Harvest2

1 messages · Page 1 of 1 (latest)

marble parrot
#

My team has an older version of Harvest in production, which contains a Grafana dashboard named "NetApp Detail: Volume dashboard" which included a Latency Breakdown panel that would report values such as qos_latency_from_backend , qos_latency_from_frontend, qos_latency_from_cluster , among others (check image for reference).

When investigating a similar metric in 25.05, we were not able to locate a similar metric or panel that would display a list of each latency source, even with the newest set of dashboards and all collectors enabled following official procedures from the documentation.

We have seen on this (discussion)[https://github.com/NetApp/harvest/issues/3423] that qos_detail_resource_latency and qos_detail_ops metrics were removed due to a skew in calculation. As those have a different name and context, I would also like to confirm rather or not this explains the missing aforementioned metrics. If so, by reporting this to the developers we would like to request a return qos_latency_from to keep fulfilling our business cases after we move to 25.05 in prod.

Thank you in advance for the excellent support by NetApp.

Best regards,

woven plaza
#

@marble parrot They should be the same metrics. Your screenshot shows Grafana legend names, so they can be what you have written in the legend names. You can check the panel query to verify. They were removed since Harvest version 25.02 due to the skew reasons mentioned in this GitHub issue. Below is the documentation for these metrics from Harvest version 24.11: Harvest 24.11.1 ONTAP Metrics.

marble parrot
#

@woven plaza Thank you for your response! With those metrics removed, are there any recommended metrics in 25.05 to emulate a similar break down of latency sources?

#

Or perhaps any plans to reinstate them in a future version

woven plaza
#

@marble parrot Unfortunately, there is no workaround possible in Harvest to collect these metrics. Due to the reasons mentioned in the issue shared earlier, we haven't found a way to collect these metrics correctly.