In this section:
The DSC Platforms support logging to hard drives (/var/log) on the RTNG_MGMT_CPUs (VM1 and VM2).
For example, if a log is created in the log file that resides in VM1 in slot 1, then this log appears in the log file with the hostname <user configured>slot1. If you view this log on the RTNG_MGMT_CPU in VM2, then the hostname appears in the log file with the hostname slot2.
The SP2000 supports logging to IDE hard drives (/var/log) on the AMC590.
For the SP2000, logs are simultaneously directed to both Management CPU cards, and, therefore, are identical, with the exception of the hostname values. For example, if a log is created in the log file that resides in Management CPU in slot 14, then this log appears in the log file with the hostname <user configured>slot14. If you view this log on the Management CPU in slot 24, then the hostname appears in the log file with the hostname slot24.
You can use the Web UI to
Debug logging is useful for troubleshooting purposes, but excessive logging can cause communication delays and is not recommended for normal operations.
This section describes alarm and event log handling for the DSC - SP2000 Platform.
The DSC - SP2000 Platform supports the following alarm and event logs:
SNAMI log (gr310audit). This log captures every single incoming GR310 command and single GR310 response transmitted from the DSC 8000.
For more information about the Signaling Network Activation Manager Interface (SNAMI), see the appropriate section in the SS7 Application Guide 2.
The DSC - SP2000 Platform forwards all logs to the /var/log directory on the hard drives (referred to as hard drives) of the Management and Routing VMs.
The reserved disk space for logging depends on the given DSC - SP2000 Platform.
In order to avoid filling the reserved disk space, a maintenance script is evoked daily at 12:00 A.M. and the log files are moved to the /var/log/archives directory. This log rotation is required to separate logs daily and, therefore, minimize the log file size on the hard drives.
If 80% of the reserved hard drive space is filled with logs, some of the log files must be deleted. In this case, a cleanup script is evoked, which deletes the log files that have been on the hard drive for the longest period of time. The cleanup script examines the log files that have been on the hard drive for 7 days, and deletes the oldest log files until enough space is available for the new logs. If there is still not enough space, the log files are deleted individually, again starting with the log files that have been on the hard drive for the longest period of time, until there is enough space for the new logs.
Figure ptidbglog Data Information (Example) shows an example of system log data output. Both system and debug log entries conform to the same ASCII format.
The following figure shows the fields that appear in each log entry.
ptidbglog Data Information (Example)
The following table lists and describes the fields shown in the preceding image.
System Log Entry Fields Descriptions
Field Name | Description |
---|---|
Date | Uses the form “mm dd”. |
Time | Uses a 24-hour clock: “21:18:43”. |
Process Name1 | A unique identifier for the internal process which generates the ptisyslog entry. For example, the entry snm: indicates that the condition originates in the internal MTP stack on the DSC Platform. |
Severity | Indicates the severity of the message as:
|
Message | System-generated message. |
Description | Data defined on a per message type basis providing details describing the event. |
Sequence Numbers | Each Management and Routing VM has its own sequence numbering in syslog that is reset at every startup. Each Management and Routing VM resets its sequencing independently. The sequence numbers ensure that there is no mismatching or confusion between the Management and Routing VMs. Note
There may be a slight delay between the local Management and Routing VM writing a log to its hard drive and the remote Management CPU receiving the forwarded log. For the DSC - SP2000 Platform, the syslog prepends sequence numbers on a message-by-message basis as they are received, but messages are only written to ONE of the log file to avoid duplication. For example, the messages intended for the /var/log/messages file with a priority below INFO are filtered and do not appear in the syslog. |
1 Some process entries reference event identifiers.
The Log Configuration utility (see the following figure) allows you to do the following:
The syslog default configuration is based on the following templates:
The Reset button at the bottom of the screen allows you to reset the log templates to their original state. There is no forwarding of any generated logs to e-mail or IP address.
You must make sure that the remote server has the syslog daemon configured to receive logs. Also, you must make sure that the appropriate port is configured if your firewall is active.
The DSC supports the collection of vital and necessary information using the Web UI. This information includes disk storage, routing, memory, hardware, and so on and is used by Engineering and Customer Support for troubleshooting purposes.
Only users with root credentials can collect engineering support information.
Click Engineering Support.
You can change the Information Collection Timeout as required between 10 and 120 minutes.
Click Initiate Information Collection.
The time required to collect the engineering information depends on your system configuration and the Information Collection Timeout.
The debug file containing the accumulated system detail and debugging information is stored in the compressed file /tmp/system-status-allslots-yyyy-mm-dd-hhmmss.tar.bz2 (for example, /tmp/system-status-allslots-2017-07-19-170320.tar.bz2). Inside this file, is a compressed file for each slot in the system.
For each slot, a file is created in the /tmp directory: system-status-slot<slot number>-yyyy-dd-mm-hhmmss.tar.bz2 for the CPU cards and system-status-slot<slot number>-yyyy-dd-mm-hhmmss.tar.gz2 for IO cards.