[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824412#comment-17824412
]
Stefan Miklosovic edited comment on CASSANDRA-14572 at 3/7/24 1:25 PM:
---
[CASSANDRA-14572|https://github.com/instaclustr/cassandra/tree/CASSANDRA-14572]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 43s
✓ j17_cqlsh_dtests_py311 6m 40s
✓ j17_cqlsh_dtests_py311_vnode 7m 0s
✓ j17_cqlsh_dtests_py386m 29s
✓ j17_cqlsh_dtests_py38_vnode 7m 28s
✓ j17_cqlshlib_cython_tests 8m 4s
✓ j17_cqlshlib_tests 7m 12s
✓ j17_dtests 37m 20s
✓ j17_dtests_vnode34m 14s
✓ j17_unit_tests 11m 47s
✓ j17_utests_oa13m 2s
✕ j17_jvm_dtests 28m 11s these are
both ok, there is just a flaky one ruining all job
✕ j17_jvm_dtests_vnode22m 53s
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3960/workflows/6095a8a5-a743-49f9-82ac-f22da431697e]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3960/workflows/cab3a70e-feba-4cca-9f48-d3a067759404]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3960/workflows/7eac0186-fecf-4a43-8bfd-d83fc627414e]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3960/workflows/db402d02-1e92-41e1-b701-eae37db624fe]
was (Author: smiklosovic):
[CASSANDRA-14572|https://github.com/instaclustr/cassandra/tree/CASSANDRA-14572]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 43s
✓ j17_cqlsh_dtests_py311 6m 40s
✓ j17_cqlsh_dtests_py311_vnode 7m 0s
✓ j17_cqlsh_dtests_py386m 29s
✓ j17_cqlsh_dtests_py38_vnode 7m 28s
✓ j17_cqlshlib_cython_tests 8m 4s
✓ j17_cqlshlib_tests 7m 12s
✓ j17_dtests 37m 20s
✓ j17_dtests_vnode34m 14s
✓ j17_unit_tests 11m 47s
✓ j17_utests_oa13m 2s
✕ j17_jvm_dtests 28m 11s
✕ j17_jvm_dtests_vnode22m 53s
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3960/workflows/6095a8a5-a743-49f9-82ac-f22da431697e]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3960/workflows/cab3a70e-feba-4cca-9f48-d3a067759404]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3960/workflows/7eac0186-fecf-4a43-8bfd-d83fc627414e]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3960/workflows/db402d02-1e92-41e1-b701-eae37db624fe]
> 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: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 7h
> 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),
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824131#comment-17824131
]
Stefan Miklosovic edited comment on CASSANDRA-14572 at 3/6/24 6:50 PM:
---
org.apache.cassandra.metrics.ClientRequestRowAndColumnMetricsTest
org.apache.cassandra.metrics.ClientRequestMetricsTest
org.apache.cassandra.metrics.CassandraMetricsRegistryTest
org.apache.cassandra.metrics.CQLMetricsTest
org.apache.cassandra.metrics.BatchMetricsTest
org.apache.cassandra.db.virtual.CollectionVirtualTableAdapterTest
[CASSANDRA-14572|https://github.com/instaclustr/cassandra/tree/CASSANDRA-14572]
{noformat}
java17_pre-commit_tests
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
✓ j11_build4m 34s
✓ j11_unit_tests_repeat 43m 51s
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3957/workflows/492749f5-a21c-4de7-bb00-31a1fd7026e5]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3957/workflows/a7d5534c-d510-44fd-aaeb-4ff13ae6f7c8]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3957/workflows/5a649d88-d6d6-45d9-8cb3-975a20ad]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3957/workflows/89ad653d-c169-419c-9c38-3a16a6deb4bc]
was (Author: smiklosovic):
[CASSANDRA-14572|https://github.com/instaclustr/cassandra/tree/CASSANDRA-14572]
{noformat}
java17_pre-commit_tests
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
✓ j11_build4m 34s
✓ j11_unit_tests_repeat 43m 51s
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3957/workflows/492749f5-a21c-4de7-bb00-31a1fd7026e5]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3957/workflows/a7d5534c-d510-44fd-aaeb-4ff13ae6f7c8]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3957/workflows/5a649d88-d6d6-45d9-8cb3-975a20ad]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3957/workflows/89ad653d-c169-419c-9c38-3a16a6deb4bc]
> 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: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 7h
> 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 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:
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822060#comment-17822060
]
Stefan Miklosovic edited comment on CASSANDRA-14572 at 2/29/24 10:10 AM:
-
Put more comments in there. I still do not think that we should add any
generation scripts / helpers ... I mean, why? It is great that you generated
that with the help of some tooling but once this is all done, why do we need to
commit that too? From now on, it will be just about simple addition of two
classes, row (which you need to write anyway) and its walker which is pretty
straightforward to me.
was (Author: smiklosovic):
Put more comments in there. I still do not think that we should add any
generation scripts / helpers ... I mean, why? It is great that you generated
that with the help of some tooling but once this is all done, why do we need to
commit that too? From now on, it will be just about simple addition of two
classes, row and its walker which is pretty straightforward to me.
> 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: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 5.5h
> 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 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822060#comment-17822060
]
Stefan Miklosovic edited comment on CASSANDRA-14572 at 2/29/24 10:09 AM:
-
Put more comments in there. I still do not think that we should add any
generation scripts / helpers ... I mean, why? It is great that you generated
that with the help of some tooling but once this is all done, why do we need to
commit that too? From now on, it will be just about simple addition of two
classes, row and its walker which is pretty straightforward to me.
was (Author: smiklosovic):
Put more comments in there. I still do not think that we should add any
generation scripts / helpers ... I mean, why? It is great that you generated
that with the help of some tooling but one this is all done, why do we need to
commit that too? From now on, it will be just about simple addition of two
classes, row and its walker which is pretty straightforward to me.
> 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: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 5.5h
> 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 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820831#comment-17820831
]
Maxim Muzafarov edited comment on CASSANDRA-14572 at 2/28/24 6:06 PM:
--
These pull requests compare approaches with and without the annotation
processor (the diff in the source code lines is not too big).
With the annotation processor:
https://github.com/apache/cassandra/pull/2958/files
+3,646 −419
Without the annotation processor:
https://github.com/apache/cassandra/pull/3152/files
+3,884 −418
was (Author: mmuzaf):
These pull requests compare approaches with and without the annotation
processor (the diff in the source code lines is not too big).
With the annotation processor:
https://github.com/apache/cassandra/pull/2958/files
+3,646 −419
Without the annotation processor:
https://github.com/apache/cassandra/pull/3137/files
+3,884 −418
> 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: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 3h
> 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 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17811370#comment-17811370
]
Maxim Muzafarov edited comment on CASSANDRA-14572 at 1/26/24 7:12 PM:
--
[~mck] I've fixed your comments.
[~djoshi], [~cnlwsu], [~smiklosovic], [~aleksey] Would you mind looking at
these changes? I have a lot of hope that we can make some progress here, I've
spent a lot of time polishing it :-)
https://github.com/apache/cassandra/pull/2958/files
was (Author: mmuzaf):
[~mck] I've fixed your comments.
[~djoshi], [~cnlwsu], [~smiklosovic], [~aleksey] Would you mind looking at
these changes? I have a lot of hope that we can make some progress here, I've
spent a lot of time polishing them :-)
https://github.com/apache/cassandra/pull/2958/files
> 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: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 2h 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 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809602#comment-17809602
]
Maxim Muzafarov edited comment on CASSANDRA-14572 at 1/22/24 8:11 PM:
--
I think we can add a rate limiter or guardrail in a follow-up issue to prevent
unwise use of metric polling, but currently, I think it is beyond the issue's
scope as there should be no difference in a pattern usage for JMX and/or CQL
polling. Accessing a metric by metric name is super efficient while selecting a
large range of metrics from a large metrics set is not efficient since it
requires the MetrciRegisty collection to be filtered each time for the required
subset of metrics, but it doesn't cause any problems or OOMs.
As I mentioned earlier, I've created 1000 keyspaces with one table each,
resulting in 77k metrics, you can check [the
latest|https://issues.apache.org/jira/browse/CASSANDRA-14572?focusedCommentId=17800388=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17800388]
benchmark for polling a metric.
The JFR for that run is here:
[^flight_recording_1270017199_13.jfr]
The
{code:java}
cqlsh> select count(*) from system_metrics.keyspace_group ;
count
---
77462
(1 rows)
{code}
The query that I used selects a metric by partition:
{code:java}
select * from system_metrics.keyspace_group where name = ?
{code}
was (Author: mmuzaf):
I think we can add a rate limiter or guardrail in a follow-up issue to prevent
unwise use of metric polling, but currently, I think it is beyond the issue's
scope as there should be no difference in a pattern usage for JMX and/or CQL
polling. Accessing a metric by metric name is super efficient while selecting a
large range of metrics from a large metrics set is not efficient since it
requires the MetrciRegisty collection to be filtered each time for the required
subset of metrics, but it doesn't cause any problems or OOMs.
As I mentioned earlier, I've created 1000 keyspaces with one table, which
resulted in 77k metrics you can check the latest benchmark for polling a
metric.
The JFR for that run is here:
[^flight_recording_1270017199_13.jfr]
The
{code:java}
cqlsh> select count(*) from system_metrics.keyspace_group ;
count
---
77462
(1 rows)
{code}
The query that I used selects a metric by partition:
{code:java}
select * from system_metrics.keyspace_group where name = ?
{code}
> 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: flight_recording_1270017199_13.jfr, keyspayces_group
> responses times.png, keyspayces_group summary.png, select keyspaces_group by
> string prefix.png, select keyspaces_group compare with wo.png, select
> keyspaces_group without value.png, systemv_views.metrics_dropped_message.png,
> thread_pools benchmark.png
>
> Time Spent: 1.5h
> 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 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800171#comment-17800171
]
Maxim Muzafarov edited comment on CASSANDRA-14572 at 12/24/23 1:46 PM:
---
Hi [~djoshi],
You're right, it is better to discuss the solution design first, and only then
dig into the source code.
1. I've managed to remove the GC pressure in the last few commits, so it should
now be fine to pull a metric value from the virtual table by metric name, but
we still have to iterate over a collection to find a metric.
The CollectionVirtualTableAdapter is a general approach to export any internal
collections as virtual tables, it accepts the Iterable interface as a data
container. We can also implement narrower adapters e.g. one that accepts
Map as a data container, and if we solidify the vt model that the
map key is always equal to the virtual table partition key (which is at least
true for the metric collections), pulling will be slightly faster then. Such a
trade-off depends on the usage pattern for virtual tables with metrics, pulling
metrics every ~10-20 sec should be acceptable with the Iterable interface
(histograms are still expensive to pull often).
2. This is another compromise we have to make, each of these options has its
pros and cons. I see three options here:
- Commit the RawWalker implementations along with the model classes. Pros:
classes are plain, keep the ant build simple, easy to debug. Cons: maintain
cost if the RawWalker interface changes often, increase the amount of changes
in the patch.
- use an annotation processor to generate RawWalker implementation. Pros: no
boilerplate implementation in the code, uses plain java, no extra dependency.
Cons: additional code to maintain, increase the build complexity.
- use a templating engine (e.g. the [javapoet,
|https://github.com/square/javapoet]you meant something like that, right?) to
generate implementations. Pros: no boilerplate code, a framework to create
classes. Cons: increase the code complexity as we have to be aware of a new
library, an extra dependency.
I assume that the RawWalker interface is relatively stable and rarely changes,
so we don't need to change the implementation too often and/or generate it on
the fly. In case we want to add a new column to a model, changes are also easy.
So, if we want to remove the annotation processor, I would rather choose the
first option.
This is still a compromise, so please share your thoughts.
Here is how the generated code looks like:
{code:java}
public class MetricRowWalker implements RowWalker
{
/** {@inheritDoc} */
@Override public void visitMeta(RowWalker.MetadataVisitor visitor)
{
visitor.accept(Column.Type.PARTITION_KEY, "name",
java.lang.String.class);
visitor.accept(Column.Type.REGULAR, "scope", java.lang.String.class);
visitor.accept(Column.Type.REGULAR, "type", java.lang.String.class);
visitor.accept(Column.Type.REGULAR, "value", java.lang.String.class);
}
/** {@inheritDoc} */
@Override public void visitRow(MetricRow row, RowWalker.RowMetadataVisitor
visitor)
{
visitor.accept(Column.Type.PARTITION_KEY, "name",
java.lang.String.class, () -> row.name());
visitor.accept(Column.Type.REGULAR, "scope", java.lang.String.class, ()
-> row.scope());
visitor.accept(Column.Type.REGULAR, "type", java.lang.String.class, ()
-> row.type());
visitor.accept(Column.Type.REGULAR, "value", java.lang.String.class, ()
-> row.value());
}
/** {@inheritDoc} */
@Override
public int count(Column.Type type)
{
switch (type)
{
case PARTITION_KEY: return 1;
case REGULAR: return 3;
case CLUSTERING: return 0;
default: throw new IllegalStateException("Unknown column type: " +
type);
}
}
}
{code}
was (Author: mmuzaf):
Hi [~djoshi],
You're right, it is better to discuss the solution design first, and only then
dig into the source code.
1. I've managed to remove the GC pressure in the last few commits, so it should
now be fine to pull a metric value from the virtual table by metric name, but
we still have to iterate over a collection to find a metric.
The CollectionVirtualTableAdapter is a general approach to export any internal
collections as virtual tables, it accepts the Iterable interface as a data
container. We can also implement narrower adapters e.g. one that accepts
Map as a data container, and if we solidify the vt model that the
map key is always equal to the virtual table partition key (which is at least
true for the metric collections), pulling will be slightly faster then. Such a
trade-off depends on the usage pattern for virtual tables with metrics, pulling
metrics every ~10-20 sec should be acceptable with the Iterable interface
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800171#comment-17800171
]
Maxim Muzafarov edited comment on CASSANDRA-14572 at 12/24/23 12:00 PM:
Hi [~djoshi],
You're right, it is better to discuss the solution design first, and only then
dig into the source code.
1. I've managed to remove the GC pressure in the last few commits, so it should
now be fine to pull a metric value from the virtual table by metric name, but
we still have to iterate over a collection to find a metric.
The CollectionVirtualTableAdapter is a general approach to export any internal
collections as virtual tables, it accepts the Iterable interface as a data
container. We can also implement narrower adapters e.g. one that accepts
Map as a data container, and if we solidify the vt model that the
map key is always equal to the virtual table partition key (which is at least
true for the metric collections), pulling will be slightly faster then. Such a
trade-off depends on the usage pattern for virtual tables with metrics, pulling
metrics every ~10-20 sec should be acceptable with the Iterable interface
(histograms are still expensive to pull often).
2. This is another compromise we have to make, each of these options has its
pros and cons. I see three options here:
- Commit the RawWalker implementations along with the model classes. Pros:
classes are plain, keep the ant build simple, easy to debug. Cons: maintain
cost if the RawWalker interface changes often, increase the amount of changes
in the patch.
- use an annotation processor to generate RawWalker implementation. Pros: no
boilerplate implementation in the code, uses plain java, no extra dependency.
Cons: additional code to maintain, increase the build complexity.
- use a templating engine (e.g. the [javapoet,
|https://github.com/square/javapoet]you meant something like that, right?) to
generate implementations. Pros: no boilerplate code, a framework to create
classes. Cons: increase the code complexity as we have to be aware of a new
library, an extra dependency.
I assume that the RawWalker interface is relatively stable and rarely changes,
so we don't need to change the implementation too often and/or generate it on
the fly. In case we want to add a new column to a model, changes are also easy.
So, if we want to remove the annotation processor, I would rather choose the
first option.
This is still a compromise, so please change your thoughts.
Here is how the generated code looks like:
{code:java}
public class MetricRowWalker implements RowWalker
{
/** {@inheritDoc} */
@Override public void visitMeta(RowWalker.MetadataVisitor visitor)
{
visitor.accept(Column.Type.PARTITION_KEY, "name",
java.lang.String.class);
visitor.accept(Column.Type.REGULAR, "scope", java.lang.String.class);
visitor.accept(Column.Type.REGULAR, "type", java.lang.String.class);
visitor.accept(Column.Type.REGULAR, "value", java.lang.String.class);
}
/** {@inheritDoc} */
@Override public void visitRow(MetricRow row, RowWalker.RowMetadataVisitor
visitor)
{
visitor.accept(Column.Type.PARTITION_KEY, "name",
java.lang.String.class, () -> row.name());
visitor.accept(Column.Type.REGULAR, "scope", java.lang.String.class, ()
-> row.scope());
visitor.accept(Column.Type.REGULAR, "type", java.lang.String.class, ()
-> row.type());
visitor.accept(Column.Type.REGULAR, "value", java.lang.String.class, ()
-> row.value());
}
/** {@inheritDoc} */
@Override
public int count(Column.Type type)
{
switch (type)
{
case PARTITION_KEY: return 1;
case REGULAR: return 3;
case CLUSTERING: return 0;
default: throw new IllegalStateException("Unknown column type: " +
type);
}
}
}
{code}
was (Author: mmuzaf):
Hi [~djoshi],
You're right, it is better to discuss the solution design first, and only then
dig into the source code.
1. I've managed to remove the GC pressure in the last few commits, so it should
now be fine to pull a metric value from the virtual table by metric name, but
we still have to iterate over a collection to find a metric, which again is not
so efficient as JMX MBeans as it has direct reference to a metric instance, and
no CQL overhead.
The CollectionVirtualTableAdapter is a general approach to export any internal
collections as virtual tables, it accepts the Iterable interface as a data
container. We can also implement narrower adapters e.g. one that accepts
Map as a data container, and if we solidify the vt model that the
map key is always equal to the virtual table partition key (which is at least
true for the metric collections), pulling will be slightly faster then. Such a
trade-off depends on the usage
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792804#comment-17792804
]
Stefan Miklosovic edited comment on CASSANDRA-14572 at 12/4/23 12:50 PM:
-
By the way, when I do this
{code}
cqlsh> select * from system_views.metrics_table where scope =
'system_auth.roles' and type = 'counter';
name
| scope | type| value
--+---+-+---
org.apache.cassandra.metrics.Table.AdditionalWrites.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.BytesAnticompacted.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.BytesFlushed.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.BytesMutatedAnticompaction.system_auth.roles
| system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.CasCommitTotalLatency.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.CasPrepareTotalLatency.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.CasProposeTotalLatency.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.CompactionBytesWritten.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.LiveDiskSpaceUsed.system_auth.roles |
system_auth.roles | counter | 15632
org.apache.cassandra.metrics.Table.MemtableSwitchCount.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.PendingFlushes.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.RangeTotalLatency.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.ReadTotalLatency.system_auth.roles |
system_auth.roles | counter | 1047
org.apache.cassandra.metrics.Table.RepairJobsCompleted.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.RepairJobsStarted.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.RowCacheHit.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.RowCacheHitOutOfRange.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.RowCacheMiss.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.SpeculativeFailedRetries.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.SpeculativeInsufficientReplicas.system_auth.roles
| system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.SpeculativeRetries.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.TombstoneFailures.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.TombstoneWarnings.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.TotalDiskSpaceUsed.system_auth.roles |
system_auth.roles | counter | 15632
org.apache.cassandra.metrics.Table.UncompressedLiveDiskSpaceUsed.system_auth.roles
| system_auth.roles | counter | 15602
org.apache.cassandra.metrics.Table.WriteTotalLatency.system_auth.roles |
system_auth.roles | counter | 0
{code}
I think that 'scope' being 'keyspace.table' is just fine. virtual tables are by
default queryable without ALLOW FILTERING
we can even do something like this
{code}
cqlsh> select * from system_views.metrics_table where scope =
'system_auth.roles' and type = 'counter' and value > '0';
name
| scope | type| value
+---+-+---
org.apache.cassandra.metrics.Table.LiveDiskSpaceUsed.system_auth.roles |
system_auth.roles | counter | 15632
org.apache.cassandra.metrics.Table.ReadTotalLatency.system_auth.roles |
system_auth.roles | counter | 1047
org.apache.cassandra.metrics.Table.TotalDiskSpaceUsed.system_auth.roles |
system_auth.roles | counter | 15632
org.apache.cassandra.metrics.Table.UncompressedLiveDiskSpaceUsed.system_auth.roles
|
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792804#comment-17792804
]
Stefan Miklosovic edited comment on CASSANDRA-14572 at 12/4/23 12:49 PM:
-
By the way, when I do this
{code}
cqlsh> select * from system_views.metrics_table where scope =
'system_auth.roles' and type = 'counter';
name
| scope | type| value
--+---+-+---
org.apache.cassandra.metrics.Table.AdditionalWrites.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.BytesAnticompacted.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.BytesFlushed.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.BytesMutatedAnticompaction.system_auth.roles
| system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.CasCommitTotalLatency.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.CasPrepareTotalLatency.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.CasProposeTotalLatency.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.CompactionBytesWritten.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.LiveDiskSpaceUsed.system_auth.roles |
system_auth.roles | counter | 15632
org.apache.cassandra.metrics.Table.MemtableSwitchCount.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.PendingFlushes.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.RangeTotalLatency.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.ReadTotalLatency.system_auth.roles |
system_auth.roles | counter | 1047
org.apache.cassandra.metrics.Table.RepairJobsCompleted.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.RepairJobsStarted.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.RowCacheHit.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.RowCacheHitOutOfRange.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.RowCacheMiss.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.SpeculativeFailedRetries.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.SpeculativeInsufficientReplicas.system_auth.roles
| system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.SpeculativeRetries.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.TombstoneFailures.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.TombstoneWarnings.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.TotalDiskSpaceUsed.system_auth.roles |
system_auth.roles | counter | 15632
org.apache.cassandra.metrics.Table.UncompressedLiveDiskSpaceUsed.system_auth.roles
| system_auth.roles | counter | 15602
org.apache.cassandra.metrics.Table.WriteTotalLatency.system_auth.roles |
system_auth.roles | counter | 0
{code}
I think that 'scope' being 'keyspace.table' is just fine. virtual tables are by
default queryable without ALLOW FILTERING
we can even do something like this
{code}
cqlsh> select * from system_views.metrics_table where scope =
'system_auth.roles' and type = 'counter' and value > '0';
name
| scope | type| value
+---+-+---
org.apache.cassandra.metrics.Table.LiveDiskSpaceUsed.system_auth.roles |
system_auth.roles | counter | 15632
org.apache.cassandra.metrics.Table.ReadTotalLatency.system_auth.roles |
system_auth.roles | counter | 1047
org.apache.cassandra.metrics.Table.TotalDiskSpaceUsed.system_auth.roles |
system_auth.roles | counter | 15632
org.apache.cassandra.metrics.Table.UncompressedLiveDiskSpaceUsed.system_auth.roles
|
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792804#comment-17792804
]
Stefan Miklosovic edited comment on CASSANDRA-14572 at 12/4/23 12:27 PM:
-
By the way, when I do this
{code}
cqlsh> select * from system_views.metrics_table where scope =
'system_auth.roles' and type = 'counter';
name
| scope | type| value
--+---+-+---
org.apache.cassandra.metrics.Table.AdditionalWrites.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.BytesAnticompacted.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.BytesFlushed.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.BytesMutatedAnticompaction.system_auth.roles
| system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.CasCommitTotalLatency.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.CasPrepareTotalLatency.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.CasProposeTotalLatency.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.CompactionBytesWritten.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.LiveDiskSpaceUsed.system_auth.roles |
system_auth.roles | counter | 15632
org.apache.cassandra.metrics.Table.MemtableSwitchCount.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.PendingFlushes.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.RangeTotalLatency.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.ReadTotalLatency.system_auth.roles |
system_auth.roles | counter | 1047
org.apache.cassandra.metrics.Table.RepairJobsCompleted.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.RepairJobsStarted.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.RowCacheHit.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.RowCacheHitOutOfRange.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.RowCacheMiss.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.SpeculativeFailedRetries.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.SpeculativeInsufficientReplicas.system_auth.roles
| system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.SpeculativeRetries.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.TombstoneFailures.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.TombstoneWarnings.system_auth.roles |
system_auth.roles | counter | 0
org.apache.cassandra.metrics.Table.TotalDiskSpaceUsed.system_auth.roles |
system_auth.roles | counter | 15632
org.apache.cassandra.metrics.Table.UncompressedLiveDiskSpaceUsed.system_auth.roles
| system_auth.roles | counter | 15602
org.apache.cassandra.metrics.Table.WriteTotalLatency.system_auth.roles |
system_auth.roles | counter | 0
{code}
I think that 'scope' being 'keyspace.table' is just fine. virtual tables are by
default queryable without ALLOW FILTERING
we can even do something like this
{code}
cqlsh> select * from system_views.metrics_table where scope =
'system_auth.roles' and type = 'counter' and value > '0';
name
| scope | type| value
+---+-+---
org.apache.cassandra.metrics.Table.LiveDiskSpaceUsed.system_auth.roles |
system_auth.roles | counter | 15632
org.apache.cassandra.metrics.Table.ReadTotalLatency.system_auth.roles |
system_auth.roles | counter | 1047
org.apache.cassandra.metrics.Table.TotalDiskSpaceUsed.system_auth.roles |
system_auth.roles | counter | 15632
org.apache.cassandra.metrics.Table.UncompressedLiveDiskSpaceUsed.system_auth.roles
|
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792800#comment-17792800
]
Stefan Miklosovic edited comment on CASSANDRA-14572 at 12/4/23 12:18 PM:
-
Looks great, I am not sure when I will review this more closely but as far as I
looked into the PR I think we are on the right track.
was (Author: smiklosovic):
Looks great, I am not sure when I will review this more closely but as far as I
looked into the PR I think we are on the right track.
BTW this ticket is about _table metrics_, right? Not about _all metrics_. Do
you think this can be somehow added or it already is?
> 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: 10m
> 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 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792800#comment-17792800
]
Stefan Miklosovic edited comment on CASSANDRA-14572 at 12/4/23 12:18 PM:
-
Looks great, I am not sure when I will review this more closely but as far as I
looked into the PR I think we are on the right track.
BTW this ticket is about _table metrics_, right? Not about _all metrics_. Do
you think this can be somehow added or it already is?
was (Author: smiklosovic):
Looks great, I am not sure when I will review this more closely but as far as I
looked into the PR I think we are on the right track.
> 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: 10m
> 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 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792796#comment-17792796
]
Maxim Muzafarov edited comment on CASSANDRA-14572 at 12/4/23 12:13 PM:
---
I'd like to share some intermediate results, as I've been working on this issue
for a while and have managed to implement a robust solution. All metrics are
exported from MetricsRegistry by metric type and by metric group, the latter is
set accordingly in all the classes in the `org.apache.cassandra.metrics`
package. Need some time to write a good test coverage.
The outcome looks pretty nice, see the tables below.
{code:bash}
cqlsh> select * from system_views.metrics_all_group_names;
group_name| comment|
virtual_table
---++-
Batch | Metrics specific to batch statements |
metrics_batch
BufferPool | Metrics for buffer pool "chunk-cache" |
metrics_buffer_pool
CIDRAuthorizer | CIDR authorizer metrics specific to CIDR filtering |
metrics_cidr_authorizer
CQL |Metrics for CQL queries |
metrics_cql
Cache | Cache metrics |
metrics_cache
Client |Metrics for client requests |
metrics_client
ClientMessageSize | Metrics group for "ClientMessageSize" |
metrics_client_message_size
ClientRequest |Metrics for "ClientRequest" |
metrics_client_request
ClientRequestSize | Metrics group for "ClientRequestSize" |
metrics_client_request_size
ColumnFamily | ColumnFamily metrics |
metrics_column_family
CommitLog | CommitLog metrics |
metrics_commit_log
Compaction | Compaction metrics |
metrics_compaction
DroppedMessage | Metrics group for "DroppedMessage" |
metrics_dropped_message
HintsService | Hints service metrics |
metrics_hints_service
Index | RowIndexEntry metrics |
metrics_index
Keyspace | Metrics of keyspaces |
metrics_keyspace
MemtablePool | MemtablePool metrics |
metrics_memtable_pool
Messaging | Messaging statistics |
metrics_messaging
Paxos | Paxos metrics |
metrics_paxos
ReadRepair |Read repair metrics |
metrics_read_repair
Repair | Metrics group for "Repair" |
metrics_repair
Storage | Metrics for Storage related statistics |
metrics_storage
StorageProxy | Metrics for partition denylist |
metrics_storage_proxy
TCM |TCM metrics |
metrics_tcm
Table | Table metrics |
metrics_table
ThreadPools |Metrics of thread pools |
metrics_thread_pools
{code}
{code:bash}
cqlsh> select * from system_views.metrics_commit_log;
name | scope
| type | value
---+---+---+--
org.apache.cassandra.metrics.CommitLog.CompletedTasks | Undefined
| gauge | 129
org.apache.cassandra.metrics.CommitLog.OverSizedMutations | Undefined
| meter |0
org.apache.cassandra.metrics.CommitLog.PendingTasks | Undefined
| gauge |0
org.apache.cassandra.metrics.CommitLog.TotalCommitLogSize | Undefined
| gauge | 67108864
org.apache.cassandra.metrics.CommitLog.WaitingOnCommit | Undefined
| timer |0
org.apache.cassandra.metrics.CommitLog.WaitingOnFlush | Undefined
| timer |4
org.apache.cassandra.metrics.CommitLog.WaitingOnSegmentAllocation | Undefined
| timer |1
{code}
Autocompletion for the metrics tables works as well:
{code:bash}
cqlsh> select * from system_views.metrics_
metrics_all_group_names metrics_column_familymetrics_index
metrics_storage metrics_type_gauge
metrics_batchmetrics_commit_log metrics_keyspace
metrics_storage_proxy
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792797#comment-17792797
]
Maxim Muzafarov edited comment on CASSANDRA-14572 at 12/4/23 12:09 PM:
---
However, the left alignment looks more eye-friendly. Here is the issue to
provide some options for users: CASSANDRA-19150
{code:bash}
cqlsh> select * from system_views.metrics_storage;
name | scope
| type| value
---+---+-+---
org.apache.cassandra.metrics.Storage.Exceptions | Undefined
| counter | 0
org.apache.cassandra.metrics.Storage.Load | Undefined
| counter | 68541
org.apache.cassandra.metrics.Storage.RepairExceptions | Undefined
| counter | 0
org.apache.cassandra.metrics.Storage.StartupOpsForInvalidToken| Undefined
| counter | 0
org.apache.cassandra.metrics.Storage.TotalHints | Undefined
| counter | 0
org.apache.cassandra.metrics.Storage.TotalHintsInProgress | Undefined
| counter | 0
org.apache.cassandra.metrics.Storage.TotalOpsForInvalidToken | Undefined
| counter | 0
org.apache.cassandra.metrics.Storage.UncompressedLoad | Undefined
| counter | 78239
org.apache.cassandra.metrics.Storage.UnreplicatedLoad | Undefined
| gauge | 68541
org.apache.cassandra.metrics.Storage.UnreplicatedUncompressedLoad | Undefined
| gauge | 78239
{code}
was (Author: mmuzaf):
However, the left alignment looks more eye-friendly. Here is the issue to
provide some options for users: CASSANDRA-19150
{code:bash}
cqlsh> select * from system_views.metrics_dropped_message;
name
| scope | type | value
---+---+---+---
org.apache.cassandra.metrics.DroppedMessage.CrossNodeDroppedLatency.BATCH_REMOVE_REQ
| BATCH_REMOVE_REQ | timer | 0
org.apache.cassandra.metrics.DroppedMessage.CrossNodeDroppedLatency.BATCH_REMOVE_RSP
| BATCH_REMOVE_RSP | timer | 0
org.apache.cassandra.metrics.DroppedMessage.CrossNodeDroppedLatency.BATCH_STORE_REQ
| BATCH_STORE_REQ | timer | 0
org.apache.cassandra.metrics.DroppedMessage.CrossNodeDroppedLatency.BATCH_STORE_RSP
| BATCH_STORE_RSP | timer | 0
org.apache.cassandra.metrics.DroppedMessage.CrossNodeDroppedLatency.CLEANUP_MSG
| CLEANUP_MSG | timer | 0
org.apache.cassandra.metrics.DroppedMessage.CrossNodeDroppedLatency.COUNTER_MUTATION_REQ
| COUNTER_MUTATION_REQ | timer | 0
org.apache.cassandra.metrics.DroppedMessage.CrossNodeDroppedLatency.COUNTER_MUTATION_RSP
| COUNTER_MUTATION_RSP | timer | 0
org.apache.cassandra.metrics.DroppedMessage.CrossNodeDroppedLatency.DATA_MOVEMENT_EXECUTED_REQ
| DATA_MOVEMENT_EXECUTED_REQ| timer | 0
org.apache.cassandra.metrics.DroppedMessage.CrossNodeDroppedLatency.DATA_MOVEMENT_EXECUTED_RSP
| DATA_MOVEMENT_EXECUTED_RSP| timer | 0
org.apache.cassandra.metrics.DroppedMessage.CrossNodeDroppedLatency.ECHO_REQ
| ECHO_REQ | timer | 0
org.apache.cassandra.metrics.DroppedMessage.CrossNodeDroppedLatency.ECHO_RSP
| ECHO_RSP | timer | 0
org.apache.cassandra.metrics.DroppedMessage.CrossNodeDroppedLatency.FAILED_SESSION_MSG
| FAILED_SESSION_MSG| timer | 0
{code}
> 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
>
> Time Spent: 10m
> 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:*
>
[jira] [Comment Edited] (CASSANDRA-14572) Expose all table metrics in virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791082#comment-17791082
]
Maxim Muzafarov edited comment on CASSANDRA-14572 at 11/29/23 1:20 PM:
---
[~cnlwsu] do you mind if I pick up this issue? I already have some draft
changes :-)
was (Author: mmuzaf):
[~cnlwsu] Would you mind if I pick up this issue? I have some draft changes for
that.
> 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: Chris Lohfink
>Priority: Low
> Labels: virtual-tables
>
> 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 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
