Server logs configuration

User configuration of the security logging system is defined in the following file /etc/saymon/logger.json

Log parameters

The following is the example of logging configuration for SAYMON server.

{
  // Log categories
  "categories": {
    "Default": "Info"
  },
  // Log channels
  "channels": {
    // The 'default' channel is meant for messages, that don't fit other channels (Public channel)
    "default": [
      {
        "type": "console",
        "options": {
          "level": "debug",
          "stderrLevels": [
            "error"
          ],
          "colorize": false,
          "prettyPrint": true
        }
      }
    ],
    // The 'session' channel is meant for user session messages (Private channel)
    "session": [
      // Example 1: Send logs to UDP server
      // {
      //   type: 'udp',
      //   options: {
      //     server: 'localhost:514'
      //   }
      // },
      //
      // Example 2: send logs to a Kafka server
      // {
      //   type: 'kafka',
      //   options: {
      //     server: 'localhost:9092',
      //     topic: 'LOG_SESSION'
      //   }
      // }
    ],
    // The 'audit' channel is meant for user audit messages (Private channel)
    "audit": [],
    // The 'faults' channel is meant for security messages (Private channel)
    "faults": []
  }
}

categories

{
  "categories": {
    "Default": "Info",
    "MyActor": "Error",
    "MyOtherActor": "Debug"
  }
  ...
}
Section/Parameter Description

categories.<category-name>

Minimal log level for this category.

There is a special logging category, "Default", that defines the default log level.

Possible log levels:

  • "Silent",

  • "Info",

  • "Warn",

  • "Error",

  • "Debug"

channels

This section allows you to define log channel settings.

SAYMON logging separates all messages into channels. Each log channel represents a specific way of handling logs.

Security events can be sent to different channels. Each channel can contain multiple transport modules (mechanisms of log delivery to the appropriate storage system, for example udp or kafka) to deliver messages to multiple systems at the same time.

For example, error messages can be sent to the "faults" channel, that will send print them to the console and send them to an external system (for example, to the syslog server).

{
  "channels": {
    "faults": [
      {
        "type": "console",
        "options": {
          "level": "debug"
        }
      },
      {
        "type": "udp",
        "options": {
          "server": "localhost:514"
        }
      }
    ]
  }
}

System has 4 thematic channels defined:

  • session - information about opening/closing a user session,

  • audit - information about changes to the system,

  • faults - information about errors while accessing the system,

  • default – channel for messages that don’t fit other channels

By default, the system has a single channel default. This channel prints messages to the server’s console.

All messages sent to an undefined channel will be ignored.

You can define multiple transport modules for each channel for simultaneous delivery in multiple log storage systems.

channels {
    ...
    "session": [
      //Send logs to the server via UDP
      {
        "type": "udp",
        "options": {
          "server": "localhost:514"
        }
      },

      // Send logs to Kafka
      {
        "type": "kafka",
        "options": {
          "server": "localhost:9092",
          "topic": "LOG_SESSION"
        }
      }
    ],
    ...
}
By default, the system has a default channel. You don’t need to specify its settings in the configuration file, unless you want to override its default behavior (sending events to the console).
Section/Parameter Description

channels.<channel-name>.type

Transport module type. Possible types:

channels.<channel-name>.options

Transport module configuration. Depends on its type.

common

"common": {
  "resolveRemoteIp": true
},
Section/Parameter Description

common.resolveRemoteIp

If this parameter is set to true, the system will use DNS to automatically detect the client name and include it in the Security log.

Enabling this parameter can affect performance of the logging system, so it should only be enabled in special cases. By default this functionality is disabled.

udp

Section/Parameter Description

options.server

UDP server address .

System accepts the following address formats:

  • <ip-address|hostname>:<port>

  • <ip-address|hostname>

  • <port>

kafka

Section/Parameter Description

options.server

Kafka server address.

System accepts the following address formats:

  • <ip-address|hostname>:<port>

  • <ip-address|hostname>

  • <port>

options.topic

Kafka topic, where the events are sent.

console

Section/Parameter Description

options.level

Minimal log level that is shown in the console output. By default – 'debug'

options.stderrLevels

List of log levels that need to output in stderr, and not in stdout. For example ['error', 'debug', 'info']. By default, the list is empty.

options.colorize

Colorize log levels in the output. By default – false.

options.prettyPrint

Format the console output. By default – true.

Log rotation parameters

SAYMON server performs log rotation with logrotate.

You can configure log rotation of the SAYMON server in the /etc/logrotate.d/saymon file.

logrotate configuration file has the following structure:

<path to log path> {
    configuration parameters
}

The following is the default logrotate configuration for the SAYMON server and MongoDB.

  • SAYMON logs

  • MongoDB logs

/var/log/saymon/*.log {
    daily
    missingok
    rotate 14
    compress
    delaycompress
    notifempty
    copytruncate
}
/var/log/mongodb/*.log {
    daily
    rotate 30
    compress
    dateext
    missingok
    notifempty
    sharedscripts
    copytruncate
}

The following table contains a reference for the used logrotate parameters:

Parameter Description

daily

Perform log rotation daily.

missingok

Continue log rotation without throwing an error if one of the log files is missing.

rotate N

Number of days to store logs for.

compress

Compress files as .gzip archives.

delaycompress

Don’t archive the latest log until the next rotation cycle.

notifempty

Don’t rotate logs if they are empty.

copytruncate

Use the same file for logs, truncating it after rotation.

sharedscripts

Execute prescript and postscript scripts only once per log rotation and not for every log.