[
https://issues.apache.org/jira/browse/CASSANDRA-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17088060#comment-17088060
]
Stephen Mallette commented on CASSANDRA-15582:
----------------------------------------------
Getting back to the discussion on comparing metrics on 3 and 4, I think it
makes sense to work on the manual process of this effort first to see if it can
at least have a reasonable documented approach. I spent a fair bit of time
trying multiple ways to get two separate cassandra clusters running locally
(one for 3 and one for 4). I'd found it easy enough to do by installing
cassandra locally and editing some of the config a bit. I had less success with
nicer approaches like ccm and docker. The latter was pretty annoying as that
seems like such a simple way to get things working but I clearly was confounded
by something in the step of remotely connecting to cassandra/JMX in a docker
container. For now, I will continue my analysis with this simple rig I have
currently working.
> Possible to print out what was added and what was removed?
I was able to get a list of newly added metric names - so metric names added in
4 that were not in 3:
https://gist.github.com/spmallette/c443716e1c0de40b4a5bb0ef5422aeee
There are a fair number of them and many do not appear to exist in the
documentation, so perhaps this is another area that needs some attention in
relation to this ticket.
> How do we ensure that all code paths that generate the metrics are exercised?
I think this was a good point as well. I've yet to come across a metric that
wasn't initialized as start of cassandra, but I've only determined that by
random diggings in code and so I can't say with confidence that this is always
the case. If anyone is familiar with any metrics that are fired up as a result
of specific code paths having to be exercised I'd be interested to know about
them as it would mean some new surface area to consider in all this.
I think I will venture to try to better understand the nature of the property
keys shifting between 3 and 4 to see if I can firm up my understanding of what
is happening there. And, hopefully, I can figure out a nicer way for anyone to
easily setup an environment to run some of this analysis if they wanted to.
> 4.0 quality testing: metrics
> ----------------------------
>
> Key: CASSANDRA-15582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15582
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
> Reporter: Josh McKenzie
> Assignee: Romain Hardouin
> Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: Screen Shot 2020-04-07 at 5.47.17 PM.png
>
>
> In past releases we've unknowingly broken metrics integrations and introduced
> performance regressions in metrics collection and reporting. We strive in 4.0
> to not do that. Metrics should work well!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
