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

  • select a log file to browse with up to 50 pages at one time

  • monitor updates in real-time

  • download a log file to your computer

  • standard navigation of log files (forward, back, specific log file lines)

  • send log file to a designated IP address
Caution

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.

Logging Description

The DSC - SP2000 Platform supports the following alarm and event logs:

  • system log (ptisyslog). This log stores service-affecting (alarms) and nonservice-affecting (significant events) conditions. The log allows you to determine the state of your system.

  • debug log (ptidbglog). This log stores detailed information about system activity. This log is used by Customer Support personnel for troubleshooting purposes. Details about the log are not provided.

  • messages log (messages). This log stores all messages of info priority or higher.

  • secure log (secure). This log stores SSH- and SFTP-related information.

  • boot log (boot.log). This log stores system boot information.

  • heartbeat (heartbeat). This log stores information regarding high availability mechanisms such as the Heartbeat application which keeps track of the network status (the status of the Ethernet ports).

  • audit trail (audit_trail) can be used to analyze user activities for creating, deleting, and modifying SS7 applications as well as any actions committed using these applications.

  • 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.

Log Rotation on the Hard Drives

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.

Viewing Logs

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:

  • LOG (information only)
  • MINOR (not performance affecting)
  • MAJOR (potentially performance affecting)
  • CRITICAL (performance affecting)
  • CLR_MINOR (clear minor alarm)
  • CLR_MAJOR (clear major alarm)
  • CLR_CRITICAL (clear critical)
  • UNKNOWN
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.

To view system logs

  1. From the Main Menu, click Logs.

  2. Click the File drop-down list and select the log file you want to view in detail.

  3. Use the navigation buttons to view the files as required.

Configuring Logging

The Log Configuration utility (see the following figure) allows you to do the following:

  • forward certain logs such as system messages and security messages to a defined IP address. Any logs that you forward to an IP address appear under the Current Syslog.conf heading.

  • reset syslog configuration to default

The syslog default configuration is based on the following templates:

  • /var/log/messages

  • /var/log/secure

  • /var/log/ptidbglog

  • /var/log/heartbeat

  • /var/log/audit_trail

To configure logging

  1. From the Main Menu, click Logs.

  2. Click Log Configuration.


  3. Configure the logging as required.

  4. Click Continue.
Tip

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.

Collecting Engineering Support Information

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.

Note

Only users with root credentials can collect engineering support information. 

To collect engineering support information (Example)

  1. From the Main Menu, click Logs.
       

  2. Click Engineering Support.

    Tip

    You can change the Information Collection Timeout as required between 10 and 120 minutes.


     

  3. Click Initiate Information Collection.

    Tip

    The time required to collect the engineering information depends on your system configuration and the Information Collection Timeout.

    Tip

    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.  

  4. Click the file.
       


  5. You can open or save the file as required.

  6. Opening the file displays the list of files compiled during this process.

  

  • No labels