Log4j with multiple Jvms

Question

Context

In the project I am (production environment) has a server that is installed with 4 java applications, being:

• 1 application deployed Jetty
• 1 application in Tomcat
• 2 jar generated with Spring Boot framework

All applications are separate, that is, each application has a dedicated JVM. For log control, each application implements its Log4j, using the log4j.properties file (each application has its file) to configure and control the log level.

Problem

In application 1 (App JETTY) I need to create two menus with the options:

1. Active Log Debug
2. Active Log Error

When the admin user in Runtime selects the option Active Log Debug, the 4 applications running on the server should start generating log level Debug. The same occurs in the case of Active Log Error option, all 4 applications should start generating log level Error.

I thought of the following alternatives:

1) Read the file .properties of the applications (installation directory) and change the level of LOG as, replace the property of propertyConfigurator.configure() for PropertyConfigurator.configureAndWatch (RUNTIME)

2) Submit the command -Dorg.apache.logging.log4j.simplelog.StatusLogger.level=TRACE for each JVM (RUNTIME)

I do not know if that way of thinking this coherent and whether it will work.

Does anyone have any idea or have experienced any similar problem, multiple Log4j in multiple Vms?

Answer 1

On the solutions presented in the question

1) Read application file . properties...

Setting up Log4j to monitor the configuration file would work and would be a good solution, provided in the library architecture.

Just make sure you are using the latest version of the library. In version 1.2, the functionality watchdog is discouraged for JEE applications because the new thread used to monitor the file is not destroyed if the application is updated without restarting the server.

2) Submit the command...

Submitting a command line parameter to an active JVM is impossible.

Possible alternatives

Monitor Configuration

It works well if the deployment structure is predictable and applications have access to a directory where you can write to the server. It can generate a bit of confusion if the configuration directory is not the same in all environments.

To log4j 2 documentation tells how you can configure file monitoring. Example:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration monitorInterval="5">
...
</Configuration>

Here the file is checked every 5 seconds - the minimum allowed in the configuration. This means that after the log level change, it may take up to 5 seconds for the new configuration to take effect.

JMX

Use a JMX client to change the logs at runtime.

The advantage is that it is not necessary for the application to read any external data and also no additional implementation is required in Loggers, although the application that performs the change at the log level needs which applications are operating to communicate with them.

Remote appender

Yet another Alternative is to create a separate service for the logs using, for example, the Socketappender.

In this case, the two applications connect to a third party that takes care exclusively of the logs.

The advantage of "remote" logs is that you can scale the environment and still keep logs centralized.

The log level update can be done in any way already mentioned above.

Asynchronous appender

Using an asynchronous appender can decrease the impact of logging on performance, especially if the mode DEBUG is active.