Logging and Auditing Operations

Oracle Health Insurance applications support several levels of logging and auditing for gathering and assessing information about the runtime state of the system.

Types of Logs

Oracle Health Insurance applications support the following logs:

  • Application Log: the primary purpose of this log is to report runtime errors.

  • Security Log: contains information about creating user accounts, changes in privileges, and read-access to sensitive data.

  • Protected Health Information (PHI) log: after specifying the proper filter, Oracle Health Insurance application logs sensitive information like names, addresses, and web service payloads to a specific log that can be managed separately.

Configuration of an Appender

The following example shows the configuration of a Rolling File Appender that writes log statements to file:

<configuration>
    <appender name="fileAppender" class="ch.qos.logback.core.rolling.RollingFileAppender"> (1)
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> (2)
            <fileNamePattern>target/ohiApplication_%d{yyyy-MM-dd}.log</fileNamePattern> (3)
        </rollingPolicy>
        <encoder>
            <pattern>%d{ISO8601} [ %t ] %ohiLevel %c - %m%n</pattern> (4)
        </encoder>
        <filter class="com.oracle.healthinsurance.logging.logback.OhiSecurityLevelFilter"> (5)
            <inclusive>false</inclusive> (6)
        </filter>
        <filter class="com.oracle.healthinsurance.utils.logging.logback.OhiPHILevelFilter">
            <inclusive>false</inclusive>
        </filter>
    </appender>
    ...
</configuration>

Explanation of some key elements:

1 In log back, an Appender handles the logged messages. In most cases, writing log messages to a file or the console. The name attribute defines the name of this specific Appender. This is useful in referencing the appender. The class attribute defines the behaviour of the Appender. A RollingFileAppender writes log messages to a file that can rollover.
2 This defines when a RollingFileAppender rolls over to a new file (for example, trigger by time or file size) and the exact behaviour of the element (for example, renaming the previous log file using a pattern, moving the previous log file to a different directory). Class ch.qos.logback.core.rolling.TimeBasedRollingPolicy can create a new log file every day.
3 This defines the location and name of the log files. For a TimeBasedRollingPolicy, a valid %d conversion specifier is necessary. The java.text.SimpleDateFormat class specifies the date-and-time pattern that %d conversion specifier may contain. If there is no date-and-time pattern, then the system assumes the default yyyy-MM-dd pattern. The value of fileNamePattern defines the rollover period.
4 The encoder formats the log message. The pattern defines the format of the output of the log line.
5 The OhiSecurityLevelFilter and OhiPHILevelFilter filter security and PHI messages respectively.
6 Setting the value for the inclusive tag to false ensures that security or PHI messages are excluded for this appender that writes to the Oracle Health Insurance application log.

For more information on Logback configuration, see the Logback Website.

Security Audit Log

Oracle Health Insurance applications log specific, security-related log statements. Examples include:

 2010-06-11 21:01:24,077 [ [ACTIVE] ExecuteThread: '1' for queue:
'weblogic.kernel.Default (self-tuning)' ] SECURITY
com.oracle.healthinsurance.provisioning.service.impl.ProvisioningServiceImpl -
User 322 with loginName FN0023P0002 was created.
2010-06-11 21:01:24,398 [ [ACTIVE] ExecuteThread: '1' for queue:
'weblogic.kernel.Default (self-tuning)' ] SECURITY
com.oracle.healthinsurance.provisioning.service.impl.ProvisioningServiceImpl -
User 322 with loginName FN0023P0002 was modified.

For auditing purposes, the setup for the security log is likely to be different. For example, change the appender configuration to retain the security log for a longer time.

Specify filter class com.oracle.healthinsurance.logging.logback.OhiSecurityLevelFilter as mentioned in the following example to capture security-related log data in an Appender.

<appender name="securityAppender" class="ch.qos.logback.core.FileAppender">
    <file>target/ohiSecurity.log</file>
    <append>true</append>
    <encoder>
        <pattern>%d{ISO8601} [ %t ] %marker %c - %m%n</pattern>
    </encoder>
    <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
        <maxFileSize>100MB</maxFileSize>
    </triggeringPolicy>
    <filter class="com.oracle.healthinsurance.utils.logging.logback.OhiPHILevelFilter">
        <inclusive>false</inclusive>
    </filter>
    <filter class="com.oracle.healthinsurance.utils.logging.logback.OhiSecurityLevelFilter" />
</appender>

Protected Health Information (PHI) Log

Oracle Health Insurance applications log Protected Health Information or PHI in a separate log. PHI may include user-sensitive information like name, address, or DOB. This way, specific, more-secure management of Protected Health Information Logs is possible.

If the system is configured to log message payloads for HTTP API interactions, the PHI log contains the message payload for all integration points.

As demonstrated in the following example (in this case for writing to a file), apply filter com.oracle.healthinsurance.utils.logging.logback.OhiPHILevelFilter to capture PHI-related log data:

<appender name="phiAppender" class="ch.qos.logback.core.FileAppender">
    <file>target/ohiPhi.log</file>
    <append>true</append>
    <encoder>
        <pattern>%d{ISO8601} [ %t ] %marker %c - %m%n</pattern>
    </encoder>
    <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
        <maxFileSize>100MB</maxFileSize>
    </triggeringPolicy>
    <filter class="com.oracle.healthinsurance.utils.logging.logback.OhiSecurityLevelFilter">
        <inclusive>false</inclusive>
    </filter>
    <filter class="com.oracle.healthinsurance.utils.logging.logback.OhiPHILevelFilter"/>
</appender>

Prevent Protected Health Information from appearing in logs (files or otherwise) where it must not, by applying the OhiPHILevelFilter for every Appender. Use the following configuration for all loggers that must not log Protected Health Information:

<filter class="com.oracle.healthinsurance.utils.logging.logback.OhiPHILevelFilter">
    <inclusive>false</inclusive>
</filter>

Customize the Logback Configuration

A default logback.xml file comes with any Oracle Health Insurance application. Following are the steps for using a custom log back configuration:

  1. Create a custom logback.xml configuration file.

  2. Use the -Dlogback.configurationFile Java option to point to the custom configuration file. For example:

-Dlogback.configurationFile=/fully/qualified/path/to/custom_logback.xml

Logback Log Levels

Following are the log levels, in order of no logging to all logging:

  • error

  • warn

  • security (Oracle Health Insurance custom level)

  • phi (Oracle Health Insurance custom level)

  • info

  • debug

  • trace

Associating a Log Level With an Appender

The following configuration example shows how to specify the logging detail level for a specific Appender:

<root level="error">
    <appender-ref ref="fileAppender" />
</root>

Oracle recommends using a fileAppender for Oracle Health Insurance logging only. Do not log to the console as well, as this does not provide additional data (only the same data in multiple places). Also, note that additional logging impacts the performance of the system.

Configuring Specific Loggers

For diagnostic purposes Oracle may request to (temporarily) add loggers. The following example shows the addition of debug level loggers for a package and a specific class:

<configuration>
    <!-- OHI Application specific loggers -->
    <logger name="com.oracle.healthinsurance.integration" level="debug"/>
    <logger name="com.oracle.healthinsurance.restclient.internal.components.RestClientFactoryImpl" level="debug"/>

    <root level="error">
        <appender-ref ref="fileAppender"/>
    </root>
</configuration>
Make sure to remove these diagnostic loggers after capturing the logs.

Apply Logging Configuration Changes without Restarting Servers

Change logging parameters carefully. For example, more fine-grained logging or logging to multiple channels affects the performance of the system.

The following example shows how to configure Logback to periodically scan its configuration file for changes automatically and apply any changes to the logging configuration. With these settings, the system activates any changes made to the logback.xml configuration file after sixty seconds, without having to restart the system:

<configuration scan="true" scanPeriod="60 seconds">
 ...
</configuration>