Writing admin log entries to a file

Configure an integration node or server to write admin log entries to a file, by setting properties in the node.conf.yaml or server.conf.yaml configuration file.

Before you begin

Read the following topics:

About this task

In addition to displaying admin log entries in the web user interface, you can configure the integration node or integration server to write the contents of the admin log to a file.

For independent integration servers, the admin log files are created in the adminLog subdirectory of the integration server's working directory:
workDir/adminLog
For integration nodes and their managed integration servers, the admin log files are created in the common/adminLog directory (workDir/common/adminLog), with a subdirectory for each integration node and integration server:
workDir/common/adminLog/integrationNodeName/integrationServerName

For integration nodes that were created with a shared work path, the admin logs are created in the shared work path to ensure that they are accessible to both nodes in a multi-instance configuration.

Procedure

Configure an integration node or server to write a log of admin events to a file, by modifying the node.conf.yaml or server.conf.yaml configuration file for the integration node or server:

  1. Open the appropriate node.conf.yaml or server.conf.yaml configuration file by using a YAML editor.

    You can edit the file by using the built-in YAML editor that is provided in the IBM® App Connect Enterprise Toolkit, either by double-clicking the file in the Application Development view or by right-clicking the file and selecting Open with > YAML editor. If you choose to edit the file by using a plain text editor, ensure that you do not include any tab characters (which are not valid in YAML) and use a YAML validation tool to validate the contents of your file.

  2. Set the following properties in the AdminLog section of the appropriate node.conf.yaml or server.conf.yaml file:
    1. Enable the contents of the admin log to be written to a file, by setting the fileLog property to true. By default, this property is set to false.
    2. Specify the number of days for which the log files are to be stored in the file system before being deleted, by setting the fileLogRetentionPeriod property.
    3. Specify the number of files that are to be stored each day, by setting the fileLogCountDaily property.
    4. Specify the maximum file log size to be stored each day, by setting the fileLogSize property. By default, if file logging is enabled, each daily log file is stored for 30 days before it is deleted, and for each of those 30 days, up to 10 files are stored, up to a maximum of 100MB each per day.
      For example:
      
      AdminLog:
        enabled: true               # Control logging admin log messages. Set to true or false, default is true.
        # When enabled the maximum amount of disk space required for admin log files is
        # fileLogRetentionPeriod * fileLogCountDaily * fileLogSize
        fileLog: false              # Control writing admin log messages to file. Set to true or false, default is false.
        fileLogRetentionPeriod: 30  # Sets the number of days to record admin log.
                                    # After this, old files are deleted as new ones are created. Default is 30 days.
        fileLogCountDaily: 10       # Maximum number of admin log files to write per day, default is 10 per day.
        fileLogSize: 100            # Maximum size in MB for each admin log file. Maximum size is 2000MB, default size is 100MB.
        consoleLog: false           # Control writing admin log messages to standard out. Set to true or false, default is false.
        consoleLogFormat: 'idText'    # Control the format of admin log messages written to standard out. Set to idText, text, or ibmjson. Default is idText.

      At the end of the specified retention period, the next log file to be created causes any log files older than the retention period to be deleted. When the maximum number of daily files is exceeded, the oldest file on that day is deleted, and the remaining files are renamed.

  3. Restart the integration node or integration server for the changes to take effect. Changes to the server.conf.yaml and node.conf.yaml files take effect only when the modified integration node or server is restarted.