|
| |
| Sun Java System Application Server Standard and Enterprise Edition 7 2004Q2 Update 3 Administration Guide | |
Chapter 5
Using LoggingThis chapter describes the logging features and functions of the Sun Java System Application Server. In addition, components for which logging may be used are discussed.
This chapter includes the following topics:
About LoggingLogging is a useful debugging and diagnostic tool when used in applications. It also increases the developer’s productivity. The Sun Java System application server’s own log output can help identify and diagnose server configuration and deployment problems.
Logging within the Sun Java System Application Server uses the Java logging API. Sun Java System Application Server collects and stores logging information in two log files, namely, access.log and server.log located in the logs directory. You can also direct logs to your own log file.
A logged message provides more information than simply the message itself. The additional information provided includes:
The type and order of the additional message information varies depending upon the platform used for logging and the logging service enabled for that platform. To enable the virtual server ID for logged messages, see Configuring the Log Service.
Logging on the UNIX PlatformThis section discusses how log files are created. In addition, this section includes the following topics:
Default Logging in server.log
On UNIX platforms, the log files are created in server.log located in the log sub-directory. Logs coming from all the server components and virtual servers of an instance are collected in this single file.
The default log level for the entire server can be set. However, you can also override the default log level for a particular subsystem at the subsystem level. You can also redirect stdout and stderr to the server's event log and direct the log output to the operating system's system log. Additionally, you can direct stdout and stderr content to the server’s event log. Log messages by default are sent to stderr in addition to the specified server log file.
Another feature available is to log the virtual server ID with the log message. This is a useful feature when multiple virtual servers are used to log messages to the same log file. You can choose to write the log messages to system log. When you do so, logging is not performed on the server.log file. Instead the syslog logging service on UNIX is used to produce and manage logs.
You can also use the server.xml attributes to control the contents of this file. For details about the server.xml file, see the Sun Java System Application Server Administrator’s Configuration File Reference.
Example of server.log
The following is an example of server.log.
Timestamp, Log Level, (PID vsid(optional)): messageID: message
[01/Aug/2002:11:39:31] INFO ( 1224): CORE1116: Sun Java System Application Server 7 2004Q2
[01/Aug/2002:11:39:36] INFO ( 1224): CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.4.0_02-20020712] from [Sun Microsystems Inc.]
[01/Aug/2002:11:39:50] INFO ( 1224): JMS5023: JMS service successfully started. Instance Name = domain1_server1, Home = [D:\install_7_29\imq\bin].
[01/Aug/2002:11:39:53] INFO ( 1224): CIS0056: Creating TCP ServerConnection at [EndPoint [IIOP_CLEAR_TEXT:192.18.145.66:3700:false]]
[01/Aug/2002:11:39:53] INFO ( 1224): CIS0057: Created TCP ServerConnection at [EndPoint [IIOP_CLEAR_TEXT:192.18.145.66:3700:false]]
[01/Aug/2002:11:39:54] INFO ( 1224): CIS0054: Creating TCP Connection from [-] to [EndPoint [IIOP_CLEAR_TEXT:192.18.145.66:3700:false]]
Changing Default Log File Location
While deploying an enterprise or web application, you are provided the option of pre-compiling the JSPs in the application. The log messages pertaining the JSPs that are being compiled are stored in the administration server's log file usually located at {domain_root}/{domain_name}/admin-server/logs/server.log. This is the default logging option.
Since all the messages are logged to the same file, exceptions or errors thrown while deploying applications using pre-compiled JSPs could get lost in the volume of messages in the common log file. When multiple applications are being deployed to multiple instances under a given domain, the log messages in the admin-server will need to be carefully scrutinized for any exceptions relevant to a particular application's JSPs.
Therefore, it is better to log messages pertaining to applications that are deployed using pre-compiled JSPs, in the server instance’s server.log file, instead of the administrative server’s server.log file.
To redirect the log messages to your Sun Java System Application Server instance’s server.log file, change the path to the log file in the Administrator Interface. See Configuring the Log Service for more information.
Logging Using syslog
For stable operational environments where centralized logging is required syslog is appropriate. For environments where log output is frequently required for diagnostics and debugging, individual server instance or virtual server logs may be more manageable.
By using the syslog log file, in conjunction with syslogd, and the system log daemon, you can configure the syslog.conf file to:
- Log messages to the appropriate system log
- Write messages to the system console
- Forward logged messages to a list of users, or forward logged messages to another syslogd on another host over the network
Configuring syslog
To allow better manageability and readability, you can direct messages with less severity to be stored in a separate file by configuring syslog.conf located in the /etc directory.
To configure syslog:
- To direct messages with less severity to be stored in a separate file add the following command to the syslog.conf file in Solaris:
daemon.debug /var/adm/iasdebug
- Provide a hang-up signal to syslogd. This can be done by using the following command:
kill -HUP <PID syslogd>
- Go to the Admin Server in the Administration interface and select the Write to system log option. Save, and apply changes. Restart the Admin Server for the changes to take effect.
An example of a configured Solaris syslog.conf file follows:
#ident "@(#)syslog.conf 1.5 98/12/14 SMI "/* SunOS 5.0 */
#
# Copyright (c) 1991-1998 by Sun Microsystems, Inc.
# All rights reserved.
#
# syslog configuration file.
#
# This file is processed by m4 so be careful to quote (`') names
# that match m4 reserved words. Also, within ifdef's, arguments
# containing commas must be quoted.
#
*.err;kern.notice;auth.notice /dev/sysmsg
*.err;kern.debug;mail.crit /var/adm/messages
daemon.info;daemon.err;daemon.debug;daemon.alert;daemon.crit;daemon.warnin g /var/adm/iaslog
daemon.debug /var/adm/iasdebug
#daemon.notice; /var/adm/iaslognotice
#daemon.warning; /var/adm/iaslogwarning
#daemon.alert; /var/adm/iaslogalert
#daemon.err; /var/adm/iaslogerr
#*.alert;kern.err;daemon.err operator
#*.alert root
*.emerg *
# if a non-loghost machine chooses to have authentication messages
# sent to the loghost machine, un-comment out the following line:
#auth.notice ifdef(`LOGHOST', /var/log/authlog, @loghost)
mail.debug ifdef(`LOGHOST', /var/log/syslog, @loghost)
#
# non-loghost machines will use the following lines to cause "user"
# log messages to be logged locally.
#
ifdef(`LOGHOST', ,
user.err /dev/sysmsg
user.err /var/adm/messages
user.alert `root, operator'
user.emerg *
)
For more information, see the syslog.conf man page.
Any change made to syslog.conf will require a restart of the Sun Java System Application Server for the change to take effect.
Since logging to syslog means, logs from all Sun Java System Application Servers, and other daemon applications are collected in the same file, logged messages are enhanced with the following information to identify Sun Java System Application Server-specific messages from the particular server or virtual server instance:
The log service can be configured for both the server instance and the virtual server instance in the server.xml file. The log service configuration for the virtual server instance is described in the section About Virtual Servers and Logging. The log service configuration for the server instance is described in Configuring Logging Through the Administration Interface.
Log levels are configurable through the Administration interface for applicable subsystems and components.
For more information on the syslog logging mechanism used in the UNIX operating environment, use the following man commands at a terminal prompt:
man syslog
man syslogd
man syslog.conf
Example of syslog messages
The following is an example of syslog messages.
Timestamp, hostname [instance_name], [subsystem], [vsid], Message ID, Loglevel, Message data
Jul 19 14:33:18 strange /usr/lib/nfs/lockd[164]: [ID 599441 daemon.info] Number of servers not specified. Using default of 20.
Jul 19 14:33:20 strange ntpdate[181]: [ID 558275 daemon.notice] adjust time server 192.18.56.149 offset 0.06702 6 sec
Jul 19 14:38:13 strange xntpd[248]: [ID 204180 daemon.info] synchronisation lost
Jul 19 14:38:47 strange server1 appservd[374]: [ID 702911 daemon.info] INFO ( 374): CORE1116: Sun Java System Application Server 7 2004Q2
Jul 19 14:38:48 strange server1 appservd[374]: [ID 702911 daemon.info] FINE ( 374): Collecting statistics for up to 1 processes with 128 threads, 200 listen sockets, and 1000 virtual servers
Using Log LevelsThis section discusses log levels and how you can assign a log level for each Sun Java System Application Server subsystem.
The following topics are described:
About Log Levels
The Sun Java System Application Server uses the standard JDK 1.4.2_02 log levels for selective logging of information. In addition to the standard JDK log levels, Sun Java System Application Server has added log levels designed to map more intuitively to server.log and to tightly integrate with Solaris.
When logged messages are routed to server.log, they are also mapped to log levels as defined in the Sun Java System Application Server Log Levels Mapped to server.log.
You can assign a log level for each Sun Java System Application Server subsystem for which logging is enabled. A log level is useful to streamline the amount of message information that is recorded during runtime. The level is specified in the server.xml file for the intended subsystem. You can specify the log level from the Administration interface for the selected subsystem, or, you can edit the server.xml file directly to set the desired log level for the selected subsystem.
To set the log level for each subsystem or component directly in the server.xml file, see the Sun Java System Application Server Administrator’s Configuration File Reference.
The Log levels described in the table Log Levels match the requirements of the JDK1.4.2_02 logging API specification. However, the log levels ALERT and FATAL are specific to Sun Java System Application Server and are not implemented in the JDK1.4.2_02 logging API.
The following table defines the log levels and messages in Sun Java System Application Server, in increasing order of severity. The left column lists the log level designation in the Sun Java System Application Server and the right column provides a brief description of each log level.
Log Levels Used for syslog Configuration
The following table contains a list of log levels that can be configured within the Sun Java System Application Server when using syslog. The left column lists the log level designation in the Sun Java System Application Server, and right column provides the corresponding log level in the syslog facility.
Log Levels Used by HTTP Load Balancer
The HTTP load balancer (Enterprise Edition) uses log levels that maps to the log levels of the Web Server on which the load balancer is configured. For more information on the load balancer’s log levels, see Configuring Log Messages.
About Virtual Servers and LoggingThe Sun Java System Application Server can have virtual server instances. Each virtual server within a application server instance has its own identity and may have its own log file. The use of separate log files for each virtual server can help track server activity for particular transactions and resources.
To specify the log file name for a virtual server from the Administration interface, go to the HTTP Server link from the directory tree and open the server instance element under the virtual server folder to display the General tab on the right frame. You can enter the path and name of the log file for this virtual server in the Log File field.
Note
When logging is enabled and an application is running, logged messages from the application are logged without the virtual server ID.
You can also direct logged messages from multiple virtual servers to one server log file. When so doing, you may wish to enable the log-virtual-server-id in the log service element of the server.xml file. This helps users to distinguish log messages originating from different virtual servers.
<log-service level="FINEST" log-stdout="false" log-stderr="false" echo-log-messages-to-stderr="false" create-console="false" log-virtual-server-id="true" use-system-logging="false">
</log-service>
<http-listener>
<virtual-server-class>
<virtual-server id="server1" http-listeners="http-listener-1" hosts="strange" mime="mime1" state="on" accept-language="false"/>
<virtual-server id="server2" hosts="strange" mime="mime1"/>
</virtual-server-class>
</http-listener>
In this example, <log-service log-virtual-server-id="true"> is responsible for including virtual_server_id in every log message. This allows you to differentiate messages coming from different virtual servers. The absence of attribute “log-file” in the virtual-server element, causes all the virtual servers to log messages to a single file.
About LoggersLogging can be enabled or disabled selectively at the subsystem level. Logging control for each subsystem is specified in the server.xml file, as described in the Sun Java System Application Server Configuration File Reference. Each subsystem has its own logger in accordance with the requirements of the JDK1.4.2_02 logging API.
In the following table, the left column defines the subsystem and the right column the element in the server.xml file for each subsystem.
Table 5-3 Subsystems and Locations in Sun Java System Application Server
Subsystem
Element
Administration Server
<admin-service>
EJB Container
<ejb-container>
Web Container
<web-container>
MDB Container
<mdb-container>
Sun Java System Message Queue (JMS service)
<jms-service>
Security Service
<security-service>
Java Transaction Service (JTS)
<transaction-service>
Object Request Broker (ORB)
<iiop-service>
Default handlers1
<log-service>
1Default handlers refers to the default logger associated with all server.xml entries that are not associated with a particular subsystem, such as the utility classes.
The table Log Levels defines the log levels, in increasing order of severity, provided for messages in Sun Java System Application Server. These log levels match the requirements of the JDK1.4.2_02 logging API specification. In addition, the log levels ALERT and FATAL are specific to Sun Java System Application Server and are not supported in the JDK1.4.2_02 logging API.
About Client Side LoggingThe Application Client Container (ACC) has its own log service and can only log to a local file.
The ACC typically runs in its own process, on a different host from the application server. As such it has its own logging infrastructure and its own log file. The ACC configuration is held in the file sun-acc.xml.
The client subsystem logging element for the ACC is log-service. The following table lists the element, and the attributes, each with the noted default and range of values.
Table 5-4 ACC Logging Element
Element
Attribute
Description
log-service
file
ACC log file; when empty or missing, log to stdout.
log-service
level
ACC log level.
An example of the sun-acc.xml file is provided in the Sun Java System Application Server Configuration File Reference.
Redirecting Application and Server Log OutputFor developers, it is important that the application logs and server logs be made readily available during unit testing for application components and J2EE applications. On the UNIX platform, many developers are comfortable with simply having the log messages stream to stderr in the terminal window in which the server instance is started, or, use the command tail -f to see the log messages written in log files.
The server.xml file contains attributes that can be set for stdout and stderr to direct logged messages to a log file or to the terminal window, and so forth. See the Sun Java System Application Server Configuration File Reference for more information on the use of stdout and stderr.
See Configuring the Log Service for information on the log service.
Log File ManagementYou can set up your access and event log (server.log) files to be automatically archived. At a certain time, or after a specified interval, your logs are rotated. Sun Java System Application Server saves the old log files and stamps the saved file with a name that includes the date and time they were saved.
Note
Although you can create multiple virtual servers and associate a log file for each virtual server, log rotation settings for individual virtual servers is not supported.
For example, you can set up your access log files to rotate every hour, and Sun Java System Application Server saves and names the file “access.199907152400,” where name of the log file, year, month, day, and 24-hour time is concatenated together into a single character string. The exact format of the log archive file varies depending upon which type of log rotation you set up.
Note
These facilities are primarily provided for non-Solaris platforms.
For Solaris, these facilities are not enabled by default, and you must use the native Solaris operating system log management facilities such as logadm on Solaris 9. On Solaris 8, the preferred utility for log management would be the cron facility described in Using the Solaris cron Utility to Schedule Execution of logadm.
Depending on the operating system, there are four distinct ways you can perform log rotations. These are discussed in the section that follows. Topics include:
For Solaris 9
- Using Solaris logadm utility. For more information, see Rotation Using Solaris logadm Utility.
For Solaris (any version)
- Using Solaris cron utility. For more information, see Rotation Using Solaris “cron” Utility.
Internal-daemon Log Rotation
Internal-daemon log rotation is available for UNIX operating system.
Internal-daemon log rotation occurs within the HTTP daemon and can only be configured at the server instance startup time. Internal daemon log rotation allows the server to rotate logs internally without requiring a server restart.
Logs rotated using this method are saved in the following format:
access.<YYYY><MM><DD><HHMM>
error. <YYYY><MM><DD><HHMM>
You can specify the time used as a basis to rotate log files and start a new log file. For example, if the rotation start time is 12:00 a.m., and the rotation interval is 1440 minutes (one day), a new log file is created immediately upon save regardless of the present time and collects information until the rotation start time. The log file rotates every day at 12:00 a.m., and the access log is stamped at 12:00 a.m. and saved as access.199907152400. Likewise, if you set the interval at 240 minutes (four hours), the four-hour intervals begin at 12:00 a.m. such that the access log files will contain information gathered from 12:00 a.m. to 4:00 a.m., from 4:00 a.m. to 8:00 a.m., and so forth.
If log rotation is enabled, log file rotation starts at server startup. The first log file to be rotated gathers information from the current time until the next rotation time. Using the previous example, if you set your start time at 12:00 a.m. and your rotation interval at 240 minutes, and the current time is 6:00 a.m., the first log file to be rotated will contain the information gathered from 6:00 a.m. to 8:00 a.m, and the next log file will contain information from 8:00 a.m. to 12:00 p.m. (noon), and so forth.
Scheduler Based Log Rotation
Scheduler log rotation, allows you to archive log files immediately or have the server archive log files at a specific time on specific days. To archive log files immediately select Admin Server from the left pane of the Administration interface. Then, click on the Logging link at the top of the right page. Next, click Log Rotation. Finally, click Archive.
Logs rotated using the scheduler method are saved as the original filename followed by the date and time the file was rotated. For example, access might become access.24Apr-0430PM when it is rotates at 4:30 p.m.
Log rotation is initialized at server startup. If rotation is turned on, Sun Java System Application Server creates a time-stamped access log file and rotation starts at server startup.
Once the rotation starts, Sun Java System Application Server creates a new time stamped log file when there is a request or error that needs to be logged to the access or error log file and it occurs after the prior-scheduled “next rotate time”.
Note
For server logging directed to a file other than syslog on Solaris, you must archive the server logs.
To archive log files and to specify use of the schedulerd control method, select Admin Server from the left pane of the Administration interface. Then, click on the Logging link at the top of the right page. Next, click the Scheduler based Log Rotation box. Finally, OK. The current state of thescheduler is indicated.
Rotation Using Solaris logadm Utility
The Solaris 9 operating system incorporates the utility logadm which can be used to perform an array of functions with logged messages.
Particular to the Sun Java System Application Server, this utility is useful for performing log rotation tasks when running it from the Solaris cron utility, described in Using the Solaris cron Utility to Schedule Execution of logadm.
You can specify the following log rotation details with respect to log files:
The above details are specified in the file logadm.conf located in:
n /etc/logadm.conf
A sample logadm.conf file follows:
# Copyright 2001-2002 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
# ident "@(#)logadm.conf 1.2 02/02/13 SMI"
#
# logadm.conf
#
# Default settings for system log file management.
# The -w option to logadm(1M) is the preferred way to write to this
# file,
# but if you do edit it by hand, use "logadm -V" to check it for
# errors.
#
# The format of lines in this file is:
# <logname> <;options>
# For each logname listed here, the default options to logadm
# are given. Options given on the logadm command line override
# the defaults contained in this file.
# # logadm typically runs early every morning via an entry in
# root's crontab (see crontab(1)).
#
/var/log/syslog -C 8 -P 'Tue Jul 9 10:10:00 2002' -a 'kill -HUP `cat
/var/run/syslog.pid`' /var/adm/messages -C 4 -P 'Tue Jul 30 10:10:00 2002' -a
'kill -HUP `cat /var/run/syslog.pid`' /var/cron/log -c -s 512k -t /var/cron/olog
/var/lp/logs/lpsched -C 2 -N -t '$file.$N'
#
# The entry below is used by turnacct(1M)
#
/var/adm/pacct -C 0 -N -a '/usr/lib/acct/accton pacct' -g adm -m 664 -o adm -p never
#
# The entry below will rotate Sun Java System application server's default logfile
# every day provided the current logfile size is >= 512k. It will compress
# the old log file before archiving it and also delete the old files after 30
# days. The compression is done with gzip(1) and the resulting log file has
# the suffix of .gz.
/var/appserver/domains/domain1/server1/logs/server.log -A 30d -s 512k -p 1d -z
Alternatively, you can start log rotation on a specific file by invoking the logadm command interactively.
The following example rotates syslog and keeps eight log files. Old log files are placed in the directory /var/oldlogs instead of /var/log:
% logadm -C8 -t'/var/oldlogs/syslog.$n' /var/log/syslog
You can also use an interactive command-line option to invoke rotation on a file specified in /etc/logadm.conf, but with different or modified options.
If options are specified both in /etc/logadm.conf and on the command-line, those in the /etc/logadm.conf file are applied first. Therefore, the command-line options override those in /etc/logadm.conf. An example of this is as follows:
% logadm /var/appserver/domains/domain1/server1/logs/server.log -p now
The above command rotates the given file using all the options provided for that file in /etc/logadm.conf.
Note
When multiple options are specified at a time, there is an implied AND between them. This means that all conditions must be met before the log is rotated.
For detailed information on logadm utility and its options, please refer to its manpage as follows:
% man logadm
OR
% logadm -h
Rotation Using Solaris “cron” Utility
On Solaris 8, the cron utility can be used to perform application server log rotations. Cron-based log rotation is initialized at server startup. If rotation is turned on, the server creates a time-stamped access log file and rotation starts at server startup.
To perform application server log rotation use the following command:
% crontab -e
This starts your favorite editor (defined by env. variable $EDITOR) so that you can provide the list of cron entries.
This section includes the following topics:
About the crontab Entry Format
A crontab file consists of lines of six fields each. The fields are separated by spaces or tabs. The first five fields are integer patterns that specify the following:
Using this format, you can specify access and eventlog files to be rotated at specified time of day/week/month and schedule to repeat the rotations. For example,
0 0 * * 1-5
/opt/SUNWappserver7/appserver/domains/domain1/server1/bin/rotatelogs
0 12 * * 1-5
/opt/SUNWappserver7/appserver/domains/domain1/server1/bin/rotatelogs
0 * * * 1-5
/opt/SUNWappserver7/appserver/domains/domain1/mainserver/bin/rotatelogs
This rotates access and log files for server1 at midnight and noon every day between Monday and Friday; while access and log files for mainserver is rotated every hour of every day between Monday and Friday.
The crontab files are stored under /var/spool/cron/crontabs/. You can create the crontab file as an end user or root. Depending on your privileges, you can see the crontab entries by using the following command:
% crontab -l username
Using the Solaris cron Utility to Schedule Execution of logadm
The cron command starts a process that executes commands at specified dates and times. Regularly scheduled commands can be specified according to instructions found in crontab files in the directory /var/spool/cron/crontabs.
As an example of a regularly scheduled command used with cron, the following entry in crontab will start logadm everyday at midnight.
0 0 * * 0-6 logadm
Note that users can submit their own crontab file using the crontab(1) command.
To keep a log of all actions taken by cron, CRONLOG=YES (by default) must be specified in the /etc/default/cron file. /etc/cron.d/logchecker is a script that checks to see if the log file has exceeded the system ulimit. If so, the log file is moved to /var/cron/olog.
Configuring Logging Through the Command-line InterfaceYou can configure aspects of the logging service from the command-line for the server instance and for the virtual server instance.
To get all of the log-service attributes for the server instance:
asadmin> get instance_name.log-service.*
The log-service attributes are also defined in the table Log Service Attributes.
An example of using this command with a designated server instance name follows:
asadmin> get server1.log-service.*
The list of attributes for the logging service of the server1 instance is returned. You can configure each listed attribute by using the set command.
To enable the logging of a virtual server ID for the virtual server instance, enter the following command at the terminal prompt:
asadmin> get instance_name.LogVirtualServerId
The current state of the LogVirtualServerId is returned. If the state is false, you can enable it with the set command as follows:
asadmin> set instance_name.LogVirtualServerId=true
To set the log file name for a virtual server instance, use the set command as follows:
asadmin> set instance_name.virtual-server.<virtual server id>.logFile=<log file>
As an example, the following set log file command is issued:
asadmin> set instance2.virtual-server.instance2.logFile=/space/IAs7se/appserver7/appserv/doma ins/domain1/instance2/logs/log
For more information on command syntax, see the command-line interface help.
For more information on using asadmin, see Appendix A, "Using the Command Line Interface."
Configuring Logging Through the Administration InterfaceThis section describes the tasks you can perform through the Sun Java System Application Server Administration interface to configure the available logging service options for both server-wide (global) elements, directives, and application components.
This section includes the following topics:
Configuring the Log Service
The log service is an element within the J2EE Service Element category in the server.xml file, as described in the Sun Java System Application Server Configuration File Reference. The log service is used to configure the system logging service, which includes the following log files:
Configuration of the system logging service includes specifying values for attributes of the log service element.
You can configure the following attributes for the log service element through the Administration interface.
The Log Service link is accessible from the expanded tree hierarchy for the server instance in the left pane of the Administration interface. The following table describes each of the attributes that can be configured, along with the default and range of values allowed.
Table 5-5 Log Service Attributes
Attribute
Default
Description
file
server.log1
(optional) Overrides the name or location of the server log. The file and directory in which the server log is kept must be writable by whatever user account used to run the server.
level
INFO
(optional) Controls the default type of messages logged by other elements to the server log. Allowed values are as follows, from highest to lowest: FINEST, FINER, FINE, CONFIG, INFO, WARNING, SEVERE, ALERT, FATAL.
Each value logs all messages for all lower values; for example, FINEST logs all messages, and FATAL logs only FATAL messages. The default value is INFO, which logs all INFO, WARNING, SEVERE, ALERT, and FATAL messages.
log-stdout
True
(optional) If true, redirects stdout output to the server log. Legal values are on, off, yes, no, 1, 0, true, false.
log-stderr
True
(optional) If true, redirects stderr output to the server log. Legal values are on, off, yes, no, 1, 0, true, false.
echo-log-messages-to-stderr
True
(optional) If true, sends log messages to stderr in addition to the server log. Legal values are on, off, yes, no, 1, 0, true, false.
create-console
False
(optional) If true, creates a console window on Windows operating system for stderr output. Legal values are on, off, yes, no, 1, 0, true, false.
log-virtual-server-id
False
(optional) If true, virtual server IDs are displayed in the virtual server logs. These are useful if multiple virtual-server elements share the same log file.
use-system-log
False
If true, uses the UNIX syslog service to produce and manage logs.
1In the directory specified by the log-root attribute of the server element.
Configuring Logging for Application Server Components and Subsystems
This section describes how to enable logging and select a log level for Sun Java System Application Server components and subsystems. Note that the Java Transaction Service component has more than one log file. Since most of the components and subsystems are handled in the same way with respect to configuring a log level, the procedure to select a log level is documented one time only, for the indicated grouping of components and subsystems.
The following components and subsystems can utilize selective logging of server messages. You can become familiar with the components and subsystems from the references to other topics within this guide as indicated.
- ORB - Configuring Support for Corba-based Clients
- Web Container - Configuring J2EE Services
- EJB Container - Configuring J2EE Services
- MDB Container - Configuring J2EE Services (within the EJB container)
- Java Transaction Service - Configuring J2EE Services
- JMS Service - Java Message Service
- Virtual Server - Using Virtual Servers
To Specify a Log Level
To specify a log level for ORB, Web Container, EJB Container, MDB Container (within the EJB Container), Java Transaction Service, and JMS Service, perform the following procedure:
- In the left pane of the Administration interface, expand the Sun Java System Application Server instance to display the components and subsystems you wish to edit.
- Click the link for the desired component or subsystem.
- In the right page of the Administration interface, select one of the following log level parameters, from the Log Level drop-down list. The log levels are described in About Log Levels.
To Specify a Log File: (Virtual Server)
- In the left pane of the Administration interface, expand the Sun Java System Application Server instance to display the HTTP Server subsystem.
- Click the HTTP Server link.
- Click the Virtual Server link.
- Click the desired server instance link.
- In the right page of the Administration interface, under the General tab, enter the desired directory path and file name for the Log File field.
To Specify a Transaction Log Location: (Java Transaction Service)
- In the left pane of the Administration interface, expand the Sun Java System Application Server instance to display the Transaction Service subsystem.
- Click the Transaction Service link.
- In the right page of the Administration interface, under the Advanced field group, enter the desired directory path and file name for the Transaction Log Location field.
Configuring the Directives for Error Logging
Sun Java System Application Server includes error logging directives for the init.conf file. The following directives are included:
- Error Log Date Format. The ErrorLogDateFormat directive specifies the date format that the server logs use.
- Log Flush Interval. The LogFlushInterval determines the maximum time interval, in seconds, before which the access log is flushed from the memory into the access.log file.
- Pid Log. PidLog specifies a file in which to record the process ID (pid) of the base server process. Some of the server support programs assume that this log is in the server root, in logs/pid.
All the directives for init.conf are fully described in the Sun Java System Application Server Configuration File Reference.
Viewing the Access Log FileYou can view both the Administrator server’s and the Sun Java System Application Server instance’s http log files.
To view the Administration Server’s http log, select the Admin Server from the left pane in the Administration interface, and then choose the Logging tab from the right page. The View HTTP Access Log link is displayed. Select this link to view the configured access log.
To view an access log for the application server instance, click the server instance desired from the left pane of the Administration interface. Click on the Logging tab from the right pane. Click the View Access Log link to display the configured active access log for that server instance.
Viewing the Event Log FileYou can view both the Administrator server’s and the Sun Java System Application Server instance’s active event log files.
To view the Administrator server’s event log, select the Admin Server from the left pane, and then choose the Logging tab from the right page. The View Event Log link will be displayed. Select this link to view the configured event log.
To view the event log for the application server instance, click the server instance desired from the left pane of the Administration interface, and then choose the Logging tab from the right pane. The View Event Log link will be displayed. Select this link to view the configured event log.
Setting Log PreferencesDuring installation, an access log file named access is created for the server. You can customize access logging for any resource by specifying whether to log accesses, what format to use for logging, and whether the server should spend time looking up the domain names of clients when they access a resource.
To use one log file for multiple virtual servers, LogVsId should be turned on in the server.xml file for the event log. See the Sun Java System Application Server Configuration File Reference for details. Alternatively, LogVsID can be turned on in the Admin Server Logging tab of the Administration interface.
Follow the steps below to enable the Log virtual server ID from the Administration interface. The changes are effected following restart of the Administration server.
This setting requires a restart of the Sun Java System Application Server for the change to take effect.
Running the Log AnalyzerThe flexanlg is a Log Analyzer tool used for log file reporting. The Log Analyzer can be used only when logging is directed to a file other than syslog.
Use the log analyzer to generate statistics about your default server, such as a summary of activity, most commonly accessed URLs, times during the day when the server is accessed most frequently, and so on. The log analyzer cannot generate statistics for virtual servers other than the default server. However, statistics can be viewed for each virtual server as described in Viewing the Access Log File.
Note
Before running the log analyzer, you must rotate the server logs. For more information, see Log File Management.
You can run the log analyzer command from the command-line, by running the tool flexanlg, which is in the directory install_dir/bin/flexanlg.
To run flexanlg, type the following command and options at the command prompt:
flexanlg [ -P ] [-n name] [-x] [-r] [-p order] [-i file]* [ -m metafile ]* [ o file][ c opts] [-t opts] [-l opts] [-h help]
Command Options (Options marked with * can be repeated).
-i filename
input log file(s)
-P
proxy log format
-n servername
the name of the server
-x
output in HTML
-r
resolve IP addresses to hostnames
-p [ c, t, l ]
output order; default order is counts, time statistics, and lists
-m filename
meta file(s)
-o filename
output log file; default is stdout
-c [ h, n, r, f, e, u, o, k, c, z ]
count these items; default is: h, n, r, e , u, o, k, c
h: total hits
n: 304 Not Modified status codes (use local copy)
r: 302 Found status codes (redirects)
f: 404 Not Found status codes (Document Not Found)
e: 500 Server Error status codes (Misconfiguration)
u: total unique URLs
o: total unique hosts
k: total kilobytes transferred
c: total kilobytes saved by caches
z: Do not count any items
-t [ sx, mx, hx, xx, z ]
find general statistics; default is: s5m5h24x10
s (number): Find top (number) seconds of log
m (number): Find top (number) minutes of log
h (number): Find top (number) hours of log
u (number): Find top (number) users of log
a (number): Find top (number) user agents of log
r (number): Find top (number) referers of log
x (number): Find top (number) for miscellaneous keywords
z: Do not find any general statistics
-l [ cx, hx ]
Make a list of the specified suboption; default is: c+3h5
EXAMPLE: Using the flexanlg command
flexanlg -i /var/opt/SUNQappserver7/domains/domain1/server1/logs/access