Additional logging properties

This section describes several advanced logging configuration options supported by Access Decision Service (ADS), defined within the deployment.yaml file.

Separate event types in the audit log output

The audit logs produced by ADS contain two types of events:

• evaluation events - data regarding access requests and their responses

• administrative events - data regarding runtime changes to the configuration of ADS

The log output can be sent to a file, the console, or both. Additionally, you can control whether the output contains:

• evaluation events only
• administrative events only
• both types combined
• both types but on separate output items

note

For general information about logging properties, refer to the logging sectionOpens in a new tab of the Dropwizard documentation.

Select which log types display in the log output, by declaring the appropriate logger after the loggers property, under the logging section and then configuring the nested logger properties as shown in the examples below.

Logger	Log types
com.axiomatics.audit.ads.eval	Only evaluation events
com.axiomatics.audit.ads.admin	Only administrative events
com.axiomatics.audit	Both evaluation and administrative events

Additionally, you can determine the log output destination using the additive property. Setting it to true enables output to both the console and a specified file while setting it to false directs logs only to the file.

Important

Changing loggers also requires updating the currentLogFilename and archivedLogFilenamePattern values to ensure compatibility and avoid data overwrites.

Simple example

In the following example the evaluation events are output in a file named ads-eval-event.log and the console. To achieve this, the "com.axiomatics.audit.ads.eval" logger is used and the additive property is set to true.

logging:
level: WARN
loggers:
"com.axiomatics.audit.ads.eval":
level: INFO
additive: true
appenders:
    - type: file
      layout:
        type: json
      threshold: INFO
      currentLogFilename: ./logs/ads-eval-event.log
      archivedLogFilenamePattern: ./logs/ads-eval-event-%d{yyyy-MM-dd}-%i.log.gz
      archivedFileCount: 7
      timeZone: system
      maxFileSize: 10MB

Advanced example

In the following example the log data are separated into two separate output files, one for each type of event.

The com.axiomatics.audit.ads.eval and com.axiomatics.audit.ads.admin loggers are used and the output files are named ads-eval-event.log and ads-admin-event.log respectively. Additionally, for the latter, the output destination is limited to the file only by setting the additive property to false.

logging:
  level: WARN
  loggers:
    "com.axiomatics.audit.ads.eval":
      level: INFO
      additive: true
      appenders:
        - type: file
          layout:
            type: json
          threshold: INFO
          currentLogFilename: ./logs/ads-eval-event.log
          archivedLogFilenamePattern: ./logs/ads-eval-event-%d{yyyy-MM-dd}-%i.log.gz
          archivedFileCount: 7
          timeZone: system
          maxFileSize: 10MB
          
    "com.axiomatics.audit.ads.admin":
      level: INFO
      additive: false
      appenders:
        - type: file
          layout:
            type: json
          threshold: INFO
          currentLogFilename: ./logs/ads-admin-event.log
          archivedLogFilenamePattern: ./logs/ads-admin-event-%d{yyyy-MM-dd}-%i.log.gz
          archivedFileCount: 7
          timeZone: system
          maxFileSize: 10MB

Configure single-line per event log output

Certain log events in ADS can produce messages that span across multiple lines. Should this pose an issue—such as when employing a log analysis tool that requires single-line log messages—you have the option to adjust the logging settings to adopt a JSON format. This ensures that each event is recorded in a singular line per event, enhancing compatibility and ease of analysis.

logging:
  level: WARN
  loggers:
    "com.axiomatics.audit":
      level: INFO
      additive: false
      appenders:
        - type: file
          layout:
            type: json
          threshold: INFO
          currentLogFilename: ./logs/ads-audit-event.log
          archivedLogFilenamePattern: ./logs/ads-audit-event-%d{yyyy-MM-dd}-%i.log.gz
          archivedFileCount: 7
          timeZone: system
          maxFileSize: 10MB
  appenders:
  - type: console
    target: stdout
    timeZone: system
    # Uncomment the following lines to enable JSON layout as the default.
    # layout:
    #   type: json
    #   prettyPrint: true

JSON layout enabled for audit logging

In this example, the JSON layout is enabled solely for audit logs, which are directed to a separate log file. All other log events are sent to standard output. To enable JSON layout for all logs, uncomment the section as described.

Enable verbose audit logging

By default, the log output for evaluation events is presented in a concise format. That means, information not essential to auditing is excluded from the evaluation events. If you want to enable full, or verbose, logging information you need to add the audit property in the deployment.yaml configuration file and set its nested property mode to verbose.

In the example below the verbose audit logging is enabled:

audit:
  mode: verbose
 
logging:
  level: WARN
  loggers:
    "com.axiomatics.audit": INFO
  appenders:
    - type: console
      target: stdout
      timeZone: system

Verbose logging output enabled

info

The nested property mode can have two values, concise and verbose, with concise being the default value.

See the section Audit log message format for output examples and more information about the logging output format.

Enhance logging with tracing information in MDC

Log entries from ADS can be enhanced with trace and span identifiers by including these as attributes within the Mapped Diagnostic Context (MDC). This enhancement, however, is dependent on the activation of the OpenTelemetry Java agent, which ADS utilizes for tracing capabilities. For more information, refer to the Tracing for more information.

Once enabled, the OpenTelemetry Java agent integrates trace and span information into the MDC for each log event. For more details on the types of information injected into the MDC, refer to theOpenTelemetry MDC documentationOpens in a new tab.

Within the JSON logging format, MDC values are included by default. To exclude these values, add the property includes: to the JSON layout section of the deployment.yaml configuration file and exclude mdc from the list of logging event attributes, as shown in the sample below:

layout:
  type: json
  timestampFormat: "yyyy-MM-dd'T'HH:mm:ss.SSSZ"
  prettyPrint: false
  appendLineSeparator: true
  includes: [timestamp, threadName, level, loggerName, message, exception]

MDC excluded from log output (excerpt)

This will prevent the MDC value from being printed in the log output.

To include it again, add mdc back to the list of logging event attributes:

layout:
  type: json
  timestampFormat: "yyyy-MM-dd'T'HH:mm:ss.SSSZ"
  prettyPrint: false
  appendLineSeparator: true
  includes: [timestamp, threadName, level, loggerName, message, mdc, exception]

MDC included in log output (excerpt)

Refer to the Dropwizard documentation for JSON layoutOpens in a new tab for more information.