SAR support exists to process data from the following operating systems:
|Linux||Use Systat 4.0.1|
If you browse the list of SAR tables that are supplied with ITSV you will see that there are (at the time of writing) about 31 tables which support various types of data (memory, cpu etc.) from different operating systems. Some of these tables contain metrics that are typically only produced by one operating system.
Please note that the SAR table represents a combination of all the sar metrics from the other tables (with a few exceptions covered below). For purposes of efficiency, you should select either the SAR table, or a number of the smaller tables that suit your specific requirements. If you are unsure, select the SAR table initially. The following table lists the sub-tables that are combined to make the SAR table.
|SARFAS||File Access System Statistics|
|SARBUF||Buffer Activity Statistics|
|SARSYS||System Call Statistics|
|SARSEM||Semaphore and Messaging Statistics|
|SARQUE||Processor Queue Statistics|
|SARTTY||TTY Device Statistics|
|SARSTS||System Table Statistics|
|SARKPC||Kernel Process Activity|
|SARCSW||System Switching Activity|
|SARSWP||Swapping and Switching Statistics|
|SARKMA||Kernel Memory Allocation Statistics|
|SARNMI||Namei Cache Statistics|
|SARPSCH||Process Scheduling Activity|
|SARCBUF||Copy Buffer Activity|
|SARSCAT||Scatter-Gather and Physical I/O, and DMA Transfer Buffer Statistics|
|SARSOCK||Network Statistics on Sockets|
|SARPRC||Process Creation Activity|
If you decide to add any of the above SAR* tables to your PDB you will have to update their KEPT status to YES as they are supplied as KEPT=NO.
The following SAR* tables are not combined with the SAR table as their data contains instance variable(s). These tables are supplied with a KEPT status of YES by default and can be added to your PDB as required.
|SARCPUB||CPU Utilization detailed by CPU ID/engine|
|SARBD||Block Device By Partition Statistics|
|SARDEV||Block Device Statistics|
|SARIFAC||Network Interface Statistics (Linux only)|
|SARLTTY||TTY Device Statistics (Linux only)|
Finally, you should use the SARPAG table instead of the SARPG1, SARPG2 and SARPG3 tables separately.
This section is intended to get you started, please refer to your system's documentation on the 'sar' command for further information. You may already be collecting sar data at your site so the following may be unnecessary.
Generally, SAR data collection can be started with a command similar to :
sar -A -o sarlog.dat 300 12
Once sar completes the following command will take the binary file created (sarlog.dat) in the example and will produce another file in ASCII format.
sar -A -f sarlog.dat > sarlog.log
It is this ASCII file that is recognized and processed by IT Service Vision.
There are supplied SAR tables that are provided with IT Service Vision that store data broken down by CPU. In order to process this data you may have to specify additional switches on the above command. At present, the only platforms that have been tested are AIX, HP-UX, Linux and SunOS. For example:
Solaris does not have a by CPU switch and the sar -A command on Linux automatically reports both by CPU and summarized separately.
To process sar data into IT Service Vision, use the %CPPROCES macro as follows:
%CPPROCES(COLLECTR=SAR,TOOLNM=SASDS,RAWDATA="directory or single file");
Sar data is typically collected and written to a binary data file named after the day of the month. Once a day, or whenever you want to process the data, another sar command should be entered which reports off the binary file, the output of which should be piped to an ASCII log file. It is this log file that the IT Service Vision SAR collector processes. For sites with many machines, multiple log files can be processed if they are placed in a directory and RAWDATA points to this location. You can also create a sub-directories if you wish to segregate different platforms and/or machines. The SAR collector will read all files in the directory that RAWDATA points and all files in its sub-directories.
Within %CPPROCES, each individual file is processed separately enabling %CPPROCES to reject any files which it does not recognize, or is unable to process. If an error occurs while processing a particular file, a message is written to the SAS log explaining that this file is being skipped and %CPPROCES moves onto the next file. At the end of any %CPPROCES run you should review the SAS log for any messages that indicate if a file has been skipped. If possible fix the problem and re-run %CPPROCES against just this file.
The SAR collector also supports the automatic execution of duplicate checking macros. As with other similar collectors, code DUPMODE=DISCARD on the %CPPROCES macro to initiate duplicate checking of incoming data.