This isn't so much a question as it is a bug report.
cpu.sh outputs correct information on non-Micro-partitioned AIX servers; but on Micro-partitioned systems with SMT, the sar command adds a new column that invalidates the cpu.sh output.
Column headings from "sar -P ALL 1 1" output on a stand-alone server. This is what cpu.sh expects to see:
11:12:04 cpu %usr %sys %wio %idle physc
Column headings from "sar -P ALL 1 1" on a micro-partitioned system with SMT enabled. Notice the new column:
11:12:02 cpu %usr %sys %wio %idle physc %entc
This difference is addressed in the sar manpage:
Beginning with AIX 5.3, the sar command reports utilization metrics
       physc and %entc which are related to Micro-Partitioning and
       simultaneous multi-threading environments. These metrics will only be
       displayed on Micro-Partitioning and simultaneous multi-threading
       environments. physc indicates the number of physical processors
       consumed by the partition (in case of system wide utilization) or
       logical CPU (if the -P flag is specified) and %entc indicates the
       percentage of the allocated entitled capacity (in case of system wide
       utilization) or granted entitled capacity (if the -P flag is
       specified). When the partition runs in capped mode, the partition
       cannot get more capacity than it is allocated. In uncapped mode, the
       partition can get more capacity than it is actually allocated. This is
       called granted entitled capacity. If the -P flag is specified and there
       is unused capacity, sar prints the unused capacity as separate CPU with
       cpu id U. Note: The sar command only reports on local activities.
Can this issue get fixed in the official release of the Splunk for Unix and Linux TA app?
(Is there a different way in which I should report this issue?)
 
		
		
		
		
		
	
			
		
		
			
					
		I created issue SPL-53293 for this. We might need your help in verifying it, as I don't think we have a micropartitioned AIX system to test with.
 
		
		
		
		
		
	
			
		
		
			
					
		Thanks for the report, I will add this to this list of things that we will consider fixing in the next release of the app.
 
					
				
		
 
		
		
		
		
		
	
			
		
		
			
					
		If you have enterprise support, you can open a support case on this. That is probably a good idea if for no other reason than to get the bug officially filed and triaged.
According to araitz, this app should eventually wind up on github - you could provide a patch then if you have one. See http://blogs.splunk.com/2011/11/07/splunk-for-unix-and-linux-an-update-and-an-introduction/ -- but I just checked and it's not there yet.
 
		
		
		
		
		
	
			
		
		
			
					
		Yeah, someone was supposed to put the app on github but never followed through 😕 I'll keep pushing.
