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

Maxim Muzafarov commented on CASSANDRA-14572:
---------------------------------------------

Ok, so now the changes are completely ready. 
I've fixed all the CI issues related to the current patch and, with the help of 
Mick and Ekaterina, have done a full CI test. All tests look good, the OOM that 
was raised is not related to the patch as it also fails on the trunk, and I 
added tests to check that metrics are completely removed from the 
CassandraMetricsRegistry when the remove method is called.
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2602/workflows/978acbe2-6951-4954-a4b3-5fd8674c7dd4
https://app.circleci.com/pipelines/github/Mmuzaf/cassandra/561/workflows/e115a3dd-753b-4e02-94cd-e20feee1a207/jobs/46321

> Expose all table metrics in virtual table
> -----------------------------------------
>
>                 Key: CASSANDRA-14572
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14572
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Legacy/Observability, Observability/Metrics
>            Reporter: Chris Lohfink
>            Assignee: Maxim Muzafarov
>            Priority: Low
>              Labels: virtual-tables
>             Fix For: 5.x
>
>         Attachments: systemv_views.metrics_dropped_message.png
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> While we want a number of virtual tables to display data in a way thats great 
> and intuitive like in nodetool. There is also much for being able to expose 
> the metrics we have for tooling via CQL instead of JMX. This is more for the 
> tooling and adhoc advanced users who know exactly what they are looking for.
> *Schema:*
> Initial idea is to expose data via {{((keyspace, table), metric)}} with a 
> column for each metric value. Could also use a Map or UDT instead of the 
> column based that can be a bit more specific to each metric type. To that end 
> there can be a {{metric_type}} column and then a UDT for each metric type 
> filled in, or a single value with more of a Map<Text, Text> style. I am 
> purposing the column type though as with {{ALLOW FILTERING}} it does allow 
> more extensive query capabilities.
> *Implementations:*
> * Use reflection to grab all the metrics from TableMetrics (see: 
> CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric 
> implementors... but its reflection and a kinda a bad idea.
> * Add a hook in TableMetrics to register with this virtual table when 
> registering
> * Pull from the CassandraMetrics registery (either reporter or iterate 
> through metrics query on read of virtual table)



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

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to