Log4J with multiple JVMs

Navigation
1

Context

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

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

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

Problem

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

  • Active Log Debug
  • Active Log Error

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

    I thought about the following alternatives:

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

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

    I do not know if this way of thinking is coherent and will work.

    Does anyone have any ideas or have you experienced any similar problem, multiple Log4J in multiple JVMs?

        
    asked by anonymous 21.06.2016 / 00:58

    1 answer

    1

    About the solutions presented in the question

      

    1) Read the application's .properties file ...

    Configuring 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 the 1.2 version, the watchdog feature 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 deploy framework is predictable and applications have access to a writeable directory on the server. It can generate a bit of confusion if the configuration directory is not the same in all environments.

    The Log4J 2 documentation tells you 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 changing the log level, it may take up to 5 seconds for the new setting to take effect.

    JMX

    Use a JMX client to change the logs at run time.

    The advantage is that the application does not need to read any external data and also no additional implementation is required in the loggers, although the application that performs the log level change needs to know which applications are running to communicate with them .

    Remote Appender

    Yet another alternative is to create a separate service for the logs using, for example, SocketAppender .

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

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

    Updating the log level 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 DEBUG is active.

        
    21.06.2016 / 05:57
    Popular table with fluent api How to create a select in firebird?