The /etc/caringo/cloudgateway/logging.yaml file is a standard log4j2 configuration file installed with a Content Gateway server.

Back up the Existing Configuration

Save copies of any prior configuration files when making changes using the copy command. Also, check for files like logging.yaml.rpmnew to be sure you are using the latest configuration we ship; yum does not replace modified configuration files.

• On the Content Gateway server:

  • /etc/caringo/cloudgateway/logging.yaml

System Logging

The Content Gateway server’s system logs record operational details about the execution of the Content Gateway and assist administrators and DataCore Support to monitor and troubleshoot issues.

Log Levels

Editing the logLevel property in the logging.yaml file changes the logging level in /var/log/caringo/cloudgateway_server.log (not the cloudgateway_audit.log file). There is no need to restart for the new level to take effect because the file is checked for changes every few seconds. The logLevel property is located at the top of the logging.yaml file for easy access as of Content Gateway v7.1.

These are the levels available:

• trace

• debug

• info (default)

• warn

• error

Rolling Files

The extract from the logging.yaml file shows logging directly to the Content Gateway server's file system, rolling log files when they reach 100 MB in size, and keeping 10 generations of rolled log files:

Timestamps in Filenames

The field %d{ISO8601} in the conversion pattern tells Content Gateway to provide its own timestamp value.

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 https://perifery.atlassian.net/wiki/spaces/public/pages/2443822661.

The audit logging is configured within the logging.yaml file, along with the system logging configuration. The audit log looks for the name: audit to separate messages from system messages. This must not be modified 

The extract from the logging.yaml file shows audit logging directly to the Content Gateway server's file system, rolling log files when they reach 100 MB in size, and keeping 10 generations of rolled log files:

Syslog Setup for SCS

By default, the Content Gateway server’s audit and server log messages are sent to a file local to each Content Gateway server, but they should also be sent to a centralized syslog server, such as the SCS server.

Perform the following modifications to send logs to a syslog server:

Enable Syslog

Perform the following modifications on each Content Gateway server’s /etc/caringo/cloudgateway/logging.yaml.

1. Set the “host” in both places (under audit_syslog and server_syslog) to the private side IP address of the SCS. This IP address needs to be on the same subnet as the storage nodes.

2. Uncomment the lines “ref: audit_syslog” and “ref: server_syslog”.

Verify the Syslog Entries

Check the places where it defines the syslog in logging.yaml.

1. Configure the IP addresses seen below with the private side IP address of the SCS. If unclear, type ip a on the SCS and look for the IP address that matches the same subnet as the storage nodes.

2. Nothing needs to be restarted or the logging changes to take effect.

3. Check in /var/log/datacore/ on the SCS server for entries in the Content Gateway server and audit logs.

Syslog Setup on Legacy CSN

The SCS, at least in recent versions, already includes the /etc/rsyslog.conf and /etc/logrotate.d/ configurations to accept Content Gateway audits and server logs. The legacy CSN does not have that by default. These instructions can also be used if using a custom syslog server. Always backup configuration files before modifying them.

Configure Syslog

Configure the Syslog server with the location to write these log files.

1. Navigate to the CSN's /etc/rsyslog.conf and add these two lines in the local* section at the bottom of the file:

2. Add the following line above /var/log/messages in the /etc/rsyslog.conf file to avoid duplicating incoming messages from Gateway and Elasticsearch logs to the /var/log/messages file.

   The result resembles:

3. Save the file and restart rsyslog: service rsyslog restart.

Enable Rotation

Create these two rotation files and add them to /etc/logrotate.d/. Be sure logrotate is run hourly (/etc/cron.hourly/logrotate), not daily.

caringo-content-gateway-server

caringo-content-gateway-audit

Update Existing Log Rotation

caringo-castor

Also, ensure that you have a dateformat line in /etc/logrotate.d/caringo-castor as in the above files. The default log file format when compressed will only allow you to logrotate once per day, so quickly rolling logs won’t rotate hourly as expected/ desired. You may also update the rotate line so that the CSN keeps more than 8 files- a good number might be 30 (as shown below) presuming there is enough space in /var/log. The resulting /etc/logrotate.d/caringo-castor file should look like this:

Enable Syslog

Perform the following modifications on each Content Gateway server’s /etc/caringo/cloudgateway/logging.yaml.

1. Set the “host” in both places (under audit_syslog and server_syslog) to the private side IP address- the bond0 interface- of the CSN. The bond0 interface should end in .5. This IP address needs to be on the same subnet as the storage nodes.

2. Uncomment the lines “ref: audit_syslog” and “ref: server_syslog”.

Verify the Syslog Entries

Check the places where it defines the syslog in logging.yaml.

1. Configure the IP addresses seen below with the bond0 IP address of the CSN. If unclear, type ifconfig bond0 on the CSN.

2. Nothing needs to be restarted or the logging changes to take effect.

3. Check in /var/log/caringo/ on the CSN for entries for the Content Gateway server and audit logs.