What determines which logging settings are available?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

What determines which logging settings are available?

Oakley, Craig (NIH/NLM/NCBI) [C]
We are wanting to tweak the logging levels of our Solr 7.4 nodes to see what might be helpful to add to the solr.log for debugging purposes.

In investigating what is available, however, I run /solr/admin/info/logging and I find that there is little consistency in what logging settings are available to any given node (referring here to the "name" field of the "loggers" array returned by /solr/admin/info/logging) - even between nodes running in the same SolrCloud and/or on the same host.

For instance one node of a SolrCloud might have org.apache.solr.cloud.overseer.SliceMutator which can be set, but no other instance of the same SolrCloud has that setting.

Could someone clarify what determines which setting are available?

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: What determines which logging settings are available?

Shawn Heisey-2
On 5/10/2019 4:26 PM, Oakley, Craig (NIH/NLM/NCBI) [C] wrote:
> We are wanting to tweak the logging levels of our Solr 7.4 nodes to see what might be helpful to add to the solr.log for debugging purposes.
>
> In investigating what is available, however, I run /solr/admin/info/logging and I find that there is little consistency in what logging settings are available to any given node (referring here to the "name" field of the "loggers" array returned by /solr/admin/info/logging) - even between nodes running in the same SolrCloud and/or on the same host.
>
> For instance one node of a SolrCloud might have org.apache.solr.cloud.overseer.SliceMutator which can be set, but no other instance of the same SolrCloud has that setting.

The logger names are almost always the fully qualified class name.  If
you don't have a particular class name in the logger list, it probably
means that Solr instance has never run any of the code in that class, so
the logger was never created.

For the particular class you mentioned, it probably means that only that
one node has been the overseer.  If you were to restart that Solr node,
one of the other nodes would likely become the overseer, and will most
likely have some new loggers.  I do not know if that specific class
would be one of them just by changing the overseer node.

Any logging settings that you change in the Logging tab of the admin UI
will not survive a node restart.  If you want those to persist, you'll
need to put them into the logging config.  Solr 7.4 uses log4j2, so the
file to edit is log4j2.xml.

Thanks,
Shawn