[
https://issues.apache.org/jira/browse/CASSANDRA-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17121076#comment-17121076
]
Chris Lohfink commented on CASSANDRA-8612:
------------------------------------------
Yeah thats pretty much it. its gonna be bit of auditing the existing metrics
and adding where it only captures one case. If you are including latencies this
gets a bit more confusing. We have "read latencies" for single partition
latencies and "coordinator scan" latencies for range queries. Really it seems
like "read" should be them merged and maybe have a range/single specific one.
This could be like a gauge that merges the metrics at read time (like
keyspace/table parent latencies do). But if keeping latencies outta scope of
this I dont think it's necessary to support the 2 different types still.
For tombstones per read/sstables per read I think it makes more sense to just
have a single metric, and it seems to me more like a bug that C* doesnt even
include them in range reads.
> Read metrics should be updated on all types of reads
> ----------------------------------------------------
>
> Key: CASSANDRA-8612
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8612
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
> Reporter: Chris Lohfink
> Priority: Low
> Labels: lhf, metrics
> Attachments: 0001-Update-read-metrics-on-all-types-of-reads.patch
>
>
> Metrics like "sstables per read" are not updated on a range slice. Although
> separating things out for each type of read could make sense like we do for
> latencies, only exposing the metrics for one type can be a little confusing
> when people do a query and see nothing increases. I think its sufficient to
> use the same metrics for all reads.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
