[
https://issues.apache.org/jira/browse/SOLR-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15946139#comment-15946139
]
Hoss Man commented on SOLR-9959:
--------------------------------
bq. So it's not true that exactly the same info is still available from
/admin/metrics as in /admin/mbeans?stats=true.
Sure -- i wasn't suggesting that the *exact* same info was available (with the
exact same names) -- my point is that as things stand on the branch, from a
users point of view:
* {{admin/mbeans}} is virtually useless
* the {{stats=true}} param was explicitly removed
* there is no obviously straight forward replacement for users (particularly
for the UI, and in conjunction with the {{diff}}) option.
meanwhile, as a developer: there seems to be a relatively straight forward way
to keep *most* of the existing {{admin/mbeans}} functionality working (probably
requiring clients to only some make some minor tweaks to the "stat" names they
expect from each "key" in the {{infoRegistry}}) for the foreseeable future --
so why not make it work...
{quote}
* add a {{default MetricsMap getMetricsMap() \{return null;\}}} to
{{SolrInfoBean}} (to replace {{getStatistics()}})
* any class implementing both {{SolrInfoBean}} and {{SolrMetricProducer}}
_could_ implement {{initializeMetrics(...)}} such that it keeps a private
reference to a {{MetricsMap}} it registers & return that from
{{getMetricsMap()}}
** many of the {{SolrInfoBean}} classes already seem to be maintaining a
{{private MetricsMap metricsMap;}} that is assigned in
{{initializeMetrics(...)}} but never used (in the class) after that
* {{/admin/mbeans}} can call {{getMetricsMap()}} on each {{SolrInfoBean}} it
loops over if {{stats=true}}
{quote}
...that seems easier then implementing equivalent Admin UI functionality based
on {{admin/metrics}} (particularly in combination with the "diff" support) and
would have other wins for other existing programtica consumers of
{{/admin/mbeans}}
bq. 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?
I don't know about IntelliJ orwhat it was trying to do, but you may want to
double check that - it definitely wasn't needed in ivy (i tried removing it and
everything compiled fine)
bq. ...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.
To be clear: the {{<jmx/>}} element is solrconfig.xml specific, and the
existing "default" logic is (whne no {{<jmx/>}} exists) is probably _not_ the
best given solr is now a standalone app.
It seems like moving forward it makes sense to keep metrics reporters like
{{SolrJmxReporter}} configured at the solr.xml/container level -- so moving
forward with 7.0 and on, I definitely don't think we should use *exactly* the
same defaults as how it's worked in the past. We can let our defaults be
driven by the existince of an existing MBeanServer created by the JVM based on
startup options, but we definitely should *NOT* be calling
{{ManagementFactory.getPlatformMBeanServer()}} and _forcing_ the JVM to create
a platform MBeanServer.
bq. 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).
Please note there is an important difference between the platform *MBeans* APIs
and the (virtually identical) platform *MXBeans* APIS ... i'm not an expert but
one thing i do know is that accessing the platform *MBeans* requires an
MBeanServer, but you can access MXBeans directly from the individual static
methods in {{ManagementFactory}}
Hence my point about taking a look at SystemInfoHandler: it uses
{{ManagementFactory.getOperatingSystemMXBean();}} to fetch and
{{OperatingSystemMXBean}} (as well as using {{Class.forName()}} to try and load
some JVM vendor specific MXBeans as well) which gives access to all the same
info as an {{OperatingSystemMBean}} currently used in the
{{OperatingSystemMetricSet}} -- *w/o needing an MbeanServer to be running*.
This bean introspection code works in jdk9 just fine...
{noformat}
...
<str name="name">Linux</str>
<str name="arch">amd64</str>
<int name="availableProcessors">4</int>
<double name="systemLoadAverage">0.74</double>
<str name="version">3.19.0-51-generic</str>
<long name="committedVirtualMemorySize">4325052416</long>
<long name="freePhysicalMemorySize">3611639808</long>
<long name="freeSwapSpaceSize">16437768192</long>
<double name="processCpuLoad">0.010957238841522514</double>
<long name="processCpuTime">11510000000</long>
<double name="systemCpuLoad">0.19951374172457412</double>
<long name="totalPhysicalMemorySize">16513077248</long>
<long name="totalSwapSpaceSize">16860049408</long>
<long name="maxFileDescriptorCount">65536</long>
<long name="openFileDescriptorCount">170</long>
...
{noformat}
Similar info about BufferPools (the other place
{{SolrDispatchFilter.setupJvmMetrics()}} uses the MBeanServer) should be
available via {{BufferPoolMXBean}} , see example of how to get a list of these
in the javadocs:
https://docs.oracle.com/javase/7/docs/api/java/lang/management/BufferPoolMXBean.html
bq. ... 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.
Losing type info for cache metrics is inconvinient, but losing and the ability
to monitor individual cache metrics as individual JMX Attributes seems like a
big loss.
> 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]
