In this section:
Overview
Use the Event Log object to create, configure, disable and enable system and subsystem level log files to capture system, security, debug, packet, trace and accounting events. The SBC 7.2.x release supports FIPS-140-2 and the 10.1.3 release supports FIPS-140-3. FIPS-140-2 is not supported in 10.1.3 and later releases and gets automatically converted to FIPS-140-3 as part of the upgrade. To verify the current status of FIPS certification, contact the Global Support Assistance Center: For each event type, an event class (subsystem) and severity threshold can be configured. Event classes include: The ROLLFILE facility provides a means of closing the active log file and opening a new one with an incremented (name) suffix. This facilitates real-time analysis of system events by performing the analysis on closed, rather than opened and growing, files.
The Event Log object allows you to create event log filters to capture debug, security, system, trace, and accounting events using following parameters:
- Filter Admin – Filter configuration for each event log type and event class
- Filter Status – View filter status per each event log type and event class (using the request command)
- INFO Level Logging Enable – Re-enable INFO level logging if it becomes disabled due to system congestion
- Memory Usage – Measure memory usage of each process
- Platform Audit Logs – View platform audit logs of administrative, privileged, and security actions
- Platform Rsyslog – Method of sending event messages to a syslog server.
- Subsystem Admin – Filter configuration for each subsystem
- Type Admin – Event log for configuration items related to each event log type
For security protection, the Netconf interface does not support "/aaa" records.
Filter Admin
If using INFO filter level is needed for troubleshooting, the SBC triggers the alarm sonusCpEventLogFileDebugLevelInfoNotification any time the Debug Event Log filter level is set to INFO as a reminder of potential memory congestion due to the accumulation of a large number of Debug Event logs in memory. The alarm includes a warning message to set the filter level to MAJOR. The alarm is enabled or disabled using both CLI and EMA When the filter level is set to Once the troubleshooting is completed, set the filter level to When the filter level is changed, the clear alarm
The SBC records the maximum number of Debug Event logs, which can potentially cause memory to become congested resulting in unexpected or undesirable SBC performance.INFO
, the following events occur: sonusCpEventLogFileDebugLevelInfoNotification
every five minutes.Debug Event Log filter level is set to INFO. Set to MAJOR if finished troubleshooting
on the last modified Debug Event Log file.MAJOR
. The alarms are cleared when the filter level is set to MAJOR
.sonusCpEventLogFileDebugLevelInfoClearNotification
is triggered and a message Debug Event Log filter level is no longer set to INFO
is displayed in the log file.
Command Syntax
% set oam eventLog filterAdmin <node name> <event_type: audit | debug | memusage | security | system | trace> <event_class: audit | callproc | directory | netmgmt | policy | resmgmt | routing | security | signaling | sysmgmt | trace> level <info | major | minor | noevents> state <off | on>
Command Parameters
Filter Status
Command Syntax
% request oam eventLog filterStatus <node name> <event_type: audit | debug | memusage | security | system | trace> <event_class: audit | callproc | directory | netmgmt | policy | resmgmt | routing | security | signaling | sysmgmt | trace> resetStats
Command Parameters
INFO Level Logging Enable
The active and standby SBC are designed to turn off INFO level logging if the system becomes congested. The "request oam eventLog infoLevelLoggingEnable clearInfoLevelLoggingDisabled
" command is used to re-enable INFO level logging once it is disabled. See sonusCpEventLogInfoLevelLoggingDisabledNotfication - MAJOR for associated trap details.
To view INFO LEVEL LOGGING DISABLED state, run the following command.
> show table oam eventLog typeStatus INFO TOTAL LEVEL CURRENT FILE FILE TOTAL FILE FILES NEXT LOG LOGGING TYPE FILE RECORDS BYTES FILES BYTES DROPPED ROLLOVER DESTINATION LAST FILE DROP DISABLED ------------------------------------------------------------------------------------------------------------------------------ system 1000005.SYS 216 31756 32 1032744 0 0 localDisk 0000-00-00T00:00:00+00:00 false debug 1000014.DBG 1601 188964 32 27489838 0 0 localDisk 0000-00-00T00:00:00+00:00 false trace 1000005.TRC 0 128 32 5224 0 0 localDisk 0000-00-00T00:00:00+00:00 false acct 1000085.ACT 1 202 32 7592 0 0 localDisk 0000-00-00T00:00:00+00:00 false security 1000005.SEC 7 1047 32 23610 0 0 localDisk 0000-00-00T00:00:00+00:00 false audit 1000005.AUD 1002 186238 32 4267027 0 0 localDisk 0000-00-00T00:00:00+00:00 false packet 1000005.PKT 0 128 32 872 0 0 localDisk 0000-00-00T00:00:00+00:00 false
Command Syntax
% request oam eventLog infoLevelLoggingEnable clearInfoLevelLoggingDisabled
Command Parameter
Memory Usage
The SBC Core uses the OAM Event Log memusage command to log the memory usage of each process over a configurable interval. The SBC generates a memory log which is uses to capture and log process heap memory usage over time. The following limitations apply in this release: The number of bytes used by an active process are captured in the memory usage log file: Processes are identified by the log entries encoded by the system. For example, the format of a log entry: The memory usage details are logged to the hard drive in the directory: Use the log number to locate the correct log file. For example: where the 113 03282017 073341.007995:1.01.00.00006.MAJOR .PRS: memusage: 1516445696
/var/log/sonus/sbx/evlog
/var/log/sonus/sbx/evlog/<log number>.mem
<log number>.mem
is the memory usage log file.
Command Syntax
% set oam eventLog process memusage state <enable | disable> level <summary | detailed> interval <0...140>
Command Parameters
Platform Audit Logs
Command Syntax
% set oam eventLog platformAuditLogs state <disabled | enabled>
Command Parameters
Platform Rsyslog
Use Rsyslog to configure a remote server IP address, port, and protocol type to push platform logs of administrative, privileged, and security actions to a remote server.
When platformRsyslog
is enabled, the /etc/
rsyslog.conf
file is configured to send the configured platform logs to the remote syslog server. The remote server's /etc/rsyslog.conf
file must match the configuration of the SBC to receive platform logs. The SBC automatically adds an Access Control List (ACL) rule to send the audit logs through the application layer to the remote server.
The following logs will not be supported: Monit, Mail, Printer, dpkg and the /var/log/messages file.
platformRsyslog
is disabled.For a High Availability (HA) pair, the
file is updated both on the Active and the Standby SBCs to push the audit logs to the remote server./etc/
rsyslog.conf
Command Syntax
To create a new Server configuration table:
set oam eventLog platformRsyslog servers server<no> remoteHost<host_ip> protocolType<protocol> port <port>
Command Parameters
Ensure the Platform Rsyslog state
is set to "disabled" before configuring/re-configuring the IP address, port, and/or protocol type of the remote server.
Command Syntax
To enable/disable the Rsyslog service for all the Linux Logs:
set oam eventLog platformRsyslog syslogState <disabled | enabled>
Command Parameters
Subsystem Admin
Command Syntax
Mandatory parameters required to configure an Event log subsystem event type:
% set oam eventLog subsystemAdmin <system_name> <subsys_ID>
Non-mandatory parameters to configure an Event log subsystem event type:
% set oam eventLog subsystemAdmin <system_name> <subsys_ID> infoLogState <disabled | enabled> maxEventID <0-4.294967295E9> minEventID <0-4.294967295E9>
Command Parameters
Type Admin
The syslog
ACL rules are added and removed by enabling/disabling syslogState
and configuring the syslog
log fields.
To guard against overlogging, the SBC logs up to 4,294,976,295 messages per second in the event logs (configurable with set oam eventLog typeAdmin system diskThrottleLimit
), but additional event messages above that threshold are discarded. If log events must be discarded, the SBC writes an error message about the skipped messages in the system (.SYS) log.
Command Syntax
The following syntax applies to the set oam eventLog typeAdmin command:
% set oam eventLog typeAdmin <acct | audit | debug | memusage | packet | security | system | trace> compressionSupport <both | none | only> compressionDaysToKeep <1 .. 7> compressionCleanupDirectory <directory name> diskThrottleLimit <0-4294976295> eventLogValidation fileCount <1-2048> fileSize <256-65535> fileWriteMode <default | optimize> filterLevel <info> messageQueueSize <2-100> renameOpenFiles <disabled | enabled> rolloverAction <start | stop> rolloverInterval <0-31536000> rolloverStartTime <time> rolloverType <repetitive | nonrepetitive> saveTo <none | disk> servers <syslogRemoteHost | syslogRemotePort | syslogRemoteProtocol> syslogState <disabled | enabled>
Only the Administrator can execute the above command using the audit
and security
attributes:
% set oam eventLog typeAdmin audit...
% set oam eventLog typeAdmin security...
The following syntax applies to the request oam eventLog typeAdmin
command:
% request oam eventLog typeAdmin <acct | audit | debug | memusage | packet | security | system | trace> rolloverLogNow % request oam filterStatus <card name> <audit | debug | memusage | security | system | trace> <audit | callproc | directory | netmgmt | policy | resmgmt | routing | security | signaling | sysmgmt | trace
Only the Administrator can execute the following commands using the "audit" and "security" attributes:
% request oam eventLog typeAdmin audit rolloverLogNow % request oam eventLog typeAdmin security rolloverLogNow % request oam eventLog filterStatus <card name> security security resetStats
The System log displays Info level logs which are traps or faults when the System log filterLevel is configured to log Major and/or Critical events.
Command Parameters
For Hardware and SWe-Based Systems
- The compressed files are named using the following convention:
<System Name>_<timestamp>_xxxxxxx.ACT.gz
...where System Name
is the name of the Redundancy group. Example: SBX30_1571352583_1000018.ACT.gz
- The number of files created and maintained concurrently is unlimited, and is not constrained by the
fileCount
configured for the accounting log.
For N:1 Cloud-Based Systems
- The compressed files are named using the following convention:
< Hostname i.e. VM Name >_<timestamp>_xxxxxxx.ACT.gz
You cannot use the system name because, in an N:1 system, multiple instances running in active mode would have the same system name.
The SBC uses the actualCeName
as the Hostname
because this is the name specified in the user metadata. Example: vsbc1Site1_1571352902_1000003.ACT.gz
- The number of files created and maintained concurrently is unlimited, and is not constrained by the
fileCount
configured for the accounting log.
For 1:1 Cloud-Based Systems
- The compressed files are named using the following convention:
<System Name>_<timestamp>_xxxxxxx.ACT.gz
...where System Name is the actualSystemName
, as this is the name specified in the user metadata. Example: vsbcSystem22_1571348519_1000001.ACT.gz
- The number of files created and maintained concurrently is unlimited, and is not constrained by the
fileCount
configured for the accounting log.