Monitoring Operating System Data with CCMS
Agents
Use
The operating
system collector SAPOSCOL collects operating system data for any host and
stores this in a segment of the shared memory. All CCMS agents can copy this
data to the CCMS monitoring segment and transfer it to the central monitoring
system. This means that the data is visible in the CCMS monitoring
architecture and is displayed in the familiar transactions ST06 and OS07. For
more detailed information about the operating system collector, see
operating system
collector SAPOSCOL and SAP
Note 371023.
In this way, you can monitor the operating system data for servers without a running SAP system. An expensive installation and configuration of RFCOSCOL is no longer necessary.
Operating System Data Displayed in the Alert Monitor
After the successful installation of the agent, the CCMS monitoring architecture displays the following data in transaction RZ20, in the Operating System monitor:
● Filesystems
● CPU
● Paging
● Commit Charge (only for Microsoft Windows)
● Swap Space (only for UNIX)
● OS Collector
● LAN
Features
Configuring the Monitoring of Operating System Data
The agent allows an individualized selection of subtrees for the Operating System and Filesystems monitors. You can use a filter to explicitly remove subtrees or entire components from the monitoring display. No monitoring nodes are then generated for these. As an alternative to filtering out file systems, you can activate an exclusive monitoring with which only the file systems that you explicitly specify are monitored. All other file systems are not then monitored.
As of Patch Collection 2005/4 of the CCMS agents, you can change the names of the MTE classes for the monitored operating system data as desired. This means that you can assign operating system data from different hosts to different MTE classes. This simplifies Customizing, for example, the threshold values or the assignment of different auto-reactions depending on the function or the platform (Microsoft Windows, UNIX) of the monitored hosts.
In the SAPCCMSR.INI configuration file of the CCMS agents, you can use the parameter OsColFile to specify a configuration file in which you can make these settings. In this case, SAPCCMSR.INI would contain an entry of the type:
OsColFile <configuration file for monitoring operating system data>
This SAPOSCOL filter file is referred to as oscolfile.txt in the following.
Structure of the SAPOSCOL Filter File oscolfile.txt
You can make the following specifications in the oscolfile.txt filter file:
● Filtering Out Components
After the keyword FilterOutComponent, enter the components that you do not want to be copied to the CCMS monitoring segment, and for which the system will therefore not create a subtree in the monitoring tree in transaction RZ20.
● Filtering Out File Systems
You can use the keyword FilterOutFilesystem to filter out file systems that are not to be copied to the CCMS monitoring segment. In this way, you can, for example, exclude particular file systems that are always 100% full from the monitoring. You can specify the file system name or use a pattern with a wildcard character (*).
● Set the MTE Class and Attribute Group of the Monitored Operating System Data
In the context of monitoring, you can also set the associated MTE class and attribute group yourself for the following components:
○ Microsoft Windows: CPU, Lan, Commit_Charge, Paging
○ UNIX: CPU, Lan, Swap_Space, Paging
Since this happens at host level, you can assign the operating system data of different hosts to different MTE classes. To do this, enter the keyword MonitorComponent. The syntax of the keyword is:
MonitorComponent <component name> <MTE class> [<attribute group>]
The corresponding monitoring objects and monitoring attributes then receive the following names:
Node Name |
Standard MTE Class |
MTE Class Set Yourself |
CPU |
CPU |
<Name> |
Paging |
Paging |
<Name> |
Commit_Charge |
Commit_Charge |
<Name> |
Swap_Space |
Swap_Space |
<Name> |
Lan |
Lan |
<Name> |
You can see from the table that the set MTE class is used as a prefix for the associated monitoring attributes. Since the length of the MTE class is restricted to 40 characters, a maximum of 24 characters are available to your for the name that you have chosen.
● Set the MTE Class and Attribute Group of the Monitored Disks
In the same way as setting your own name for the MTE class and attribute group for the monitored operating system data, there is a keyword available with which you can set your own name for the MTE class and attribute group for disks. To do this, enter the keyword MonitorDisk. The syntax of the keyword is:
MonitorDisk <disk name> <MTE class> [<attribute group>]
The corresponding monitoring objects and monitoring attributes then receive the following names:
Node Name |
Standard MTE Class |
MTE Class Set Yourself |
Disk |
Disk |
<Name> |
● Adjusting Monitoring of File Systems
As an alternative to filtering out individual file systems, you can activate an exclusive monitoring. In this case, the system creates a subtree in the monitoring architecture for only the file systems that you specify with the keyword MonitorFilesystem. Other file systems are ignored. Entries with the keyword FilterOutFilesystem are also ignored. The syntax of the keyword is:
MonitorFilesystem <file system> [<MTE class> [<attribute group>]]
You can also assign a separate MTE class or attribute group to the monitoring object for the file systems (by default, this is always the class FilesystemMO), so that, for example, you can use a rule-based monitor to display only the file systems that you have explicitly assigned to this MTE class.
● Adjusting the Monitoring of the LAN Interfaces
You can monitor specific LAN interfaces exclusively in the same way as monitoring certain file systems. You can also set the MTE class and the attribute group of the LAN interfaces to be monitored. To do this, enter the keyword MonitorLAN. The syntax of the keyword is:
MonitorLAN <LAN> [<MTE class> [<attribute group>]]
If you simply want to set the MTE class for all LAN subtrees, in the same way as with the keyword MonitorComponent, enter the wildcard character * for <LAN>.
Note also that the name for <LAN> must not contain any spaces. In this case, use the wildcard character * as a workaround. In this way, if you wanted, for example, to monitor the LAN interface MS TCP, you could enter only MS* for <LAN>.
If you have installed an SAPCCM4X agent, there is already a complete Operating System monitoring tree that was created by the monitored SAP instance. In this case, you must deactivate the ABAP data collector in the monitored system. When it is started, the SAPCCM4X agent then creates a new Operating System monitoring tree in accordance with oscolfile.txt: Follow the procedure below:
1. Start transaction RZ21 in the system that the SAPCCM4X agent is monitoring. In the Methods group box, select Method Definitions and choose Display Overview.
2.
Change the
following methods by selecting the methods and choosing Edit Data (
):
○ CCMS_Fsys_Collect
○ CCMS_OS_Collect
○ CCMS_OS_LAN
3. On the Release tab page, deactivate the Data Collection Method indicator and on the Control tab page, deactivate the Execute method immediately after start of a monitoring segment check box.
4. Save the method definitions.
5. Restart the CCMS agent.
● Set the MTE Class and Attribute Group of Monitored Processes
By default, the MTE class MonitoredProcessesMo is assigned to processes that are monitored by the operating system collector SAPOSCOL. You can change this MTE class (and the attribute group) by specifying the desired name after the keyword MonitorProcess. The syntax of the keyword is:
MonitorProcess <process name> <MTE class> [<attribute group>]
You can
individually set the MTE class and attribute group of the monitored processes
individually in the selection of the monitored processes (see
Monitoring Selected
Processes with SAPOSCOL). This has the advantage that all configuration
settings for the monitored processes are in one file.
Note that with the keyword MonitorProcess, you only assign monitored processes to classes and groups; unlike FilterOutFilesystem and MonitorFilesystem, it does not have any filter functions.
Example
Example SAPOSCOL Filter File oscolfile.txt
The following file is intended to assist you in creating the filter file oscolfile.txt; the meaning of selected configuration settings is explained in the example below:
#######################################################################
###
### OsColFile.txt
### Configuration file for Operating System Monitoring
###
#######################################################################
# FilterOutComponent <Component Name>
### CCMS agent does not create MTEs for <Component Name>
### Windows: <Component Name> = CPU | Lan | Commit_Charge | Paging
|
###
Filesystems
### UNIX:
<Component Name> = CPU | Lan | Swap_Space | Paging |
###
Filesystems
# FilterOutFilesystem <Filesystem Name> | <Pattern>
### CCMS agent does not create MTEs for <Filesystem Name>
|<Filesystem>
### Filesystem name can contain '*' as a wildcard
(<Pattern>).
### CCMS agent does not
create MTEs for <Filesystem Name> | <Pattern>
# MonitorFilesystem <Name> | <Pattern> [ <MTE Class> [<Group>]]
### CCMS agent creates MTEs for this file system only. All other
### Filesystems are ignored
### Name can contain '*' as a wildcard (<Pattern>)
### Name can be an unsubstituted filesystem name e.g. $DIR_TRANS
### $DIR_PERF, if these represent file systems collected by saposcol
### <MTE Class> and <Group> are
optional. If you want to
specify
### your own customizing group you have to specify the MTE class,
too.
# MonitorComponent
<Component Name> <MTE Class> [<Group>]
### CCMS agent creates MTEs with specified MTE class and customizing
### group.
### <Group> is
optional. If you don't specify the
customizing group,
### then the standard name is used.
###
### Windows: <Component Name> = CPU | Commit_Charge | Paging
### UNIX:
<Component Name> = CPU | SwapSpace | Paging
# MonitorLAN <Name> | <Pattern> [ <MTE Class> [<Group>]]
### CCMS agent creates MTEs for this LAN interfaces
only. All other
### LAN interfaces are ignored
### Name can contain '*' as a wildcard (<Pattern>)
### <MTE Class> and <Group> are
optional. If you want to
specify
### your own customizing group you have to specify the MTE class,
too.
# MonitorProcess
<Name> | <Pattern> <MTE Class> [<Group>]
### Changes the MTE Class (and the Attribute Group) of the monitoring
### objects of the monitored process <Name>. Name can contain '*' as
a
### wildcard (<Pattern>). If you want to specify
your own customizing
### group you have to specify the MTE class, too.
Examples of Configuration Parameters and their Meaning
Contents of oscolfile.txt |
Description |
FilterOutComponent
CPU |
● Does not create subtree CPU and does not create subtree Swap_Space ● Creates a tree only for the file system /usr/sap/trans |
FilterOutComponent Filesystems |
● Does not create a subtree for file systems |
FilterOutComponent
CPU |
● Does not create a CPU subtree ● Does not create trees for file systems that match the pattern /oracle/C11/sapdata* (such as /oracle/C11/sapdata2); all other file systems are displayed |
MonitorFilesystem |
● Only creates a tree for file systems that match the pattern /oracle/C11/sapdata* (such as /oracle/C11/sapdata2); the nodes are created under the MTE class CL_ORA and the attribute group CG_ORA |
MonitorProcess |
● Creates the subtree for the *disp+work processes with the default MTE class MonitoredProcessesMo and the attribute group Kernel_Group |
MonitorCompontent CPU
|
● Subtree CPU has the MTE class and attribute group host123CPU, and its monitoring attributes have this name as a prefix |
CCMS Agents, Advanced
Functions of the CCMS Agents start page