In general, two types of logging files are located in the conf directory of the PAS for OpenEdge instance and ABL application:

  • The .xml files:
    • Control what is logged.
    • Declare the logging file name, log entry data format, and log file roll-over time.
    • Control how often the logging configuration is refreshed.
    Note: An example of an XML logging file is WEB-INF/logging.xml, which bootstraps the logging configuration.
  • The .properties files, which define the properties for log file name, roll-over time, default logging level, and log entry data format.
    Note: Whenever possible, check within the .properties files for the option you want to change before attempting to alter one of the XML files. In some cases, you may find no choice but to alter the XML file because a property may not exist for easy alterations.

As of OpenEdge 12, the process of configuring logging options has been greatly simplified. Previously, all modifications had to be made in a multitude of XML files. While many of these still exist, the most common properties are now in two files, which correspond to a specific purpose within the PAS for OpenEdge instance. The names for these properties consists of some common patterns:

  • psc.as.logging.application-area.fileName—When applicable, describes the log file name.
  • psc.as.logging.application-area.level—When applicable, supports the logging verbosity.
  • psc.as.logging.application-area.pattern—A list of tokens for data elements to be logged.

For logging outside of the MS Agent and ABL sessions, understand that its implementation is the Logback logging framework. Therefore, logging format property's placeholder tokens (the pattern portion) comes from the Logback documentation.

As a third-party, we:
  • Do not recreate the Logback documentation for PatternLayout, as it can change per release.
  • Use the Logback MDC service to expose HTTP request, and authentication and authorization event tokens that can also appear alongside the Logback Pattern Layout tokens.

We expose the Logback log entry patterns so that you can customize the log file for better integration with centralized log collection products and add additional fields of information for troubleshooting. A good example is the access log pattern: you can add it, recording the JSESSIONID header for each request, response, and/or Authorization header to track login credentials.

With this naming scheme and the token patterns established, this topic describes what each of the potential application areas provides in context of the running instance.

logging-pasoe.properties

Defines the properties used by PAS for OpenEdge for the log file name, roll over time, default logging level, and log entry data pattern for the following OpenEdge application services in the logging-tomcat.xml Logback configuration file:

  • psc.as.logging.authn—For all OpenEdge ABL application login event logging.
  • psc.as.logging.authz—For all OpenEdge ABL application URL access event logging.
    • AuthN and AuthZ are common abbreviations for [Auth]enticatio[n] and [Auth]ori[z]ation, respectively.
      • The authn log captures all of the direct login passes or failures, for when Spring authenticates with a user-ID and password.
      • The authz log captures all of the Spring URL authorization failures that reject a client request.
      • Both the authn and authz logs are matched to the ABL application, just like the Session Manager and MS Agent logs.
      • Both the authn and authz logs include the request-ID for corresponding to the server’s access log.
    • Typically, you would not change the authn and authz logging levels. Increasing the logging will only give you passed authentications and passed authorizations. Therefore, the logging verbosity is really related to the ABL application’s Java front-end components for timeouts, disconnects, failed Agent starts, and so on.
  • psc.as.logging.oeabl—For all OpenEdge ABL application webapps (oeabl.war) Session Manager and Spring Security logging.
    • Troubleshooting authentication and authorization failures are often captured in audit trail logs and this information is difficult to be extracted from the Spring log entries in the Session Manager log. Therefore, to make it simple, this property does the extraction and logging, though ABL Session Manager log is still the web application, Spring, and Session Manager log for troubleshooting functional failures.
    • You use the Session Manager log to troubleshoot a configuration problem or supply information to OpenEdge Engineering for identifying OpenEdge code error. Those are unrelated with ABL coding errors, except in the case of OERealm coding issues while returning user account information to the authentication process.
  • psc.as.logging.oeman—PAS for OpenEdge application server remote manager web application.
  • psc.as.logging.oests—STS web application service (for OpenEdge Authentication Gateway).
  • psc.as.logging.oehealth—PAS for OpenEdge web server health scanner service.
  • psc.as.logging.oedbg—PAS for OpenEdge remote ABL application debugger service.
  • psc.as.logging.oeproxy—PAS for OpenEdge reverse-proxy web application service.

logging-tomcat.properties

Defines the properties used by the PAS for OpenEdge (tomcat) web server logging control file(s) for the log file name, roll over time, default logging level, and log entry data pattern for the following web server services in the logging-tomcat.xml Logback configuration file:

  • psc.as.logging.console—Core Tomcat Java process console logging.
  • psc.as.logging.catalina—Core Tomcat catalina web server logging.
  • psc.as.logging.localhost—Core Tomcat localhost web server service logging.
  • psc.as.logging.manager—Core Tomcat remote administration manager webapp logging.
  • psc.as.logging.hostmanager—Core Tomcat remote administration hostmanager webapp logging.
  • psc.as.logging.oehealth—OpenEdge oehealth web server scanner logging.
  • psc.as.logging.access—Core Tomcat client HTTP client request access logging.
    • These properties provide all options for the standard access log, which tracks requests and may require customization as needed to match business (auditing) requirements or for application usage trending. For reference, here the Enhanced MDC logging includes the token for output of the RequestID.

XML File Purposes

XML files that are customer editable for application troubleshooting:

  • ablapps/appname/conf/logging-ablapp.xml—Select Java subsystem logging for configuration issues.
  • logging-oests.xml—Select Java subsystem logging for configuration issues.

XML files that should be edited only by technical support, professional services, or OpenEdge engineering for server or service troubleshooting:

  • ablapps/appname/conf/logging-ablapp.xml—Select Java subsystem logging for OpenEdge or third-party code issues.
  • logging-oedbg.xml
  • logging-oeproxy.xml
  • logging-oests.xml
  • logging-security.xml
  • logging-soapdeploy.xml

XML configuration files that should be edited only by technical support, professional services, or OpenEdge engineering for Logback framework troubleshooting:

  • logging-access.xml
  • logging-oeabl.xml
  • logging-oehealth.xml
  • logging-oemanager.xml

Logging property update examples

Enable additional Spring Security logging for a PAS for OpenEdge instance for OERealm authentication

This distinct OpenEdge 12 example of how to turn on additional Spring Security logging for a PAS for OpenEdge instance for OERealm authentication involves modifying an XML configuration file to increase logging relating to this distinct security process.

  1. Add the following information to the logging-ablapp.xml file in the ablapps/appname/conf/ directory of the PAS for OpenEdge instance:
     <logger name="com.progress.appserv.services.security.OERealmUserDetailsImpl" level="TRACE"/>
 <logger name="com.progress.appserv.services.security.OERealmAuthProvider" level="TRACE"/>
  2. Restart the PAS for OpenEdge instance.

Edit the Tomcat logging pattern for web applications

As an example of how to alter the stock pattern for the Tomcat web application access log, this example restores a valuable piece of information omitted from the log entries under OpenEdge 12.

  1. Open the logging-tomcat.properties file in the conf directory of the PAS for OpenEdge instance.
  2. Locate the core Tomcat client HTTP access logging property pattern.
    psc.as.logging.access.pattern=%h %l %reqAttribute{OEReq.userId} [%date{"yyyy-MM-dd'T'HH:mm:ss.SSSXXX"}] "%r" %s %b %reqAttribute{OEReq.requestId} %n
  3. Alter the line to match the following:
    psc.as.logging.access.pattern=%h %l %reqAttribute{OEReq.userId} [%date{"yyyy-MM-dd'T'HH:mm:ss.SSSXXX"}] "%r" %s %b %D %reqAttribute{OEReq.requestId} %n

By adding the token %D after %b, the application outputs the [D]uration (in milliseconds) of the request.