[SOLR-16772] SOLR_LOG_LEVEL's effects are buggy/non-intuitive, should be handled by log4j2.xml

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Assignee: Unassigned
• Reporter: Chris M. Hostetter
• Created: 25/Apr/23 21:21
• Updated: 03/May/23 17:39

Description

The way that that SOLR_LOG_LEVEL (aka: solr.log.level sysprop) is implemented is that – if a value is specified – CoreContainerProvider calls StartupLoggingUtils.changeLogLevel(...) which (ultimately) calls log4j's LogManager.getContext(false).getConfiguration().getRootLogger().setLevel(...).

But this has some weird and confusing effects in practice:

• any logging before SolrDispatchFilter gets to this point will still happen – even if it violates the level specified
• it only changes the level of the root logger. Any other loggers that are explicitly configured still use their configured level
  • in the log4j2.xml file that we ship, we explicitly set levels for things like hadoop, zookeeper, LoggingInfoStream, HttpSolrCall, SlowRequest, jetty, etc..
  • Which means even if you set SOLR_LOG_LEVEL=ERROR or SOLR_LOG_LEVEL=OFF you'll still get WARN (or in some cases INFO) level messages from those packages/classes
• even if you run Solr with a custom log4j2.xml config, setting SOLR_LOG_LEVEL (or inheriting it from your env – maybe from a helm chart's default values.yaml) will cause your root logger's level might be overridden

Issue Links

• is related to: SOLR-16044 SlowRequest logging disabled if SolrCore logger set to ERROR