Advanced Users—Configuring Log4j 2 for GemFire
Basic GemFire logging configuration is configured via the gemfire.properties file. This topic is intended for advanced users who need increased control over logging due to integration with third-party libraries.
log4j2.xml that GemFire uses is stored in geode.jar as
log4j2-default.xml. The contents of the configuration can be viewed in the product distribution in the following location:
To specify your own
log4j2.xml configuration file (or anything else supported by Log4j 2 such as .json or .yaml), use the following flag when starting up your JVM or GemFire member:
If the Java system property
log4j.configurationFile is specified, then GemFire will not use the
log4j2-default.xml included in geode.jar. However, GemFire will still create and register a AlertAppender and LogWriterAppender if the
log-file GemFire properties are configured. You can then use the GemFire LogWriter to log to GemFire’s log or to generate an Alert and receive log statements from customer’s application and all third party libraries. Alternatively, you can use any front-end logging API that is configured to log to Log4j 2.
Using Different Front-End Logging APIs to Log to Log4j2
You can also configure Log4j 2 to work with various popular and commonly used logging APIs. To obtain and configure the most popular front-end logging APIs to log to Log4j 2, see the instructions on the Apache Log4j 2 web site at http://logging.apache.org/log4j/2.x/.
For example, if you are using:
- Commons Logging, download “Commons Logging Bridge” (
- SLF4J, download “SLFJ4 Binding” (
- java.util.logging, download the “JUL adapter” (
See http://logging.apache.org/log4j/2.x/faq.html for more examples.
All three of the above JAR files are in the full distribution of Log4J 2.1 which can be downloaded at http://logging.apache.org/log4j/2.x/download.html. Download the appropriate bridge, adapter, or binding JARs to ensure that GemFire logging is integrated with every logging API used in various third-party libraries or in your own applications.
Note: Pivotal GemFire has been tested with Log4j 2.1. As newer versions of Log4j 2 come out, you can find 2.1 under Previous Releases on that page.
Customizing Your Own log4j2.xml File
Advanced users may want to move away entirely from setting
log-* gemfire properties and instead specify their own
Custom Log4j 2 configuration in GemFire comes with some caveats and notes:
- Do not use
"monitorInterval="in your log4j2.xml file because doing so can have significant performance impact. This setting instructs Log4j 2 to monitor the log4j2.xml config file at runtime and automatically reload and reconfigure if the file changes.
- GemFire’s default
log4j2.xmlspecifies status=“FATAL” because Log4j 2’s StatusLogger generates warnings to standard out at ERROR level anytime GemFire stops its AlertAppender or LogWriterAppender. GemFire uses a lot of concurrent threads that are executing code with log statements; these threads may be logging while the GemFire appenders are being stopped.
- GemFire’s default log4j2.xml specifies
shutdownHook="disable"because GemFire has a shutdown hook which disconnects the DistributedSystem and closes the Cache, which is executing the code that performs logging. If the Log4J2 shutdown hook stops logging before GemFire completes its shutdown, Log4j 2 will attempt to start back up. This restart in turn attempts to register another Log4j 2 shutdown hook which fails resulting in a FATAL level message logged by Log4j 2.
The GEODE_VERBOSE marker (Log4J2 Marker are discussed on http://logging.apache.org/log4j/2.x/manual/markers.html) can be used to enable additional verbose log statements at TRACE level. Many log statements are enabled simply by enabling DEBUG or TRACE. However, even more log statements can be further enabled by using MarkerFilter to accept GEODE_VERBOSE. The default GemFire
log4j2.xmldisables GEODE_VERBOSE with this line:
<MarkerFilter marker="GEODE_VERBOSE" onMatch="DENY" onMismatch="NEUTRAL"/>
You can enable the GEODE_VERBOSE log statements by changing
onMatch="ACCEPT". Typically, it’s more useful to simply enable DEBUG or TRACE on certain classes or packages instead of for the entire GemFire product. However, this setting can be used for internal debugging purposes if all other debugging methods fail.