There are three things to do in order to be able to get access to all of the HMC statistical groups (using a Performance Assurance collector version of 7.5.00 or later):

1. Run the $BEST1_HOME/bgs/scripts/configure_openssh script on the partition (which may have already been done using the instructions in the Configuring data collection from HMC (for AIX systems) TSCO 20.02 documentation link: https://docs.bmc.com/docs/pages/viewpage.action?pageId=914178276
2. Run the $BEST1_HOME/bgs/scripts/configure_frame_stats script on the partition (to configure the HMC to report the data required for Physical Partition Statistics, Pool Statistics, and Processor Pool Statistics groups) as described in the Unix frame metrics documentation.  TSCO 20.02 documentation link: https://docs.bmc.com/docs/display/btco2002/UNIX+frame+metrics
3. Optionally, enable the reporting of the Shared Pool Idle time metric for the partition.  Note that if you are collecting HMC data this is not required.  However, it supports real-time SPLPAR analysis (using Investigate).

Enable the HMC to report statistical data

The configure_frame_stats command requires the hscroot password when it is executed.

The configure_frame_stats command does not require any command line arguments to be specified.  By default, the HMC is being configured to provide new data every 60 minutes.  If you want the statistics to be refreshed more frequently, specify the -s flag to set a shorter statistics summarization interval.

For example, to configure the HMC to collect the statistics once every 60 seconds the command is:

Note that you must be running HMC version 7.3.2 or later In order to be able to configure the HMC to report the statistics data more frequently than every 60 minutes.

By default, the collector samples the Physical Partition Statistics, Pool Statistics, and Processor Pool Statistics metrics every 60 seconds. But the results will only change as frequently as the HMC has been configured to produce data.  So if the default configuration of the HMC is used, 60 minutes, you would see 60 identical observations over a 60 minute time period, then another set of 60 observations over the next 60 minutes, and so on.  So for maximum granularity, set the HMC frequency to 60 seconds, which corresponds with the 60 second sampling rate of the AIX collector. 

----------------------------------------------------------

Q. What command(s) are run by "configure_frame_stats"?

The script is logging into the HMC and then running the 'chlparutil' command on the HMC with the appropriate flags, which alternately can be manually executed if one were already logged into the HMC.

Q. Does the "configure_frame_stats" script do anything on the agent/server side to enable or start collecting Physical Partition Statistics, Processor Pool Statistics or Pool Statistics metric groups?

A. No. It simply configures the HMC to collect statistical about the frame, nothing more.  The data collection .mt file contains the list of which metric groups to collect.

Q. Is there a recommended setting for the data collection frequency specified using "configure_frame_stats"?

A. No. It  really depends on your use cases for this data.  If you are just collecting UDR say every 15 minutes, then 900 seconds is in theory often enough.  If you're using Investigate for real-time monitoring, probably something like 60 seconds is more appropriate.  You can always set the frequency higher -- that's never a problem.  The data collection parameters will summarize whatever you've specified for the HMC frequency to the udr "frequency" you've specified.  For example, if you have requested 10 second sampling and 15 minute spills and have set the HMC frequency to 60 seconds, your real-time data will show 6 data points with the same value (6 * 10 seconds = 60 seconds) and your UDR data will show the average of 90 data points (15 minutes = 900 seconds = 90 * 10 seconds), but that's really 15 unique data points (900 seconds = 15 * 60 seconds).

Q. Do I need to run "configure_frame_stats" if the HMC statistical frequency has already been set to support another tool?

A. No. As long as someone has set an appropriate frequency for that HMC, it doesn't need to be run a second time.

Enabling Shared Pool Idle time reporting

000031383: How is the AIX 'Shared Pool Idle Time' metric used and collected by Perform when reporting AIX SPLPAR CPU utilization? explains how to enable the collection of the Shared Pool Idle Time metric.  Note that this step is optional if you've enable HMC statistical data collection.

Debugging collection failure

If you have Physical Partition Statistics or Pool Statistics reporting problems after these steps, please provide the following to Customer Support:

• The output of $BEST1_HOME/bgs/bin/bgsagent_logs -n [hostname of the partition configured for HMC data collection] > /tmp/logs.txt

That information will help us determine why data isn't being reported. Also, it would be best to maintain login access to the partition configured to collect the HMC information during this debugging period. One of the commands that Engineering typically likes to see when debugging any type of HMC data collection problem is:

This command is run from the command line of a partition that's been connected to the HMC.

Q: In Investigate, is it possible to mimic the type of frame level reporting available in Perceiver?

You can't create a graph in Investigate that exactly mimics what you are seeing in Perceiver because there is no single metric group in Investigate that has all of the information necessary to create that graph.  Beginning with Performance Assurance version 9.0.00, this is no longer the case -- you can get either a real-time or Visualizer CDB view of all partitions on a frame from a collector running on a single SPLPAR utilizing HMC statistical data (described in 000107460: How to use one Performance Assurance collector on an AIX frame, and get high-level results for every partition)

To create a similar view in Investigate without access to HMC statistical data, you need to know:

1. If a partition is a DLPAR or an SPLPAR
2. If it is an SPLPAR what pool it belongs to 
3. The number of processors available in the pool
4. The amount of CPU consumed by each partition in the pool

A combination of the data in the Physical Partition Configuration group and the Physical Partition Statistics group has all the information (but it's not possible to combine data from multiple groups in Investigate).

So currently you can see:

• What percentage of the CPU for the whole frame a partition is consuming via the Physical Partition Statistics group
• What quantity of CPU is still available in the pool via the 'Available Pool Processors' metric in the System Statistics group
• What quantity of CPU is being used in the pool overall via the "CPU Utilization" metric in the Pool Statistics group

For multiple shared processor pools, you can drill down on the Processor Pool Statistics metric group to see a view of each SPLPAR in the pool and what percentage of the pool resources each SPLPAR is consuming.

If you have a frame where there is only a single pool that encompasses all of the processors on the frame and there are no DLPARs configured, then the Physical Partition Statistics group would effectively report % utilization out of the pool (since % pool utilization and % frame utilization would be exactly the same in that environment). But if the pool only represents a faction of the system, then you can't create that graph in Investigate.