Gateway 5 Logging Configuration

1 System Logging
2 Audit Logging

The logging.cfg file is a standard log4j configuration file. This section describes how to configure system and audit logging for the Gateway service. Additional information about log4j is available from the Apache Software Foundation's web site: logging.apache.org

Upgrading from 5.x

The configuration file for logging changed from logging.cfg (log4j) to logging.yaml (log4j2) to support Elasticsearch 5.6. Add customizations to the YAML file. See Gateway Configuration. (v6.0)

System Logging

The Gateway's system logs record operational details about the execution of the Gateway and are intended to be used by administrators and support personnel to monitor operations and debug issues.

The system logging is controlled by the root logger configuration. The example logging configuration file that is installed with Gateway sends output to the RollingFileAppender at the INFO level. The example file is also commented with guidance on changing the configuration.

# Global logging configuration
log4j.rootLogger=INFO, file

This example shows logging directly to the Gateway server's file system, rolling log files when they reach 100MB in size, and keeping 10 generations of rolled log files.

log4j.rootLogger=INFO, file
log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.file=/var/log/caringo/cloudgateway_server.log
log4j.appender.file.maxFileSize=100MB
log4j.appender.file.maxBackupIndex=10
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%d{ISO8601} %p [%t|%X{requestId}] %c{1}: %m%n
log4j.appender.file.threshold=DEBUG

This example shows sending logs to a centralized syslog server named "biglog.example.com" on the local4 facility.

log4j.rootLogger=INFO, syslog
log4j.appender.syslog=org.apache.log4j.net.SyslogAppender
log4j.appender.syslog.facility=local4
log4j.appender.syslog.syslogHost=biglog.example.com
log4j.appender.syslog.layout=org.apache.log4j.PatternLayout
log4j.appender.syslog.layout.ConversionPattern=%p [%t|%X{requestId}] %c{1}: %m
log4j.appender.syslog.threshold=DEBUG

The log4j has many advanced configuration options and administrators should refer to the Apache Software Foundation's documentation for more details.

The rsyslog service on some operating systems does not prefix messages with time stamps in the default configuration. You may either change the rsyslog configuration to include them or you may have Gateway include a high-resolution time stamp in the message body. Adding the field %d{ISO8601} in the conversion pattern tells Gateway to provide its own time stamp value. This is an example:

Audit Logging

The audit logging data feed records client requests to the storage system in a well-defined format that is suitable for automatic processing by billing and compliance applications. The definition of this format is documented in Gateway Audit Logging. The configuration of the audit logging is described herein.

The audit logging is configured within the logging.cfg file along with the system logging configuration. The audit logging uses the audit logger name to separate the messages from the system messages. The name audit for the logger cannot be changed. Audit messages are logged at INFO level and each message event type can be filtered separately. Setting the log4j filter threshold to WARN, ERROR, or FATAL disables output of that message event type.

This example shows sending the audit log messages directly to a file on the Gateway server, rolling the files when they reach 250MB, and keeping 30 generations of rolled files.

This example shows sending the logs to a centralized syslog server named "oversight.example.com" on the local3 facility.

For direct control of the message event types, change the filtering threshold to INFO to enable and FATAL to disable the type. This example shows all message event types set to INFO to enable them.

See Gateway Audit Logging for information about message event types and the format of the audit log messages.