RTView® EM
User Guide

Configure the Service Data Model
This section describes the EM Service Data Model (also referred to as the CMDB), and its configuration. The CMDB is a hierarchical map of the links between all Configuration Items (CIs) and Services in your system. When you have finished this part of the EM configuration you will have a "single-pane-of-glass" view in which data from all your Solution Packages are visible in all relevant EM displays. When the CMDB is not configured, Solution Package data is only visible in displays that are specifically for that Solution Package.

Configuration of the Service Data Model is optional.

The following figure illustrates the RTView EM component that is the subject of this section: the CMDB database.  

To configure the Service Data Model you determine how the structure of your organization fits into the CMDB hierarchy, then use the CMDB Admin display to configure the CI-to-Services mapping. 

This section includes:

  • Introduction to the CMDB: Describes the CMDB structure, and provides examples of how an organization's established structure can be applied to the CMDB.
  • Configuration Steps: Step-by-step CMDB configuration instructions.

Introduction to the CMDB
The Service Data Model, or CMDB, is an EM database that contains the map of all Configuration Items (CIs) in your system to Services. The CMDB has four hierarchical levels which suits the monitoring needs of most organizations. The four levels are, from the highest level (Owner) to the lowest level (Service):

  • Owner
  • Area
  • Group
  • Service

When you configure the CMDB you associate each CI in your system with a Service, Group, Area and Owner. These associations form the map that enables aggregation of data in EM displays.

By default, the CMDB contains a single Owner named Infrastructure. When you configure the CMDB you map each CI in your system to one or more Services, each Service to a Group, each Group to an Area and each Area to an Owner. There is no limit on the number of associations the four levels can have. The names of the CMDB levels cannot be modified. The following figure illustrates the four hierarchical levels of the CMDB.

Infrastructure is only for the internal RTView Manager Solution Package, which monitors RTView EM. Infrastructure must not be modified.

EM-SERVICE CI Type

You can also associate Services with other Services using the EM-SERVICE CI Type. The EM-SERVICE CI Type enables you to use the alerts provided by the RTVRULES Solution Package.

Defining the CMDB

When you configure the Service Data Model you use the existing structure of your organization to do so. If your organization does not have an established structure, you need to define one relevant to your system. The manner in which you adapt your system hierarchy to the CMDB levels depends on the monitoring needs of your organization. You design the CMDB by identifying the four hierarchical levels in your organization that coincide with the four-level hierarchy in the CMDB. For example, you might:

  1. Determine the Owners: Note the person or persons responsible for alerts in your organization. You might have only one Owner.
     
  2. Determine the Areas for each Owner: The Areas are relevant to the Owner accountable for resources in the Areas. Areas might be based on departments in the organization (such as Development, Sales, HR, and so forth).
   
  3. Determine the Groups for each Area: Groups might be comprised of, for example, the types of resources used in the Areas (such as Servers, Middleware and Processes).
   
  4. Determine the Services for each Group: Services might be comprised of a variety of applications that are used by a given Group.  

After you determine how to adapt your organization to the four levels of the CMDB, use the CMDB Admin display to map each CI to a Service, Group, Area and Owner. The name of the CI can indicate which Service you want to associate the CI with.

The CMDB automatically classifies the CIs in your system into CI Types. This classification is based on a preconfigured schema that is internal to EM. CI Types are determined by the role of a given CI, and the name of the CI Type describes the role. For example, a BusinessWorks application process is a BW-PROCESS CI Type, a BusinessWorks server is a BW-SERVER CI Type and an Oracle database is an ORACLE CI Type.

Small Company Example
Typically, small companies have a single Owner. The following figure illustrates a portion of a CMDB structure in which a single Owner is accountable for three Areas (Development, Sales and HR). The Development Area has three Groups associated with it (Servers, Middleware and Processes). The items in green indicate the parts of the branch (jPeters / Development / Middleware) we configure as examples in the Configuration Steps.

To prepare for configuring the CMDB we might list the hierarchical associations as follows: 

Owner Area Group Service
jPeters      
  Development    
    Middleware WebLogic
      GlassFish

We then use this list to associate each CI in our system with a Service, Group, Area and Owner.

To see a large company example, see Large Company Example.

Configuration Steps

This section describes how to configure the CMDB using the CMDB Admin display and uses the Small Company Example to illustrate. This section assumes you have determined a structure for your CMDB configuration. For details about the CMDB structure, see Introduction to the CMDB. To configure the CMDB you associate each CI in your system with a Service, Group, Area and Owner. After you configure the CMDB all relevant EM displays will contain monitoring data from your Solution Packages. Configuration of the Service Data Model is optional. There are several ways to create the CMDB:  

  • Manually, by using the CMDB Admin display.
  • Import an existing structure from a spreadsheet or database. 
  • If the data is available to the Configuration Server, you can read it dynamically by populating the structure from the raw data.
  • Any combination of the above.

At this point you have:

To configure the CMDB:
1. Open the Administration / CMDB Admin display.

2. Select a CI Type to configure from the Selected CI Type drop-down menu, located above the lower table. The Selected CI Type drop-down menu is populated with installed and configured Solution Packages in your system.

For example, to configure the jPeters / Development / Middleware / WebLogic branch as an example from the Small Company Example we select WLS. 

The Available Components table populates with CIs for WebLogic.

3. Select a CI from the Available Components table and click Add CI To.... NOTE: To determine which CIs to associate with a Service, refer to the CIName column. The CIName column contains descriptive information entered by your administrator about the CI.

The Add CI into a Service dialog opens.

4. Associate the CI with a Service by entering the Owner, Area, Group and Service. Refer to your defined CMDB structure to determine appropriate entries. For example, to configure the jPeters / Development / Middleware / WebLogic branch from our Small Company Example, we enter:

  Owner: jPeters
  Area: Development
  Group: Middleware
  Service: WebLogic

5. Click Add CI and OK.

The CI appears in the CI List for Selected Service table and the CI is now associated with the new Service. The four levels are saved in the CMDB and populate the Owner, Area, Group and Service drop-down menus in the CMDB Admin display, as well as other displays.

6. Specify the rank of importance for the CI using the Criticality drop-down menu, where A is the highest importance and E is the lowest. Criticality is used to calculate the value for Alert Impact. For our Small Company Example, we set the Criticality to E. 

7. Select the environment for the CI using the Environ drop-down menu:

  Production  
  DR (Disaster Recovery)  
  UAT (Testing)  
  Development  

 Click Update to save the entries.

8. Optionally, enter the following for the CI using the remaining drop-down menus:

  Region Optionally, enter a geographic region in which the CI resides.
  SiteName Optionally, enter a site name in which the CI resides.
  City Optionally, enter a city in which the CI resides.
  Country Optionally, enter country in which the CI resides.
  OSType Optionally, enter the operating system on the CI.

 Click Update to save the entries.

9. Add more CIs to this Service by selecting a CI and clicking Add CI. The CIs appear in the CI List for Selected Service table and the CI is now associated with the Service. Use the Selected CI Type drop-down menu to associate a different CI Type. NOTE: To modify settings (Criticality, Environ, etc.) for a CI, select the CI, change the settings and click Update. To remove a CI from a Service, select the CI and click Delete.

10.  Add a new Service by selecting a CI and clicking Add CI To.... Use the Selected CI Type drop-down menu to locate the relevant list of CIs.

For example, for our Small Company Example to add the GlassFish Service and associate GFS CIs, we select GFS from the Selected CI Type drop-down menu, select a CI from the Available Components table and click Add CI To....

The Add CI into a Service dialog opens.  

11. Make the appropriate entries and click Add CI and OK. 

For example, for our Small Company Example we make the following entries for the jPeters / Development / Middleware / GlassFish branch.

  Owner: jPeters
  Area: Development
  Group: Middleware
  Service: GlassFish

The CI appears in the CI List for Selected Service table and the GlassFish Service is in the CMDB.

12. Specify the rank of importance for the CI using the Criticality drop-down menu, where A is the highest importance and E is the lowest. For our Small Company Example, we set the Criticality to A. 

13. Select the environment for the CI using the Environ drop-down menu:

  Production  
  DR (Disaster Recovery)  
  UAT (Testing)  
  Development  

 Click Update to save the entries.

14. Optionally, enter the following for the CI using the remaining drop-down menus:

  Region Optionally, enter a geographic region in which the CI resides.
  SiteName Optionally, enter a site name in which the CI resides.
  City Optionally, enter a city in which the CI resides.
  Country Optionally, enter country in which the CI resides.
  OSType Optionally, enter the operating system on the CI.

 Click Update to save the entries.

15. Add more CIs to this Service by selecting a CI and clicking Add CI. The CIs appear in the CI List for Selected Service table and the CI is now associated with the Service. Modify settings (Criticality, Environ, etc.) for a CI as needed and click Update.

16. Click Close to close the Add CI into a Service dialog.

17. Open a display, such as the Group / Service Heatmap, to view your entries integrated into the EM display.

Continuing with our Small Company Example, we see the jPeters branch we configured in the display which has two Services in the Middleware Group:

  Owner: jPeters
  Area: Development
  Group: Middleware
  Service: WebLogic
    GlassFish

NOTE: There are two rectangles, one for each Service. Part of the heatmap is red, indicating the WlsThreadsTotalHigh alert state, which is the alert we adjusted thresholds for and enabled in the previous Configure the Solution Package instructions. Recall that we set the Criticality level for a CI associated with the GlassFish Service to A (the highest rank of importance). For this reason the rectangle representing the GlassFish Service is red. The WebLogic rectangle is not red because we set the Criticality to E (the lowest rank of importance).

18. To enable alerts, open the Administration / Alert Administration display and locate alerts for your installed Solution Package Data Server. 

    Select the alerts you wish to enable for the Solution Package, optionally modify the alert Warning Level and Alarm Level , then select Enabled.
    Click Save Settings and Yes.

19. Repeat previous steps as needed until all CIs are associated with a Service.

This completes your Service Data Model configuration. Solution Package data is visible in all relevant displays. You now have a "single-pane-of-glass" view in which data for all Solution Packages are visible in all EM displays. For details about using the CMDB display, see CMDB Admin.

Proceed to Configure Central Server Database.

 

 

Large Company Example
Typically, large companies have several owners that are in charge of several Areas. This example illustrates a single branch of the CMDB--the branch belonging to the IT manager: jSmith. For that branch of the CMDB, the company defines the following structure:

  Owners: jSmith
rJones
tSchmidt
bRoberts		 There are four managers in the company and they are the members of the CMDB Owner level. The IT manager is jSmith.
       
  Areas: IT Core
IT SVCS		 There are two CMDB Areas associated with jSmith. The two Areas are based on expertise-based subdivisions of personnel in the company: IT Core and IT SVCS.

This example continues with the IT Core branch belonging to jSmith. This example does not describe the  IT SVCS branch belonging to jSmith. 

       
  Groups: Core Apps SMS
Core Apps WEB
Core Oracle		 There are three CMDB Groups associated with the IT Core branch. The three Groups are based on the three subdivisions of personnel in the IT Core Department: Core Apps SMS, Core Oracle and Core Apps WEB.

The other Areas in the company might have different Groups.

This example continues with the Core Oracle branch belonging to jSmith. This example does not describe the Core Apps SMS and Core Apps WEB branches belonging to jSmith. 

       
  Services: R&D
Production
Web Stores		 There are three CMDB Services associated with the Core Oracle Group. The three Services are based on the infrastructure services that the company provides to its customers: R&D, Production and Web Stores.

The other Groups in the company might have different Services.

       
  NOTE: This example does not illustrate CIs associated with Services.

 

 

 
 
 
SL, SL-GMS, GMS, RTView, SL Corporation, and the SL logo are trademarks or registered trademarks of Sherrill-Lubinski Corporation in the United States and other countries. Copyright © 1998-2013 Sherrill-Lubinski Corporation. All Rights Reserved.
 
 
 

JMS, JMX and Java are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. They are mentioned in this document for identification purposes only.

 
 
 

Third Party Notice Requirements