Historical Collection Best Practices. Version 2.0

Transcription

1 Historical Collection Best Practices Version 2.0 Ben Stern, Best Practices and Client Success Architect for Virtualization and Cloud Copyright International Business Machines Corporation All rights reserved. US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Introduction: The following paper describes a Best Practices approach for Historical Data Collection. Each customer s environment is unique, but this paper will help you configure a good default set of historical collection. This paper does not attempt to cover ALL Agents, but will give recommendations for a key subset of Agents and will give some general guidelines that should be used for all Agents. Before enabling historical collection think about your business requirement for the data. There are four common use cases for the historical data. Your needs will vary for each attribute group, so consider the use cases for each attribute group when configuring historical collection: Problem Determining and Debugging: Predictive Alerting Adaptive Monitoring. Each of these use cases has different historical requirements. The following sections describe each of the use cases and the types of historical collection that will be desirable. Problem and Debugging: Some types of metrics are used for problem determination and debugging. This tends to be relatively short term in nature. Occasionally there is a need to compare performance from a long time ago, but most of the time, Subject Matter Experts (SMEs)

2 want to go back a few and evaluate the performance of a server or application and compare it to the current performance. In this case, there is no need for Summarization of the data. : When data is used for, you need to consider the purpose of the reports. Some reports are used for long term trend. Some reports are used to show SLAs are being met. Some reports are relatively short term reports to show the health of a server. When configuring historical collection, you need to consider the purpose of your reports. The primary driver of the historical collection is the duration of the reports. For short term reports, you can use Detailed data. For short to medium term reports, use Hourly summarized data. For medium to long reports use Daily or Weekly summarization. Keep in mind when configuring Summarization, you don t need to configure all summarization intervals. Some people are under the misconception that if they want Weekly Summarization that they need to configure both Daily and Hourly summarization. That is not the case. Each summarization interval can be configured independently. For example, I can configure UNIX Disk space summarization to retain the detailed metrics for 5 and Daily Summarization Data for 90. I don t need to configure Hourly Summarization. /Predictive Analytics: When doing and Predictive Analytics, you typically perform long term trend. The Performance Analyzer tool uses Daily summarization data for the out of the box Analytic Functions. So, in most cases, configure Daily Summarization. Of course, you can define your own Analytic Functions and use Hourly or Weekly summarization data. To ensure the Analytic Functions perform well, ensure that you have an appropriate number of data point in the Summarized table. If you have too few, the statistical won t be very accurate. You ll probably want at least 25 or 50 data points. To achieve 50 data points using Daily Summarization, you ll need to keep the data for 50 before pruning. More data points will make the statistical predictions more accurate, but will affect the performance of your and statistical. I would recommend no more than a few hundred data points per resource being evaluated. If you use Hourly Summarization, you ll generate 336 data points every 2. Adaptive Monitoring (Dynamic Thresholding): The new Adaptive Monitoring (Dynamic Thresholding) capabilities that were added to ITM allow you to analyze historical data to define a threshold that is based on the past performance characteristics. You can define time of day and shifts to analyze the historical data and make recommendations on thresholds. As an example, evaluate

3 the Prime Shirt data for 2 and set the threshold at 1 standard deviation about normal. Adaptive Monitoring uses Detailed data to evaluate and make recommendations on thresholds. Therefore, you ll need to keep a reasonable duration of Detailed data in order to perform the evaluation. The duration depends on how you define your shifts. If you define shifts that include day of, then you will need to keep the data longer in order to get an effective of the data. If you are only looking at Prime Shift for all, then you won t need the data as long. We recommend 7 to 30 of detailed data when comparing all work. If you compare Monday to Monday, then you will need to keep the Detailed data much longer in order to be able to establish a trend. When comparing a specific day of the, you will probably need to have at least 60 of data. Before configuring Adaptive Monitoring, you need to consider the use of the data. It doesn t make sense to perform Adaptive Monitoring on certain types of data. For example, it wouldn t make sense to perform Adaptive Monitoring for disk space. You must want to set a static threshold on either the % free space or the amount of disk space available. On the other hand, CPU monitoring is an excellent candidate for Adaptive Monitoring. It can be very beneficial to learn whether a server is behaving abnormally. Agent and Attribute Group Considerations Each Agent and each Attribute Group must be considered separately when defining Historical Collection. Tivoli has the following recommendations for a subset of the Agents and Attribute Groups. Many of our Agents have defined a set of Best Practice Historical collections. This does not include the Summarization and Pruning intervals, but is a good place to start when setting up historical collection. To use the Best Practice historical configuration, press the Show Default Groups button. The following section provides a set of recommendations for many of the Agents. These are just starting points. When looking at these recommendations, you must also consider whether you plan to use Adaptive Monitoring, short term problem determination, long term and/or /Predictive Analysis. This must be taking into account when configuring the Summarization and Pruning Intervals. The following paragraph outlines some of the that was done when determining the recommended set of historical collections. CPU data is typically used for problem determination and debugging and is used for longer term trend. Because of this, it needs to be collected more frequently and you might need multiple summarization intervals depending on what you plan to do with the data. Unlike CPU data, disk space is typically only used for long term capacity planning. You probably only need to collect disk space metrics once a day and do not need to summarize the data unless you need a specific TCR report. Unlike Disk space data, Disk I/O data is used for

4 problem determination and needs to be collected more frequently and kept for a shorter period of time. Here is some general discussion on Process historical collection. This is important for ALL of the OS Agents. In general, we don t recommend collecting process historical data. It is extremely high volume data that will put a heavy load on your Warehouse database. However, there are cases where it is important to have process historical data. If this data is important to you, then here are some guidelines and options. One option is to collect short term history data, but not Warehouse that data. That will give you access to the some short term debugging information that will allow you to look for issues shortly before you encountered a problem. With short term history collection, we collect 24 hours of history data on the Agent, but don t warehouse the data. If you need more than 24 hours of data, we recommend you keep ONLY the raw (detailed) data and don t summarize the Process data. There are 2 reasons you shouldn t summarize your Process data. First, it puts an extremely high load on your Warehouse server. Second, process data doesn t summarize very well. There are a couple of reasons why Process data doesn t summarize well. You have short lived processes that might only run for 4 or 5 seconds. Those processes will be captured historically and will reside in the Warehouse database for or depending on your retention settings. This causes the Process table to get very large. In addition, when you stop and restart an application, the process ID changes. We can t summarize that process over time since the process ID has changed. So, Summarizing process data creates results that are of limited value. If you do have a need for historical Process data, collect the detailed data and use that data for your. Most customers that collect Process data, keep the detailed data for at most 2 and then prune the older data. The section below outlines general recommendations for each Agent. You should tailor these collections to meet your needs. New Historical Collection Options Starting with ITM 6.2.2, Historical Collection can be configured uniquely on each server in the environment. As you enable the historical collection, think about the normal use cases for the metrics you are collecting and whether those metrics should be enabled on all servers or only on a subset of your systems. This can dramatically reduce the load on your Warehouse Database server. Here is an example use case. For the majority of my servers, I might want to collect CPU data every 5 or even every 15 minutes. However, there may be a small subset of servers where I need to debug a problem or optimize performance. I can create a Managed Systems List with the small subset of my servers and configure 1 minute historical collections. See the screen capture below:

5 Figure 1: Historical Collection Distribution The release of IBM Tivoli Monitoring introduced the concept of Historical Collection filtering. This provides customers with the ability to filter the rows of data being collected from a server. This feature is particularly useful for attribute groups where large numbers of rows of data are collected during each interval. Examples are Process data and Disk data. For Disk data, you will notice that most operating systems have file systems that are zero bytes in size. Since the size of those file systems never changes, there is no point collecting historical data for those file systems. In this case, I recommend defining a filter that looks like that screen capture below.

6 Figure 2: Historical Collection Disk Filtering Another useful example is process monitoring. It is not important to collect historical data for most processes unless they are either consuming resources or are using large amounts of memory and have a potential memory leak. By filtering out idle processes and processes that have less than a pre-defined memory threshold, you can dramatically reduce the amount of data being collected. Typically, filtering allows customers to reduce the number of processes being collected from 100 down to 10 or fewer. See the example screen capture below.

7 Figure 3: Historical Filtering on Process Data Database Optimization The Tivoli Data Warehouse is a high performance database. Some customers have databases with 10+ Terabytes of data and gather hundreds of millions of rows of data per day. Therefore, it is critical that you have your database administrator setup the Tivoli Data Warehouse. There are several considerations that should be taken into account to achieve optimal performance. Tune the Database The database must be tuned. Tuning will vary based on the operating system and the database vendor and version being used. However, there are some general guidelines that should always be followed. Increasing the amount of memory available to the database will improve performance. For a DB2 database, increase the size of the buffer pools. Significantly increase the size of the transaction logs. The default sizes are insufficient for the Tivoli Data Warehouse.

8 Disk I/O is typically the bottleneck with the Tivoli Data Warehouse. There are a couple of things that can be done to improve performance related to Disk I/O. o Get very fast storage for the database files. Use either a large RAID array or SAN storage with many physical disks allocated to the database. o Separate out the transaction logs from the database files onto separate filesystems. o Create separate tablespaces for the largest database tables. The Warehouse Planning Spreadsheet which can be found at the URL below can help you identify which tables will be the largest. Most customers have 5 or 6 tables that are significantly larger than the remaining tables. From a performance perspective, focus on the largest tables and try to optimize their performance and disk I/O. Warehouse Planning Spreadsheet: ibm.com/software/brandcatalog/ismlibrary/details?catalog.labe l=1tw10tm1y Database Compression Database compression can significantly improve the performance of your Tivoli Data Warehouse. By compressing the data, you will save on disk space. More importantly, by reducing the storage space required, you also reduce the disk I/O. This significantly improves the performance of the database. With most database vendors, software to perform database compression is an additional chargeable feature or product. However, if you are encountering any performance issues, it will provide significant performance improvements. With DB2 s Storage Optimization feature, we typically see approximately 50% compression of the data and 200% to 300% performance improvements. I ve even seen customers with as much as a 400% improvement in performance. Let s assume that Summarization and Pruning processing requires 10 hours per day to complete when not using database compression. By compressing the tables and indexes, you can expect the Summarization & Pruning processing to require less than 4 hours. Please remember that it s important to compress both the tables and indexes to achieve the largest performance gains. Windows OS Agent Note: The Windows OS Agent has a set of older superseded tables and newer tables. We recommend you only collect one or the other. Use the superseded tables until you reach a point when ALL of your agents have been upgraded. If all of your Agents are upgraded to the level of code or higher, use the new tables. By using either the superseded or new tables, you maintain the ability to run a report against all of your systems. If your data is split between tables, it becomes more difficult to run historical reports. Prior to ITM 6.2.2, the Performance Analyzer (ITPA) had limitations that it could only analyze 32-bit data. If you are using Performance Analyzer, you should continue to use

9 the older ITM tables. After the 64-bit data is supported, you can consider migrating the data from the older tables into the new tables. Since the new tables are typically a superset of the old tables, it is fairly easy to export the data and then import into the new tables. For the purposes of this document, I m only listing the NEW tables for the Agent, but know that superseded tables exist for many of these attribute groups. Do NOT collect Windows Thread data because this is a very high volume table. Do not collect Windows Services data. It is extremely high volume data. The Windows OS Agent contains a number of metrics that are very useful to collect historically if you are running on a server that has the particular enterprise service enabled. For example, if you server is a DNS server, then the DNS metrics will be very useful to collect historically. We can collect MSMQ metrics on servers that utilize MSQM. Starting with ITM 6.2.2, historical configuration can be configured for individual servers or Managed Systems Lists. If you have ITM or higher, we recommend you enable the historical collection for these attribute groups on the servers where the services are running. Prior to 6.2.2, you can double check the attribute groups. If no rows are returned on most of the servers, it will be safe to enable the historical collection. Attribute Groups worth considering in addition to the ones below are: DHCP Server (for DHCP Servers) DNS Memory (for DNS Servers) DNS WINS (for DNS Servers) DNS Dynamic Update (for DNS Servers) FTP Server Statistics (for FTP Servers) HTTP Service (for HTTP Servers) IIS Statistics (only if you are not using the IIS Monitoring Agent) MSMQ Queue (for MSMQ Servers) MSMQ Information Store (for MSMQ Servers) MSMQ Sessions (for MSMQ Servers) Attribute Group Typical Types of Collection NT_Memory Long Term trend NT_Logical_Disk Long term trend Recommended Collection Intervals 15 minute interval, retain for 2 Daily Summarization, retain for 1 60 Minute Collection, retain for 2 Daily Summarization, retain for 6

10 Network Interface Problem and Medium range capacity planning Processor Problem and short, medium, and long term trending Processor Summary Problem and short, medium, and long term trending Physical Disk Disk I/O Data used for short/medium term trending. Server Problem and Medium range capacity planning System Configuration Data Note: We also capture processor queue, but Processor table can be used instead. Process Used for short term problem determination Note: Filter out _Total for disk data 5 minute interval, retain for 2 Daily Summarization, retain for 3 Note: Filter out loopback traffic 5 minute interval, retain for 2 Hourly Summarization, retain for 3 Daily Summarization, retain for 1 5 minute interval, retain for 2 Hourly Summarization, retain for 3 Daily Summarization, retain for 1 5 minute interval, retain for 2 Hourly Summarization, retain for 3 5 minute interval, retain for 2 Daily Summarization, retain for 3 Weekly collection, retain for minute collection, retain for 1 to 2. Filter out processes that are not consuming CPU cycles or are not using more than 200 Meg of memory. UNIX OS Agent

11 Attribute Group Typical Types of Collection SMP_CPU Problem and short, medium, and long term trending Disk Long term trend Disk_Performance Disk I/O Data used for short/medium term trending. Network Problem and Medium range capacity planning UNIX_IP_Address Used for table join with Network table. Only needed once per day. Unix_Memory Long Term trend NFS_and_RPC_Statistics Problem and short, medium, and long term trending System Problem and short, Recommended Collection Intervals 5 minute interval, retain for 2 Hourly Summarization, retain Daily Summarization, retain for 1 60 Minute Collection Daily Summarization Retain for 6 Note: Filter out data for file systems that are zero bytes in size. 5 minute interval, retain for 2 Hourly Summarization, retain Note: Filter out file 5 minute interval, retain for 2 Daily Summarization, retain for 3 Note: Filter out loopback traffic Collect once per day so that Network traffic reports can join with this table to include IP Address for each NIC. 15 minute interval, retain for 2 Daily Summarization, retain for 1 5 minute interval, retain for 2 Hourly Summarization, retain Daily Summarization, retain for 1 5 minute interval, retain for 2 Hourly Summarization, retain

12 medium, and long term trending Solaris Zones Only collect for Solaris Zone: Use for Capacity Planning and medium/long term trending. Daily Summarization, retain for 1 5 minute interval, retain for 2 Hourly Summarization, retain Daily Summarization, retain for 1 Linux OS Agent Note: The Linux OS Agent has a set of older superseded tables and newer tables. We recommend you only collect one or the other. Use the superseded tables until you reach a point when ALL of your agents have been upgraded. If all of your Agents are upgraded to the level of code or higher, use the new tables. By using either the superseded or new tables, you maintain the ability to run a report against all of your systems. If your data is split between tables, it becomes more difficult to run historical reports. Prior to ITM 6.2.2, the Performance Analyzer (ITPA) had limitations that it could only analyze 32-bit data. If you are using Performance Analyzer, you should continue to use the older ITM tables. After the 64-bit data is supported, you can consider migrating the data from the older tables into the new tables. Since the new tables are typically a superset of the old tables, it is fairly easy to export the data and then import into the new tables. For the purposes of this document, I m only listing the NEW tables for the Linux Agent, but know that superseded tables exist for many of these attribute groups. Do NOT collect Linux_Sockets_Details because this is a very high volume table. Attribute Group Typical Types of Collection Linux_CPU Problem and short, medium term trending Linux_CPU_Averages Long term trending Recommended Collection Intervals 5 minute interval, retain for 2 Hourly Summarization, retain 5 minute interval, retain for 2 Daily Summarization, retain for

13 1 Linux_CPU_Config Hardware Config data. Collect once a. Do not Summarize. Keep for 1. Don t collect if you have an Inventory product like TADDM or TPM. Linux_Disk Long term trend 60 Minute Collection Daily Summarization Retain for 6 Note: Filter out file systems that are zero bytes in size. Linux_Disk_IO Disk I/O Data used for short/medium 5 minute interval, retain for 2 term trending. Hourly Summarization, retain Linux_IO_Ext Disk I/O Data used for short/medium 5 minute interval, retain for 2 term trending. Hourly Summarization, retain Linux_Network Problem and 5 minute interval, retain for 2 Medium range capacity planning Daily Summarization, retain for 3 Note: Filter out loopback traffic Linux_IP_Address Used for table join with Network table. Only needed once per Collect once per day so that Network traffic reports can join with this table to include IP Address for each NIC. day. Note: Filter out the loopback address Linux_NFS_Statistics Problem and 5 minute interval, retain for 2 short, medium, and long term trending Hourly Summarization, retain Daily Summarization, retain for 1 Linux_OS_Config Configuration Data Collect once a. Do not Summarize. Keep for 1. Linux_RPC_Statistics Problem and 5 minute interval, retain for 2 short, medium, and long term trending Hourly Summarization, retain

14 Linux_Socket_Status Problem and short, medium term trending Linux_Swap_Rate Problem and Long Term trend Linux_System_Statisti cs Daily Summarization, retain for 1 5 minute interval, retain for 2 Hourly Summarization, retain Problem and short, medium, and long term trending VM_Stats Problem and medium/long term trending 15 minute interval, retain for 2 Daily Summarization, retain for 1 5 minute interval, retain for 2 Hourly Summarization, retain Daily Summarization, retain for minute interval, retain for 2 Daily Summarization, retain for 1. Premium AIX Agent Note: If you are gathering key metrics with the Premium AIX Agent, don t collect the same attribute groups with the UNIX OS Agent. It is better to gather CPU, Memory, and I/O data via the Premium Agent. Attribute Group KPX CPU Summary Typical Types of Collection Long term trend KPX CPU Detail Short/Medium term trend KPX System IO Prob Recommended Collection Intervals 5 minute interval, retain for 2 Daily Summarization, retain for 1 5 minute interval, retain for 2 Hourly Summarization, retain for 3 5 minute interval, retain for 2 Daily Summarization, retain for 3 KPX Paging Space Long Term trend 15 minute interval, retain for 2

15 KPX Logical Partition KPX Workload Manager KPX Physical Memory KPX Virtual Memory Manager LPAR Utilization - Problem and Long Term trend Long term trend Long Term trend Long Term trend KPX Disks Disk I/O Data used for short/medium term trending. KPX Physical Volumes KPX Volume Groups Disk Space used for long term trend Volume Group Space used for long term trend KPX File Systems File System Space used for long term trend KPX Network Adapter Rates KPX Internet Protocol Summary Problem and Medium range capacity planning Long term capacity planning Daily Summarization, retain for 1 5 minute interval, retain for 2 Hourly Summarization, retain for 3 Daily Summarization, retain for 1 5 minute interval, retain for 2 Daily Summarization, retain for 1 15 minute interval, retain for 2 Daily Summarization, retain for 1 15 minute interval, retain for 2 Daily Summarization, retain for 1 5 minute interval, retain for 2 Hourly Summarization, retain for 3 Once a day, retain for 1 Once a day, retain for 1 Once a day, retain for 1 5 minute interval, retain for 2 Daily Summarization, retain for 3 15 minute interval, retain for 2 Daily Summarization, retain for 1

16 KPX Internet Protocol Details Problem KPX TCP Problem KPX WPAR CPU Long term trend Analisys and Problem KPX WPAR Physical Memory KPX WPAR Filesystem KPX WPAR Information Long term trend Long term trend analyisis Long term configuration retention 5 minute interval, retain for 2 Hourly Summarization, retain for 3 5 minute interval, retain for 2 Hourly Summarization, retain for 3 Only use if using WPARs 5 minute collection, retain 2 Daily Summarization, retain for 1 Only use if using WPARs 15 minute interval, retain for 2 Daily Summarization, retain for 1 Only use if using WPARs Once a day, retain for 1 Only use if using WPARs Once a day, retain for 1 HMC Agent Attribute Group KPH CPU Summary Typical Types of Collection Long term trend KPH Paging Space Long Term trend KPH Physical Memory Long Term trend KPH File Systems File System Space used for long term trend Recommended Collection Intervals 5 minute interval, retain for 2 Daily Summarization, retain for 1 15 minute interval, retain for 2 Daily Summarization, retain for 1 15 minute interval, retain for 2 Daily Summarization, retain for 1 Once a day, retain for 1

17 KPH Managed Systems Configuration Retention Once a day, retain for 1 CEC Agent Attribute Group Typical Types of Collection KPK Global CEC CEC Utilization - Long term trend KPK Per LPAR Problem. Note: Premium Agent can be used for trend KPK CPU Pools Long Term trend KPK Mon LPARs CEC Utilization - Long term trend KPK Mon Unmon Alloc CEC Utilization - Long term trend Recommended Collection Intervals 5 minute interval, retain for 2 Daily Summarization, retain for 1 5 minute interval, retain for 2 5 minute interval, retain for 2 Daily Summarization, retain for 1 5 minute interval, retain for 2 Daily Summarization, retain for 1 5 minute interval, retain for 2 Daily Summarization, retain for 1 VIOS Premium Agent Attribute Group Typical Types of Collection Recommended Collection Intervals KVA CPU Summary Long term trend 5 minute interval, retain for 2 Daily Summarization, retain for 1 KVA CPU Detail Short/Medium term trend 5 minute interval, retain for 2 Hourly Summarization, retain KVA System IO Prob 5 minute interval, retain for 2 Daily Summarization, retain for

18 3 KVA Paging Space Long Term trend KVA Logical Partition KVA Workload Manager KVA Physical Memory KVA Virtual Memory Manager LPAR Utilization - Problem and Long Term trend Long term trend Long Term trend Long Term trend KVA Disks Disk I/O Data used for short/medium term trending. KVA Physical Volumes KVA Volume Groups Disk Space used for long term trend Volume Group Space used for long term trend KVA File Systems File System Space used for long term trend KVA Network Adapter Rates KVA Internet Protocol Summary Problem and Medium range capacity planning Long term capacity planning 15 minute interval, retain for 2 Daily Summarization, retain for 1 5 minute interval, retain for 2 Hourly Summarization, retain Daily Summarization, retain for 1 5 minute interval, retain for 2 Daily Summarization, retain for 1 15 minute interval, retain for 2 Daily Summarization, retain for 1 15 minute interval, retain for 2 Daily Summarization, retain for 1 5 minute interval, retain for 2 Hourly Summarization, retain Once a day, retain for 1 Once a day, retain for 1 Once a day, retain for 1 5 minute interval, retain for 2 Daily Summarization, retain for 3 15 minute interval, retain for 2 Daily Summarization, retain for

19 1 KVA Internet Protocol Details Problem 5 minute interval, retain for 2 Hourly Summarization, retain KVA TCP Problem 5 minute interval, retain for 2 Hourly Summarization, retain KVA Storage Configuration Once a day, retain for 1 Mappings Details KVA Network Configuration Once a day, retain for 1 Mappings Details KVA Devices KVA MPIO Status Availability Report Once a day, retain for 1 KVA MPIO Configuration Once a day, retain for 1 Attributes Details KVA Shared Ethernet Adapter Problem, short 5 minute interval, retain for 2 term Daily Summarization, retain for 3 KVA Quality of Service Problem and 5 minute interval, retain for 2 Medium range capacity planning Daily Summarization, retain for 3 VMware VI Agent Attribute Group Typical Types of Collection KVM Long term trend DATASTORES Required for TCR KVM SERVER Medium/Long term trend and capacity planning Useful for TCR Required for Recommended Collection Intervals 15 minute interval, retain for 1 Summarize Daily, retain for 60 5 minute interval, retain for 1 Summarize Hourly, retain for 30 Summarize Daily, retain for 120

20 KVM SERVER CPU Problem, and capacity planning Required for TCR Required for KVM SERVER DATASTORE KVM SERVER DISK Long Term trend and capacity planning Required for TCR Required for Problem and Long Term trend /capacity planning Required for TCR Required for KVM SERVER HBA Medium/Long term trend Useful for TCR Required for KVM SERVER Medium/Long Term MEMORY trend Useful for TCR Required for KVM SERVER Long Term trend NETWORK Required for TCR Required for KVM VM CPU Debugging, Short/Medium Term 15 minute interval, retain for 1 Summarize Hourly, retain for 30 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 30 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 30 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 30 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 30 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 30 Summarize Daily, retain for minute interval, retain for 1

21 trend Useful for TCR Required for KVM VM Datastore utilization DATASTORE used for long term UTILIZATION trend Required for TCR Required for KVM VM DISK VM Disk data used for long term trend. Filter out Removable Disks like CDROM and Floppy drives Useful for TCR Required for KVM VM MEMORY VM Memory data used for short term debugging,, and capacity planning. Required for TCR Required for KVM VM NETWORK KVM VM PARTITION Problem and Medium range capacity planning Required for TCR Required for Long term capacity planning. Required for Summarize Hourly, retain for 30 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 30 Summarize Daily, retain for hour interval, retain for 1 Summarize Hourly, retain for 30 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 30 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 30 Summarize Daily, retain for hour interval, retain for 1 Summarize Hourly, retain for 30

22 KVM CLUSTERED DATASTORES KVM CLUSTERED RESOURCE POOLS Useful for TCR Medium/Long term Useful for TCR Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 14 Summarize Daily, retain for minute interval, retain for 1 Summarize Daily, retain for 60 KVM CLUSTERED SERVERS KVM CLUSTERED VIRTUAL MACHINES Problem determination and medium term trending Useful for TCR Short term problem determination Useful for TCR KVM CLUSTERS Short/Medium term problem determination Useful for TCR KVM RESOURCE POOL CPU KVM RESOURCE POOL GENERAL Resource Pool problem determination Useful for TCR Resource Pool problem determination and trend Useful for TCR 15 minute interval, retain for 1 Summarize Hourly, retain for 14 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 14 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 14 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 14 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 14 Summarize Daily, retain for 60 KVM RESOURCE Resource Pool 1 hour interval, retain for 1

23 POOL MEMORY KVM NETWORKED SERVERS KVM NETWORKED VIRTUAL SWITCHES problem determination and trend Useful for TCR Networking problem determination and trend Useful for TCR Networking problem determination and trend Useful for TCR KVM NETWORKS Networking problem determination and trend Useful for TCR KVM SERVER VIRTUAL SWITCHES KVM VIRTUAL MACHINES KVM VIRTUAL SWITCHES Networking problem determination long term trend Useful for TCR Long Term trend Required for TCR Required for Networking problem determination and trend Useful for TCR Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 14 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 14 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 14 Summarize Daily, retain for minute interval, retain for 1 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 30 Summarize Daily, retain for minute interval, retain for 1 Summarize Hourly, retain for 14 Summarize Daily, retain for 60