Hi dear friends. In this lesson, we will talk about logging in microprofile and microservices. It's recommended to use the Java JSR-47 logging standard in microprofile microservices applications. Provide more handy logging libraries to developers. I'm assuming you're already familiar with the Java Util logger class. We define a static logger object like this. And we can specify a level such as info, warning, severe, and so on. This time I set it to info. I'm entering the generated number into the logger here. Okay, save and test. I'm doing some CURL operations and generating some numbers, but as we see it isn't displayed in the log console because our servers logging level is not suitable to display this log message on the console. There's a WARNING message, but we can ignore it for now. By default, open libraries log level is AUDIT. It is a higher stage than info, so our log is not displayed. We need to adjust our server logger properties.

From bottom to top, there are these log levels: info, audit, warning, error, and off. Info: prints all messages containing any urgent or non urgent information. Audit: prints significant events that affect the server state or resources. Warning: prints warning messages by application or system. Warning messages are potential errors or impending errors. Error: prints error messages. Error messages can be severe or fatal. In other words, they can cause a function to be unavailable or the system to halt completely. Off: prints no log messages. When you specify a log level, the log messages at that level or at higher levels are written to the console or file. Let's change the log level of the service. To change it, we need to add the login configuration tag to the server.xml file. I'm setting the value of consoleLogLevel parameter as INFO. So, it will display info messages. It makes no difference whether you write it in lowercase or uppercase. Okay, I'd like to show you some more logging tag properties.

We can change the presentation format of the log. To do this, we use consoleFormat property. There are several formats: DEV, SiMPLE, JSON, and T-basic. The default console format is DEV, let's change it to JSON. I'm adding consoleFormat. keyword and saving. As you see, it immediately affects the format. Let's do a cURL. As you see, it's in JSON format despite the fact that it became a little wordy. And now, the last thing I'd like to mention about the logging tag is that we can specify the sources of the logging. To do this, we can use consoleSource option. ConsoleSource can have several values; message, trace, access/log, ffdc, and audit. Here, FFDC is a feature introduced by IBM. It collects events and errors that occur while the server is running in the background. By default, Open Liberty logging source is set to message. Let's change the consoleSource and add some other values. I'm adding message, trace, accessLog and ffdc. Okay, save the changes. I want to revert consoleFormat back to dev. To see access logs, we need to add accessLog specification to HTTP endpoint tag. Let's add.

Here, I define a path to the accessLog file and specify a logFormat. Here, h is remote host, u is the remote host user, t is start time of request, r is the first line of the request, s is the status code of the request, b is the response size in bytes excluding the headers, d is the elapsed time of the request in microseconds. Save the changes and make some cURL operations. Let me make some cURL operations. The accessLog is not printed to the console, instead it's printed to a log, the location of which is specified in the server.xml file. Let's look at the accessLog file. To find the log file, right click on the project select 'Shown In' 'Terminal'. A terminal became active at the bottom part of the IDE. I will do a short search to find the log file. Find -name, copy the name from server.xml file. I found the exact location of the file. Let me display its content using the cURL command.

As you see here, my cURL operation is logged. We can specify logging properties in the bootstrap.properties file as well. It will be saved in the same directory as server.xml. So, let's add some properties regarding how many log files will exist and which size. Okay, save the changes. Now, let's pay attention to the log.console. The server will restart when we save the changes in the bootstrap.properties file because this file is a server bootstrap.properties file and its contents affect the initialization of the server. You can also add properties that aren't related to logging. Okay, dear friends, that's all. See you in the next lesson.