Enportal/5.5/admin/system administration/Log Files: Difference between revisions
imported>Jason.nicholls m (1 revision) |
imported>Mike.berman |
||
(One intermediate revision by the same user not shown) | |||
Line 122: | Line 122: | ||
** handlers.crsFile.maxSize=1024000 | ** handlers.crsFile.maxSize=1024000 | ||
* Masking controls are also provided for controlling the verbosity of what is written to a number of the log files. The mask uses bits to turn on/off various information, and can be the sum of any of (0,1,2,4,8). | * Masking controls are also provided for controlling the verbosity of what is written to a number of the log files. The mask uses bits to turn on/off various information, and can be the sum of any of (0,1,2,4,8). | ||
==== Enabling crsRequest.log ==== | |||
To enable output to crsRequest.log, modify logger-crs.properties to show the following: | |||
<code>[ini,N] | |||
#loggers.request.mask=0,2,4,8 | |||
loggers.request.mask=0xFFFFFFFF | |||
loggers.request.assignedHandlers.requestFile.formatter=requestFormatter | |||
# | |||
#File handler that logs all executive log records to the specified file. | |||
handlers.requestFile.class=com.edgetech.util.logger.FileHandler | |||
handlers.requestFile.fileName=crsRequest.log | |||
handlers.requestFile.maxSize=1024 | |||
</code> | |||
==== CRS Debugging with crsoutput.csv ==== | |||
enPortal does not have any built-in tool to examine the raw HTTP request/response between the enPortal and proxied backend applications. Normally, it is ideal to have the backend application run in HTTP mode. That way, you can use wireshark to view the traffic between the portal and the backend application. Sometimes that is not possible, such as when running in HTTPS mode. In this case, you can use Fiddler to do two captures and make the comparison between them. First, you capture the traffic directly with the backend application. Secondly, you capture the traffic accessing the application when it is proxied in enPortal. Usually, by doing call by call comparison and comparing the Request and Response of each call is enough to figure the issues why it is not working in enPortal. You may have to examine some of HTTP headers and debug CRS rules. | |||
Perform the following steps to temporarily enable the CRS global log file: | |||
Create following three parameters in custom.properties: | |||
<code>[ini,N] | |||
crs.log.global.active=true | |||
crs.log.file.active=true | |||
crs.log.file.name=${catalina.home}/logs/crsoutput.csv | |||
</code> | |||
Re-start enPortal and access a proxied channel, then examine the crsoutput.csv file in the <tt>${INSTALL_HOME}/server/logs</tt> directory. | |||
{{Tip|The CRS debugging files can increase in size very rapidly, so should only be enabled briefly and then disabled when troubleshooting is completed.}} | |||
==Submitting Log Files to Technical Support== | ==Submitting Log Files to Technical Support== | ||
For information on submitting a support ticket, see the [[ | For information on submitting a support ticket, see the [[support/technical_support|Technical Support]] page. | ||
For instructions on sending information to the Technical Support team, see the [[ | For instructions on sending information to the Technical Support team, see the [[support/submitting_files_for_technical_support|Submitting Files for Technical Support]] page. |
Latest revision as of 04:43, 29 November 2014
enPortal provides various log files to assist you with monitoring and troubleshooting. This article details the log files that are provided.
enPortal Log Files
Location
enPortal maintains log files primarily in the following location:
- [INSTALL_HOME]/server/logs
Summary
The following table summarizes each log file and the information it provides:
Log File | Description |
---|---|
error.log.[date] | Subset of appBoard.log, containing only Error messages |
ldap.log.[date] | Messages related to LDAP |
localhost_access_log.[date].txt | Detail of all individual user HTTP requests made to the system. Note: enPortal does not log access to specific individual Widgets or Boards, but could enable debugging of all data queries so that those could be audited. |
session.log.[date] | Detail of all User sessions in the system, including: - Timestamp |
system.log.[date] | All errors, warnings, and informational messages related to the enPortal server. including: - Expired license errors |
tomcat.log.[day_of_week] | The standard log file for the Tomcat web application container |
Rotation
Log file rotation is configured in the config.properties file under [INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/, including settings such as the following:
[ini,N]
- 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
- 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.
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.
enPortal CRS Log Configuration
The custom CRS log for the enPortal proxy is not handled by log4j. This log should only be enabled when specific CRS debugging is being performed. The log files are not rotated, but there are some controls you can implement to manage the size and content of the CRS log.
- Example: Observe the following lines in [INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/logger-crs.properties:
- handlers.crsFile.class=com.edgetech.util.logger.FileHandler
- handlers.crsFile.fileName=crs.log
- You could add the following line to logger-crs-custom.properties to limit the size of this particular log file to about 1 MB:
- handlers.crsFile.maxSize=1024000
- Masking controls are also provided for controlling the verbosity of what is written to a number of the log files. The mask uses bits to turn on/off various information, and can be the sum of any of (0,1,2,4,8).
Enabling crsRequest.log
To enable output to crsRequest.log, modify logger-crs.properties to show the following:
[ini,N]
- loggers.request.mask=0,2,4,8
loggers.request.mask=0xFFFFFFFF
loggers.request.assignedHandlers.requestFile.formatter=requestFormatter
- File handler that logs all executive log records to the specified file.
handlers.requestFile.class=com.edgetech.util.logger.FileHandler
handlers.requestFile.fileName=crsRequest.log
handlers.requestFile.maxSize=1024
CRS Debugging with crsoutput.csv
enPortal does not have any built-in tool to examine the raw HTTP request/response between the enPortal and proxied backend applications. Normally, it is ideal to have the backend application run in HTTP mode. That way, you can use wireshark to view the traffic between the portal and the backend application. Sometimes that is not possible, such as when running in HTTPS mode. In this case, you can use Fiddler to do two captures and make the comparison between them. First, you capture the traffic directly with the backend application. Secondly, you capture the traffic accessing the application when it is proxied in enPortal. Usually, by doing call by call comparison and comparing the Request and Response of each call is enough to figure the issues why it is not working in enPortal. You may have to examine some of HTTP headers and debug CRS rules.
Perform the following steps to temporarily enable the CRS global log file:
Create following three parameters in custom.properties:
[ini,N]
crs.log.global.active=true
crs.log.file.active=true
crs.log.file.name=${catalina.home}/logs/crsoutput.csv
Re-start enPortal and access a proxied channel, then examine the crsoutput.csv file in the ${INSTALL_HOME}/server/logs directory.
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.