Configuring Scheduled Historical PM Collection
Use this procedure to enable scheduled historical PM collection and to configure the collection schedule.
The PSM server can be configured to automatically collect historical PMs from all managed network elements. The amount of memory required to store these PMs is dependent on the number of metrics (PM points) collected, the frequency of collection, and the number of network elements.
Before you enable scheduled historical PM collection, ensure you have sufficient disk storage space.
Each data point in the database is 12 bytes in size. To calculate the amount of storage required for a particular scenario, determine the number of data points stored and multiply by 12. This provides a good approximation of the storage required. Minor fixed storage costs are not included in this calculation.
For example, for a BTI7200 NE fully loaded with 19 MXP cards with 12 ports per card and 12 supported PM points per port:
memory storage required per month (15-minute and 1-day PMs) = number of cards per NE * number of ports per card * number of supported PM points per port * number of 15-minute and 1-day PM bins per day * 30 days per month * 12 bytes per point = 19 * 12 * 12 * (96 + 1) * 30 * 12 = approximately 96 MB per NE
The historical PM database is located in the
/backups partition, which is sized at 15% of the
total disk space. The PSM server stores PMs in the database
for 30 days. PM data points older than 30 days are purged from the
Scheduled historical PM collection scheduling is performed by
specifying the values of the following properties in the
// Switch for turning on/off the scheduled historical PM collection. Controls all NEs. pm.historical.collectionEnabled=false // Switch for turning on/off the scheduled historical PM collection for 7800 type NEs. pm.historical.7800CollectionEnabled=false // Switch for turning on/off the scheduled historical PM collection for 800 type NEs. pm.historical.800CollectionEnabled=false // Schedule for Historical PM collection for 7000 type NEs. // Every 12 hours. schedule.historicalPmCollection.cron=0 0 0/12 * * ?
By default, the PSM server retrieves historical PMs every 12 hours, which allows time to correct any retrieval failures for the 1-day bin while minimizing unnecessary processing. If you want to view historical PMs that have not yet been retrieved, you can use the manual PM retrieval function that allows you to retrieve historical PMs on demand. See the proNX Service Manager User Guide for details.
Be careful not to set the retrieval frequency such that a new retrieval is initiated before the current retrieval has completed. The prospect of this occurring increases as the network element becomes more populated. Some fully-populated network elements may require up to 30 minutes or more for the PM retrieval process to complete.
- On the workstation where the PSM server is installed,
/var/local/ems9001/conf/override-common.propertiesfile contains many settings that affect the behavior of the PSM server. Only those attributes explicitly described in this guide should be changed. Changing any other attributes may have unintended consequences, and must only be performed under the guidance of Juniper Networks Support.
- Enable or disable historical PM collection as desired.
To enable historical PM collection for the BTI7000 Series NEs, set
To enable historical PM collection for the BTI7800 Series NEs, set
To enable historical PM collection for the BTI800 Series NEs, set
To disable historical PM collection for all NEs, set
To disable historical PM collection for the BTI7800 Series NEs only, set
To disable historical PM collection for the BTI800 Series NEs only, set
- Set the collection schedule by changing the
For information on how to set this value, see Example: Scheduling Using Quartz CronTrigger Format.
- Save and close the
- Track changes to the
/var/local/ems9001/conf/override-common.propertiesfile with Git by committing this update to the Git repository.
[user ~]# cd /var/local/ems9001/conf [user conf]# git commit -m "Configured historical PMs. By email@example.com." override-common.properties
This update can now be seen in the Git log. For more information on Git, see Using Git to Track override-common.properties.
- To activate changes made to the
override-common.propertiesfile, restart the PSM server.
The restart command successfully completes when the 'Ems-' processes all change to 'running' state. Type <ctrl> c to exit the Linux watch command window.