Skip to main content

Logging Configuration

Logging for the IQ Server is managed through settings in the config.yml file. The config YAML specifies the log directory to store for each of the log files.

See Config YAML for details.

Logging Level Considerations

The recommended logging level for a production deployment is DEBUG. This is the default logging level for Lifecycle and it provides the most comprehensive logging information, which can be crucial for diagnosing issues.

Note that setting the logging level to DEBUG may cause the log file clm-server.log to grow very large. However, this level of detail is often necessary for support purposes.

Logging Rotation

Log files are configured to rotate in 50 days' worth of gzipped dated archives. The location of the log files may be specified to store them in a separate archive.

Application Log

The application log is found at ./log/clm-server.log and archived logs are compressed with the name pattern of clm-server-yyyy-MM-dd.log.gz.

IQ Server uses Dropwizard 1.3.x logging configuration

Audit Log

In the audit log, each entry is a JSON object. This allows for line-by-line parsing by external tools for inspection, analysis, and extraction of desired data.

Audit logging only occurs at the INFO level. Thus setting an audit logger level to ALL, TRACE, or DEBUG has no effect, and setting it to WARN, ERROR or OFF will disable it.

Audit events are not appended to the application log. The last active audit log is found at ./log/audit.log and archived audit logs are compressed with the name pattern of audit-yyyy-MM-dd.log.gz. Audit logging can be customized in the logging section of your config.yml file beneath the base audit logger com.sonatype.insight.audit .

Policy Violation Log

Policy violation logging is similar to the audit log, each line or entry is a JSON object. This allows for easy line-by-line parsing by external tools for inspection, analysis, and extraction of desired data.

By default, policy violation logging is disabled. It can be enabled and customized in the logging section of your config.yml file beneath the policy violation logger com.sonatype.insight.policy.violation. Policy violation events are logged independently and are not appended to the application log.

Note

Policy violation logging only occurs at the INFO level. Thus setting the policy violation logger level to ALL, TRACE, or DEBUG has no effect, and setting it to WARN, ERROR or OFF will disable it.

Using the following suggested configuration

Suggested policy violation logger configuration

logging:
  loggers:
    "com.sonatype.insight.policy.violation":
      appenders:
        - type: file
          # The file to which policy violations will be logged.
          currentLogFilename: ./log/policy-violation.log
          # When the policy violation log file rotates, the archived policy violation log will be renamed to this
          # and gzipped. The %d is replaced with the previous day (yyyy-MM-dd). Custom rolling windows can be created
          # by passing a SimpleDateFormat-compatible format as an argument: "%d{yyyy-MM-dd-hh}".
          #
          # If archive is true, this must be specified.
          archivedLogFilenamePattern: ./log/policy-violation-%d.log.gz
          # The number of archived policy violation log files to keep.
          archivedFileCount: 50

The last active policy violation log is found at ./log/policy-violation.log and archived policy violation logs are compressed with the name pattern of policy-violation-yyyy-MM-dd.log.gz.

Request Log

The last active request log is found at ./log/request.log and archived logs are compressed with the name pattern of request-yyyy-MM-dd.log.gz. The request log can be customized in the requestLog section of the config.yml file.

IQ Server uses Dropwizard 1.3.x requestLog configuration

Request Log Line Formats

As of IQ Server 1.43, the request log line format is configurable using patterns defined by the Logback Access PatternLayout class.

The Sonatype preferred format renders timestamps with the same timezone as the application log to ease comprehension during comparison.

Preferred request.log line format

logFormat: "%clientHost %l %user [%date] \"%requestURL\" %statusCode %bytesSent %elapsedTime \"%header{User-Agent}\""

Concise config.yml example of specifying request.log line format

server:
  requestLog:
     appenders:
       - type: file
         logFormat: "%clientHost %l %user [%date] \"%requestURL\" %statusCode %bytesSent %elapsedTime \"%header{User-Agent}\""
         currentLogFilename: ./log/request.log
         archivedLogFilenamePattern: ./log/request-%d.log.gz
         archivedFileCount: 50

Default request.log line format if unspecified

logFormat: "%clientHost %l %user [%date] \"%requestURL\" %statusCode %bytesSent %elapsedTime \"%header{User-Agent}\""

Example: Inspecting Reverse Proxy Authentication Headers

Reverse Proxy Authentication requires a header to be sent to the server that specifies a user ID.

Verify that the configured usernameHeader name is being sent with the correct value with every inbound request by including the configured header name in the logFormat value:

Example logFormat value printing the configured usernameHeader value

logFormat: "%clientHost %l %user [%date] \"%requestURL\" %statusCode %bytesSent %elapsedTime \"%header{User-Agent}\" %header{REMOTE_USER}"

Example: Inspecting Reverse Proxy HTTPS Headers

When fronted by a reverse proxy terminating TLS connections, reverse proxies must send special x-forwarded header(s) to IQ Server for requests to work properly.

Verify that related x-forwarded headers are being sent with the expected values by editing the logFormat pattern value:

Example logFormat value printing x-forwarded headers

logFormat: "%clientHost %l %user [%date] \"%requestURL\" %statusCode %bytesSent %elapsedTime \"%header{User-Agent}\" %header{host} %header{x-forwarded} %header{x-forwarded-host} %header{x-forwarded-proto}"