An identity applications framework uses several components such as OSP, SSPR, Dashboard, User Application driver, and Role and Resource Service driver. Each component has its own logging configuration that defines the default log levels and appender configuration for that component. Logs for all identity applications components including OSP and Identity Reporting are logged to the catalina.out file while the Localhost log records the interactions between the Tomcat server and the client. Some components such as OSP maintain additional log files that help in auditing their individual interactions. This section discusses different log files that are generated in an identity applications environment and what each of them contains.
Catalina Log: This is the global log. It records information about events such as the startup and shutdown of the Tomcat application server, the deployment of new applications, or the failure of one or more subsystems. The messages include information about the time and date of the event and the ID of the user who initiated the event.
The catalina.log file contains all log messages that are written to Tomcat's system.out and system.err streams. Tomcat's internal log statements use the java.util.logging package (juli) to log. The default destination for that log is standard.out.
The catalina.out file can include:
Uncaught exceptions printed by java.lang.ThreadGroup.uncaughtException(..)
Thread dumps, if you requested them via a system signal
Each Tomcat server instance prints a subset of its messages to standard.out or idapps.out file. The idapps.out log file is specific to User Application. The userapp-log4j.xml file stores the logging configuration for User Application, which directs all log messages to idapps.out.
The catalina.out file is located on the computer that hosts the Tomcat server instance. Each server instance has its own catalina.out file. By default, the catalina.out file is located in the logs directory under Tomcat’s root directory. For example, /opt/netiq/idm/apps/tomcat/logs/catalina.out. To view messages in the catalina.out file, log in to the computer hosting Tomcat and use a standard text editor.
NetIQ recommends that you do not modify the log files by manually editing them. Modifying a file changes the timestamp and can confuse log file rotation. In addition, editing a file might lock it and prevent it from recording information from the Tomcat server.
Some operating systems enable you to redirect standard out to some other location. By default, a server instance prints only messages of Info severity level or higher to standard out. You can modify the severity threshold as a logging configuration so that the server prints more or fewer messages to respective log files.
Localhost Log : This is the log for all HTTP transactions between the client and the application server. The log file is named as, localhost_access_log.<date of log generation>.txt file. The default location and rotation policy for this log is the same as catalina.out file.
Application Log: Each identity application component is responsible for its own logging. Tomcat provides no support for application logs. Each component will have its own logging configuration where default log levels and appender configurations are defined. These logging configuration files are placed under \conf directory of Tomcat server.
The catalina.out log messages and log files communicate events and conditions that affect Tomcat server’s operations. Logs for all identity applications components including OSP and Identity Reporting are also logged to the catalina.out file. This file also records the interactions between the Tomcat server and the client.
Some subsystems and components also maintain additional log files that help in auditing their individual interactions. The following list describes some of the additional log files:
Logging information from the User Application is also logged into the idapps.out file. However, this file does not contain Tomcat server specific information.
OSP logs are additionally stored in a separate file, osp-idm-<date of log generation>.log file located in /opt/netiq/idm/apps/tomcat/logs/ directory. Logging is turned off by default and must be enabled in the setenv.sh file in the /TOMCAT_INSTALLED_HOME/bin/ directory.
Identity Reporting logs are additionally stored in /var/opt/netiq/idm/log/.
SSPR logs are stored in /opt/netiq/idm/apps/sspr/sspr_data/logs/SSPR.log.
The HTTP subsystem keeps a log of all HTTP transactions between the client and the application server in a text file, localhost_access_log.<date of log generation>.txt file. The default location and rotation policy for this log is the same as the catalina.out file. You can set the attributes that define the behavior of HTTP access logs for your server.
By default, logs for User Application driver and Role and Resource Service driver are added to DSTrace. The trace is turned off by default and must be enabled in the driver configuration by using Designer or iManager or console. When enabled, DSTrace displays messages related to operations that the driver performed or tried to perform, at the level of detail specified by the driver trace level, as the engine processes the events. The driver trace level affects only the driver or driver set where it is set. You can also specify to write the trace information for a driver to a separate file. For more information, see Viewing Identity Manager Processes in the NetIQ Identity Manager Driver Administration Guide.
Each server has a transaction log which stores information about committed transactions coordinated by the server that may not have been completed. Tomcat uses the transaction log when recovering from a system crash or a network failure. You cannot directly view the transaction log. The file is in a binary format.
The auditing service records information from a number of security requests, which are determined internally by the security framework. The service also records the event data associated with these security requests and the outcome of the requests. Each server writes auditing data to its own log file in the server directory.
The JDBC subsystem records various events related to JDBC connections, including registering JDBC drivers and SQL exceptions. The events related to JDBC are written to the server log, such as when connections are created or refreshed or when configuration changes are made to the JDBC objects.
The JMS logging is enabled by default when you create a JMS server. The identity applications use Apache ActiveMQ as a JMS provider. Logs can be found in the ActiveMQ installed path at data/activemq.log. The identity applications rely on a Java Message Service (JMS) persistent store to persist e-mail messages. If JMS is not properly configured, any e-mail messages in the memory queue will be lost if the application server is shut down.
The Hibernate framework writes log messages in different categories and log levels. For example, it logs messages for establishing connections with the database, executed SQL statements, or cache interactions. Hibernate logging is enabled by default at Info level. The events related to JDBC subsystem are written to the server log. All Hibernate related information is logged when the data is persisted in the application.