[jira] [Commented] (CASSANDRA-19666) Split the metrics collection into smaller groups

["David Capwell (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-19666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850463#comment-17850463 ] 

David Capwell commented on CASSANDRA-19666:
-------------------------------------------

bq. This may also be an option to consider for dynamically registering metric groups and in turn registering corresponding virtual tables and JmxMbean

What do you mean by this?  From the metrics point of view everything is dynamic.  The vtable logic "requires" knowing all types ahead of time and builds the vtables off of those types (even if they have not registered yet).  

From a UX point of view this is great as every instance will have the same vtables.  If we move to a "dynamic" model where we only create the vtables once the metric gets added then we fall prey to the cluster being heterogeneous with regard to what tables exists; which is super hard for users to deal with.

> Split the metrics collection into smaller groups
> ------------------------------------------------
>
>                 Key: CASSANDRA-19666
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-19666
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Observability/Metrics
>            Reporter: Maxim Muzafarov
>            Assignee: Maxim Muzafarov
>            Priority: Urgent
>             Fix For: 5.x
>
>
> Historically, all metrics are stored in a single collection indexed by a unique metric name - {{{}ConcurrentMap<String, Metric>{}}}. This storage technique doesn't offer any advantages over other options we might have below, and causes some performance and usability issues when we need to traverse this huge collection while filtering the metrics.
> The following possible solutions could be used: 
> - Use https://www.javadoc.io/doc/io.dropwizard.metrics/metrics-core/4.0.2/com/codahale/metrics/SharedMetricRegistries.html , which provides a way to store metrics in their dedicated groups;
> - Implement a hierarchical storage structure, based on the knowledge of how the metric key is formed. For example, https://the-asf.slack.com/archives/CK23JSY2K/p1716568216701789?thread_ts=1716324924.466269&cid=CK23JSY2K
> Each of the above options assumes, that the metric groups are statically registered and known at the time a node starts. This may also be an option to consider for dynamically registering metric groups and in turn registering corresponding virtual tables and JmxMbean. In the latter case, we'll need to implement the notification mechanism for the drivers, as they are not currently notified about newly created virtual tables.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org