How to Change GLU.Engine Logging Level

The logging level of a GLU.Engine can be altered through three mechanisms.

The first method involves using the Application Settings within the GLU.Console, however, this requires a complete rebuild and redeployment of the GLU.Engine.

The second method allows for the logging level to be altered without the need for a rebuild and redeployment. This is done through the use of the “changelogginglevel.sh” script located in the GLU.Engine deployment directory:

This shell script actually makes use of one of the GLU.Engine APIs to make the change.

This is the third method, which is to call the JMX APIs directly on the server port. This method should be used when using a docker container to run the GLU.Engine.

Changing Log Level via the GLU.Console

In Build Manager, Select GLU.Engine Settings: 

Edit “logging” to the desired level:

The “Path“ and “Name” of the GLU.Engine logs can be altered to meet specific requirements. To specify the log path as the root directory of the GLU.Engine folder, utilise a full stop “.” in the relevant configuration setting “Path“.

Why have different Log Levels?

The logging framework utilised by GLU, the de-facto standard in the Java world, classifies log messages into five categories:

• ERROR
• WARN
• INFO
• DEBUG
• TRACE

These log levels are assigned based on the urgency of the log message, allowing log filtering by level of importance.

In a production environment, it is crucial to have an efficient filtering mechanism for log messages to quickly identify urgent issues leading to potential losses. Mixing urgent log messages with non-urgent ones which hampers efficient log analysis.

It is important to understand when to categorise log messages into each level of urgency.

ERROR

The ERROR level should only be used when the application really is in trouble. Users are being affected without having a way to work around the issue.

Someone must be alerted to fix it immediately, even if it’s in the middle of the night. There must be some kind of alerting in place for ERROR log events in the production environment. Often, the only use for the ERROR level within a certain application is when a valuable business use case cannot be completed due to technical issues or a bug.

Take care not to use this logging level too generously because that would add too much noise to the logs and reduce the significance of a single ERROR event. You wouldn’t want to be woken in the middle of the night due to something that could have waited until the next morning, would you?

WARN

The WARN level should be used when something bad happened, but the application still has the chance to heal itself or the issue can wait a day or two to be fixed.

Like ERROR events, WARN events should be attended to by a dev or ops person, so there must be some kind of alerting in place for the production environment.

A concrete example for a WARN message is when a system failed to connect to an external resource but will try again automatically. It might ultimately result in an ERROR log message when the retry-mechanism also fails. The WARN level is the level that should be active in production systems by default, so that only WARN and ERROR messages are being reported, thus saving storage capacity and performance.

If storage and performance are not a problem and our log server provides good search capabilities we can actually report even INFO and DEBUG events and just filter them out when we’re only interested in the important stuff.

INFO

The INFO level should be used to document state changes in the application or some entity within the application. This information can be helpful during development and sometimes even in production to track what is actually happening in the system.

Concrete examples for using the INFO level are:

• the application has started with configuration parameter x having the value y
• a new entity (e.g. a user) has been created or changed its state
• the state of a certain business process (e.g. an order) has changed from “open” to “processed”
• a regularly scheduled batch job has finished and processed z items.

DEBUG

DEBUG level logging shows the detail of every transactions.

Including:

• error messages when an incoming HTTP request was malformed, resulting in a 4xx HTTP status
• variable values in business logic.
• Transaction details
  

Due to performance implications DEBUG mode should be used in Production environments sparingly. Sparingly means 2-3 hours in a controlled test, and switched back to INFO or higher straight after.

TRACE

Compared to DEBUG, it’s pretty easy to define what to log on TRACE. As the name suggests, we want to log all information that helps us to trace the processing of an incoming request through our application.

This includes:

• start or end of a method, possibly including the processing duration
• URLs of the endpoints of our application that have been called
• start and end of the processing of an incoming request or scheduled job.
  

Log File Settings & Limits