Configure Service Data Model

This section describes the RTView EM Service Data Model (also referred to as the CMDB), and its configuration. The CMDB is a database containing the hierarchical map of associations between all Configuration Items (CIs), Services, Groups, Areas and Owners in your system. When you have finished this part of the RTView EM configuration you will have a "single-pane-of-glass" view in which data from all your Solution Packages are visible in all relevant RTView 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 Administration - 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 RTView EM database that contains the map of all Configuration Items (CIs) in your system to each hierarchical level in the CMDB. 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 your CMDB you associate each CI in your system with a Service, each Service with a Group, each Group with an Area and each Area with an Owner. These associations form the map that enables aggregation of data in RTView EM displays. When you make any changes to Owners, Areas, Groups or Services the associated levels are automatically updated. For example, when you move a Group from one Area to another, all Services associated with that Group move with it, and the RTView EM displays are updated.

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. For details, see Configure 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 Administration - 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 RTView 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.

After you configure a Service Data Model, the automatically generated Infrastructure Service Data Model looks for matching CI's in your Service Data Model in order to set the Environment. For each CI in the automatically generated Infrastructure Service Data Model, if a matching CI is found in your Service Data Model, the Environment from your Service Data Model is used for the Infrastructure CI. If the CI is found in your Service Data Model multiple times with multiple Environments, it is added multiple times to the Infrastructure CMDB--once for each Environment in your Service Data Model for that CI. If no matching CI is found in your Service Data Model, the Environment in the Infrastructure Service Data Model is set to PRODUCTION by default. You can override the default Environment by specifying a different environment in the rtv_cmdb_source_default.rtv line in your properties file.

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:

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 Administration -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 RTView 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, using the Administration - 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:

• Verified System Requirements

• Completed instructions in Installation for the full RTView EM platform

• Completed instructions in Configure Central Servers

• Completed instructions in Configure Solution Package. You have configured a local RTView EM deployment and Web Browser RTView EM deployment. That is, displays such as the All Management Areas - Area Heatmap are populated with JVM data from RTView EM servers and the CMDB database (which has only the default Owner, Infrastructure).

• Solution Package-specific displays showing monitoring data from your environment. You do not yet see Solution Package data in displays such as the All Management Areas - Area Heatmap.

• An Administration - CMDB Admin display with undefined levels and a Selected CI Type drop-down menu populated with CI Types available from your system, as shown in the following figure.

  

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 one or more CIs 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 your selected CIs 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 CIs appear in the CI List for Selected Service table and are 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 Administration - CMDB Admin display, as well as other displays.

6. Specify the rank of importance for a 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 a 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. Associate more CIs to this Service by selecting them and clicking Add CI. The CIs appear in the CI List for Selected Service table and the CIs are 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 RTView 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 in the heatmap, 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 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 RTView EM displays. For details about using the CMDB display, see CMDB Admin.

Proceed to Configure Databases of the Central Servers.

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:

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