dsmiley commented on code in PR #3734: URL: https://github.com/apache/solr/pull/3734#discussion_r2407166672
########## solr/core/src/java/org/apache/solr/handler/RequestHandlerBase.java: ########## Review Comment: The refactor for inheritance can be deferred to a minor release. BTW the JIRA issue for what you are reworking is [here](https://issues.apache.org/jira/browse/SOLR-15007?jql=project%20%3D%20SOLR%20AND%20text%20~%20%22metrics%20node%22), which is a useful examination for providing context / use-case. Imagine thousands of cores at any one time, and furthermore coming and going! It's a metrics cardinality explosion to send **any** core level metrics to an aggregator. In such a world (that I am very familiar with), you think of the Solr node as a whole that does work. No core metrics. CC @magibney I don't love the *absence* of core metrics to mean it's the node level. I worry that filtering is hard. It's imperative that it be possible to easily filter for node metrics at our endpoint. I think our current filtering (fresh custom code) can't handle that. The previous filtering (DropWizard) could definitely support that by filtering to the node registry. Since we register core metrics in a special way (for unloading), maybe our metrics could support a similar filter to not even examine the core ones. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
