back

next

 

 

 

 

Managing Logs in

Oracle WebLogic Server

 

 

Oracle WebLogic Server has quite a number of log files that are generated which naturally tend to grow over time. Without any type of log rotation, archiving, or purging set up, your file system can be filled up rather quickly and eventually pose stability issues to your application environment. Listen from someone who has seen it all–if your file system is full, your application will likely hang and in-flight transactions impacted.

 

Fortunately, setting up your environment to prevent this scenario is extremely simple. One consideration is to move all the logs to a completely separate and independent mount point outside your WebLogic domain. But this in itself still does not protect against application failures.

 

In this article, we describe a few basic things you can do to manage your logs. Given the comprehensive nature of Oracle WebLogic Server, there are a number of log files you need to monitor and control, highlighted in the following table.

 

 

Unfortunately, the WebLogic Server log rotation affects only the .log files but not the standard .out files, which is generated when you use Node Manager to start up and shut down the managed servers or if you start them up as a background process (e.g., using nohup). You must implement a custom solution for the system .out files and there are many resources available online that describe various approaches. We present one such option.

 

There are numerous log files in Oracle WebLogic Server and ideally you would want to ensure that the number of rotated log files is controlled. For example, you may have already taken the steps to rotate the log files as they grow to a certain size. This is a great first step, but you also should control how many of those rotated files you wish to retain, otherwise your file system will likely get filled up over time if they are not manually deleted. Fortunately, the WebLogic Server Administration Console provides us the means to easily do so as well.

 

Based on the configuration described in this article, each log type requires 300 MB of disk space, as we are rotating the logs after they reach 10 MB in size and keeping a maximum 30 files before removing them. All instructions are applicable to both Oracle WebLogic Server 11g and 12c.

 

 

Managed Server Logs

 

Entries generated by a Java application are generally logged in the .log files. The WebLogic Server administrator should not trust that the application appropriately controls and logs entries resourcefully. Thus, it is recommended to control these files by enabling log rotation (either by time, by size, or both) and to limit the number of retained log files. This will prevent runaway processes from endless logging to your file system and control growth.

 

1. Log in to the WebLogic Server Administration Console.

 

2. Navigate to “Server > [managed server] > Logging > General”.

 

3. Set the following values:

 

 

4. Repeat these instructions for all managed servers.

 

 

Managed Server HTTP Logs

 

Each managed server logs all incoming HTTP requests to the access.log file which typically resides within the same directory. This log exists whether or not you have configured a front facing Oracle HTTP Server or Oracle WebTier instance. To control the growth of this log file, perform the following steps.

 

1. Navigate to “Server > [managed server] > Logging > HTTP”.

 

2. Set the following values:

 

 

3. Repeat these instructions for all managed servers.

 

 

 advertisement

 

 

Managed Server Data Source Logs

 

Once created, data sources are targeted to one or more managed servers. As with the other logs, do not forget to control growth of the data source log files as well.

 

1. Navigate to “Server > [managed server] > Logging > Data Source” (new option in current releases).

 

2. Set the following values:

 

 

Domain Level Logs

 

A log is also generated at the domain level and this log is typically found under the log directory of the AdminServer taking the name [your_domain_name].log.

 

1. For domain level logging properties, navigate to “[domain] > Configuration > Logging”.

 

2. Set the following values:

 

 

4. Repeat these instructions for all managed servers.

 

 

Managed Server System Out

 

Unfortunately, the WebLogic Server log rotation settings described earlier affect only the .log files but not the standard .out files. You must implement a custom solution to rotate these. The approach documented here uses the default UNIX log rotate utility to assist in this.

 

1. Create a log rotation configuration file with the following content and place it in a local directory such as

/home/oracle/scripts/logrotate.conf:

 

/u01/app/oracle/middleware/user_projects/domains/soa_domain/servers/soa_server?/logs/soa_server?.out {

    missingok

    copytruncate

    compress

    rotate=30

    size=10M

}

 

2. Add additional entries to logrotate.conf to include the .out files for all managed servers (i.e., simply duplicate the entry above and update the path accordingly).

 

3. Edit your UNIX user cron jobs by typing crontab -e and adding the following schedule:

 

0,15,30,45 * * * * /usr/sbin/logrotate -s

$HOME/scripts/stat.txt

$HOME/scripts/logrotate.conf

 

As you can see here, we are taking advantage of the UNIX logrotate utility to easily assist in rotating the standard out logs. In our example, the cron job checks every 15 minutes if rotation is required and the log(s) will be rotated after it reaches a size of 10 MB, going through 30 rotations before removed the file.

 

 

Summary

 

This article is intended to remind every Oracle WebLogic Server administrator that there are multiple logs that need to be managed and controlled, not just the standard managed server logs. I’ve personally seen applications hang and customers question the stability of Oracle products because of the simple reason that the logs grew to the point of the file system filling up completely, rendering the deployed applications unstable.

 

One option is to create a separate mount point exclusively dedicated to logs. Here, you would update the log file location. Whether this approach is employed or not, you will also need to control log growth as described in this article.

 

OTECH MAGAZINE #7  spring 2015        copyright otech magazine 2015

www.otechmag.com