Appboard/2.6/admin/log files

Overview

AppBoard provides a number of log files to record activity and to assist with monitoring and troubleshooting. By default these log files are set to be automatically compressed and rotated to prevent run-away disk usage.

Log files are stored in the following location: [INSTALL_HOME]/server/logs/

Log Files

The following table summarizes each log file and the information it provides:

Log File	Description
appBoard.log	All messages related to client-server communications Information about data queries made to the server Java runtime error messages Other errors and warnings User IP address
error.log	Subset of appBoard.log, containing only Error messages
ldap.log	Messages related to LDAP
localhost_access_log.[date].txt	Log of individual HTTP requests serviced by the system including proxied requests. For application access information covering enPortal channel, and AppBoard Stack and Board usage refer to the system.log. Includes Actor (role, user, domain) and session details in versions 2.6.2 or higher.
session.log	Detail of all User sessions in the system, including: Timestamp Role Domain Username Transaction Result Session ID Total number of concurrent logins Total number of concurrent logins in the User's Domain IP address
system.log	All errors, warnings, and informational messages related to the enPortal server. including: Expired license errors Items requested by the application that could not be located on the server User session information Application-level access log. This logs per-user accesses to enPortal Channels, AppBoard Stacks, and AppBoard Boards.
tomcat.log	The standard log file for the Tomcat web application container
blazeds.log	BlazeDS is used for serialization / de-serialization of messages to and from the Viewer and Builder. By default BlazeDS logging is disabled and this file will not be present. Unless instructed by support it is best to leave this disabled.

appBoard.log - AppBoardDataService

During regular operation the AppBoardDataService logs messages for all data queries made by active clients. These messages contain useful information around who made the request, how large the response was, how long it took, and other miscellaneous information such as whether the response was served from the cache or not.

The format of these messages is in key=value pairs as listed below:

Key	Description
transID	The unique transaction ID for this query since the AppBoard server was last started. The transaction ID is reported to the client in error situations - see the Data / Communications Errors page for more information.
session	This is the first 8 characters from the client session ID. This is enough to correlate the session against the session.log. Not all requests are associated with a session so this may not be present.
actor	If this request is associated with the session then include the actor. The actor is a string representation of the role, domain, and username in the format: role:domain?username
state	Internal state, typically either BEGIN for when a query request is received, and FINISH when serviced.
action	Internal request type.
namespace	The data requested, for most purposes this is the Data Collection requested.
cached & cache-age	If the data requested is already in the server cache, and the cache is still valid, then a cached response is given and cached is set to true. When a cached response is given the additional cache-age field is added to show the age of the response in seconds. If the cache is invalid, or not configured, then cached is set to false and the server has to fetch the data from the data source directly.
records	This is the size of response, the number of records/rows.
prefetch & prefetch-type	If server-side polling is configured for this Data Collection then a cached response is always given, and the prefetch field is set to true. If true the prefetch-type field is added to show whether the response if from the default or a temporary job - refer to the Caching & Polling documentation for more information.
total-time	This represents the time in milliseconds (1000 = 1 second) from when the request was first received (BEGIN) until the response given back to the client (FINISH). For cached responses this is typically very low. For responses that require the AppBoard server to fetch a response from a data source this can be much larger as this is dependent on the data source. For non-cached responses this is a useful metric to measure data source response time.

Configuring appBoard.log

The typical configurations performed on appboard logging are to change the log level or enable the BEGIN log statements.

To enable debug level logging or change the log level. Edit the file ${AppBoardHome}/server/webapps/enportal/WEB-INF/classes/log4j.xml and change the INFO level inside the following (ex: DEBUG, INFO, WARN, ERROR):

[ini,N] <appender name="AppBoardLogger" <param name="Threshold" value="INFO"/> ... </appender>

and you must also change this log level to match (ex: DEBUG, INFO, WARN, ERROR):

[ini,N] <logger name="com.edgetech.services">

 <level value="INFO"/>
 <appender-ref ref="AppBoardLogger"/>

</logger>

To enable BEGIN logging statement is disabled by default. To enable the BEGIN logging statement add the following to server/webapps/enportalWEB-INF/custom.properties:

appboard.log.begin=true

Monitoring Log Files

The AppBoard system administrator may want to pro-actively monitor the log files to check for any messages that may indicate an issue that needs attention. There are various third-party log-monitoring tools that can perform this operation.

The logging system contains logs from several product related processes and sources. To avoid having to monitor multiple log files, all error conditions are written to the error.log file. Error conditions that are captured in this file should be reviewed and are generally indicative of a configuration issue or a web content retrieval issue.

In order to detect error conditions in an enPortal/AppBoard server, monitor the log file: ${INSTALL_HOME}/server/logs/error.log. In this file, it is recommended to monitor for lines that begin with a timestamp and “ERROR” in the form as follows:

##:##:##:### - ERROR - …

An example of such a line would be:

06:51:19:866 - ERROR - AppBoardDataService - 47681: FINISH – doAction('findByQuery') namespace=cacheDB.SlaTrackNotes, session '2968d98378b7564b' not valid

It is also suggested to ignore lines that end with text such as:

… session ‘xxxxxxxxxxxxxxxx’ not valid

as these messages only refer to expired user sessions and are routine.

Configuring Rotation

Log file rotation is configured in the config.properties (most log files) and appboard.properties (appBoard.log) property files under [INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/.

The default configuration is as follows:

[ini,N]

1. Log cleanup settings

logwatch.error.prefix=${logger.logs.path}/error.log logwatch.error.numberToKeep=7 logwatch.error.compress=true

logwatch.system.prefix=${logger.logs.path}/system.log logwatch.system.numberToKeep=7 logwatch.system.compress=true

logwatch.session.prefix=${logger.logs.path}/session.log logwatch.session.numberToKeep=7 logwatch.session.compress=true

logwatch.ldap.prefix=${logger.logs.path}/ldap.log logwatch.ldap.numberToKeep=7 logwatch.ldap.compress=true

logwatch.access.prefix=${logger.logs.path}/localhost_access_log logwatch.access.numberToKeep=7 logwatch.access.compress=true logwatch.access.skiplast=true

1. Log cleanup settings

logwatch.appBoard.prefix=${logger.logs.path}/appBoard.log logwatch.appBoard.numberToKeep=7 logwatch.appBoard.compress=true

This background job can be used to clean up any files that always have the same prefix. It assumes either the files are names: (<logname>, <logname><suffix1>, <logname><suffix2>) or (<logname><suffix1>, <logname><suffix2>, and so on). In the first case, the one without the suffix is assumed to be the current log, while in the latter a flag “skiplast” is used to not archive/delete the last (in alpha-numeric ordering). This is only used for the tomcat access log.

numberToKeep does not include the current log, and compress will put the old log in a file named the same with ".zip" added. The process runs every 30 minutes to look for old files that need to be processed.

Log File Configuration

The standard log files above are written using the log4j library and can be configured through the enportal/WEB-INF/classes/log4j.xml file. For information on configuring log4j, please see: http://en.wikipedia.org/wiki/Log4j#Configuration

Of note, the following settings will change the verbosity of the log files and how long each daily log is kept.

[xml,N] <param name="Threshold" value="INFO"/> <param name="MaxBackupIndex" value="15"/>

Threshold can have values from most verbose to least of: TRACE, DEBUG, INFO, WARN, ERROR and FATAL.

The MaxBackupIndex is the number of daily logs to keep for each log file type, which is 15 by default.

Additional enPortal Logging

Refer to the enPortal Log File documentation for further information.

Submitting Log Files to Technical Support

For information on submitting a support ticket, see the Technical Support page.

For instructions on sending information to the Technical Support team, see the Submitting Files for Technical Support page.