Difference between batch reads/writes and latency read/write ops_per_sec from a monitoring perspective

We are currently running CE v3.16.0.6 and use GitHub - aerospike-community/aerospike-graphite: Aerospike monitoring for Graphite - a community driven open source project to send aerospike metrics to our graphite setup; these metrics ultimately get visualized in dashboards in Grafana. I have dashboard that is akin to the Cluster Throughput panel on AMC (e.g. it breaks down the reads and writes per second for the cluster.). I was using the latency.*.read.ops_per_sec and latency.*.write.ops_per_sec for this dashboard and when we had an application that changed the client to performing batch reads. I noticed a drop in latency.*.read.ops_per_sec. Is there a reason why batch reads are not included the latency.*.read.ops_per_sec? I see them being reported separately under the batch_sub_read_(success|error|timeout) metrics. Should I just update my dashboard to add the batch_sub_read_(success|error|timeout) metrics to the latency.*.read.ops_per_sec or track those separately?

The batch reads are indeed separate from the individual read transactions when it comes to metrics. I am not sure whether there is a reason other than the transaction flow being different at the high level. It can also be an advantage to have this separation which can help troubleshoot potential bottlenecks.

thanks @meher. I will adjust my dashboards accordingly.

This topic was automatically closed 84 days after the last reply. New replies are no longer allowed.