[
https://issues.apache.org/jira/browse/SOLR-14393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18011328#comment-18011328
]
David Smiley commented on SOLR-14393:
-------------------------------------
[~mlbiscoc] FYI could save you some work here by just entirely ditching metrics
on
HIGHLIGHTER, QUERYPARSER,
SPELLCHECKER
Those are kind of higher up the stack compared to the foundational metrics that
should stay.
The other metrics are more core to the foundation of the Solr platform. This
is its own PR from OTEL but removing dubious metrics would save you effort in
that. To be clear, I mean also remove
org.apache.solr.core.SolrInfoBean.Category for the above list, in addition to
metrics.
> Remove dubious jmx / metrics categories
> ---------------------------------------
>
> Key: SOLR-14393
> URL: https://issues.apache.org/jira/browse/SOLR-14393
> Project: Solr
> Issue Type: Task
> Components: metrics
> Reporter: David Smiley
> Priority: Major
>
> When I look at Solr's metrics or browse the JMX tree or even in Solr's admin
> UI in certain areas, I see that many parts of the original & fast vector
> highlighter are present here under the category HIGHLIGHTER. I don't think
> they should be; they don't warrant it. Who cares how many times
> {{HIGHLIGHTER.SolrFormatter.default.requests}} has been used? One could
> argue _any_ number of these and just about any class in the whole system
> might be interesting to know in some perf investigation so why are these so
> special. They aren't. For that matter, nor is SPELLCHECK and some others.
> It might be interesting for SearchHandler to report metrics on the components
> that are there and how often they are used. _That_ would be cool. But down
> to the detail of which internal components are used _within_ a
> SearchComponent is a bit much.
> CC [~ab]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]