[
https://issues.apache.org/jira/browse/SOLR-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15945158#comment-15945158
]
Andrzej Bialecki commented on SOLR-9959:
-----------------------------------------
Wow, thanks Hoss for a really thorough review!
bq. Why is this impossible?
Everything's possible, it's just bits and bytes ;) but it's not always
convenient. Components that register metrics are free to do so under different
categories and keys, and in fact some of them already do register metrics under
eg. CORE, DIRECTORY, and INDEX (from one component) - that's why I wrote that
there's no natural 1:1 mapping from metric name back to a component that
registered it - we would have to maintain this in a separate structure (which
we can do, but it takes some additional space). So it's not true that exactly
the same info is still available from {{/admin/metrics}} as in
{{/admin/mbeans?stats=true}}.
bq. using /admin/mbeans?stats=true (and the Plugin/Stats screen in the UI) is
useless
This can be replaced in the UI with a view of /admin/metrics, split by registry
and category - but as explained above it won't map back 1:1 to specific
components. Since /admin/mbeans is centered around individual mbeans we can't
easily get back per-mbean stats unless we maintain some additional mapping, no
matter what filtering criteria we use.
One way to minimize this back-compat breakage would be to pretend that all
metrics under a specific {{CATEGORY.key}} map back to a particular component.
This holds true for 90% of metrics and it would allow us to populate back the
"stats" output from mbeans.
Other comments:
* agreed on adding some release note / guide material on this branch. I
usually do this as a separate JIRA once the code is stable, but I can equally
well put it in a file.
* I'll add support for using regex filters in /admin/metrics
* I added metrics-core as a dep. to DIH because IntelliJ complained about not
being able to access it when registering a {{MetricsMap}}, which is a {{Gauge}}
- I guess it wants to be able to access all parent classes of the classes
referenced here?
* {{MetricType}} and SolrCore {{_notset_}} / {{_auto_}} are issues inherited
from master, I can fix them here or in a separate issue.
* MBeanServer creation and back-compat sysprop and solrconfig options - very
good points, we should make it work in a similar way, eg. instantiating the
reporter and server when a {{<jmx/>}} element is present even if no explicit
{{SolrJmxReporter}} config is present.
** some of the metrics that we really wanted to report (eg. number of open file
descriptors) used to be accessible via reflection, which is a no-no in JDK 9 -
but they are exposed via platform MBeans. If we need to be more careful about
starting up the server then we have to make these metrics optional (which
unfortunately also means that we can't depend on them being always present).
* test changes - good points, I'll work on that.
bq. CACHE related MBeans (ex: filterCache),
I knew it would be contentious ;) That's the thing I mentioned above about
{{MetricsMap}} - and in fact if you click on this string representation in
JConsole it will expand to a proper map. The pro of this approach is that we
don't have to manage the lifecycle of cacheEntry -> metric registration, the
con is that we lose the type info.
> SolrInfoMBean-s category and hierarchy cleanup
> ----------------------------------------------
>
> Key: SOLR-9959
> URL: https://issues.apache.org/jira/browse/SOLR-9959
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
> Affects Versions: master (7.0)
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-9959.patch
>
>
> SOLR-9947 changed categories of some of {{SolrInfoMBean-s}}, and it also
> added an alternative view in JMX, similar to the one produced by
> {{SolrJmxReporter}}.
> Some changes were left out from that issue because they would break the
> back-compatibility in 6.x, but they should be done before 7.0:
> * remove the old JMX view of {{SolrInfoMBean}}-s and improve the new one so
> that it's more readable and useful.
> * in many cases {{SolrInfoMBean.getName()}} just returns a FQCN, but it could
> be more informative - eg. for highlighter or query plugins this could be the
> symbolic name of a plugin that users know and use in configuration.
> * top-level categories need more thought. On one hand it's best to minimize
> their number, on the other hand they need to meaningfully represent the
> functionality of components that use them. SOLR-9947 made some cosmetic
> changes, but more discussion is necessary (eg. QUERY vs. SEARCHHANDLER)
> * we should consider removing some of the methods in {{SolrInfoMBean}} that
> usually don't return any useful information, eg. {{getDocs}}, {{getSource()}}
> and {{getVersion()}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
