Augmenting Performance Session Retention Times

The retention period for the performance session data collected by Skylight orchestrator is the maximum amount of time that the data is kept on Skylight orchestrator before it is purged. Older data (stored for longer than the retention period) is automatically purged on a "first in, first out" basis. The retention period applies to data collected during performance sessions set up on Skylight orchestrator.

The default retention period is one week. This is recommended if Skylight orchestrator will be collecting performance session data and also collecting streamed metrics data from Skylight elements and Skylight sensor: control.

For the resizing disk space procedure, refer to Resizing Disk Space for a VMware Virtual Machine for VMware virtual machine or refer to Resizing Disk Space for a KVM Virtual Machine for the KVM virtual machine.

Procedure Requirements

A. This procedure must be executed from the Skylight orchestrator console. Connect to the console via a remote SSH client (appliance IP address, port 2200).

B. Part of this procedure is performed in the Skylight orchestrator console (Appliance Monitor CLI). To access the console, you need to know the credentials of the visionems user.

C. Part of this procedure is performed in mgr-commands mode. To enter this mode, you must know the credentials for a valid Skylight orchestrator user account (an account for the Skylight orchestrator web interface).

Procedure Steps

This procedure explains how to set the retention period for performance session data. Before doing the procedure, you should determine if you really need to change the default period (one week) as explained in Determining the Quantity and Size of Virtual Disks.

When you have determined the data retention period (a number of weeks) that is required for your system, you can set the value as explained below.

To augment performance session retention times in standalone orchestrator

1. Log in to the Skylight orchestrator console as the visionems user.

2. Set the retention period by entering this command:
   mgr-config name RRRetentionPeriod value < X >
   Where:

• X is number of weeks. Value can be 1 to 52.

3. Restart the Skylight orchestrator application server by entering:
   service restart app_server
   

   ---

   Note: It may take up to 10 minutes for the app_server to go from starting to started.

   ---

4. Confirm that the application server has restarted by entering this command:
   service show
   The list of services is displayed. The status of app_server should be Started.

5. Confirm that the retention period has been changed:
   a. Access mgr-commands mode by entering:
   mgr-commands
   You will be prompted to enter a username and password.
   b. Enter the username and password for a valid Skylight orchestrator user account (an account that can be used to access the Skylight orchestrator web interface).
   c. Display the configuration:
   show mgr
   d. Check that the retention period now says: < X > weeks.
   e. Quit mgr-commands mode by entering:
   quit

To augment performance session retention times in HA orchestrator

1. Open an SSH terminal session to the Skylight orchestrator designated as the preferred active site on port 2200.

2. Log in as the visionems user.

3. Set the retention period by entering this command:
   mgr-config name RRRetentionPeriod value < X >
   Where:

• X is number of weeks. Value can be 1 to 52.

4. Restart the HA redundancy to apply a new configuration by entering:
   redundancy control restart
   

   ---

   Note: It may take up to 10 minutes for the app_server to go from starting to started.

   ---

5. Confirm that the retention period has been changed:
   a. Access mgr-commands mode by entering:
   mgr-commands
   You will be prompted to enter a username and password.
   b. Enter the username and password for a valid Skylight orchestrator user account (an account that can be used to access the Skylight orchestrator web interface).
   c. Display the configuration:
   show mgr
   d. Check that the retention period now says: < X > weeks.
   e. Quit mgr-commands mode by entering:
   quit
   

   ---

   Notes:

   While HA redundancy is restarting, there will be a delay in PM reporting (5 to 10 minutes), but there will be no gap.

   No activity needs to be performed on the passive site. In case of failover, a new active site will have proper retention (< X > weeks in this example).

   ---