This section describes the RTView Enterprise Service Model (also referred to as the CMDB), and its configuration. Before the CMDB is configured, your solution package data is only visible in displays that are specifically for that solution package (such as the displays in the Components tab).
After you configure the CMDB, you gain a "single-pane-of-glass" view. That is, your solution package data is visible and incorporated into the displays and performance metrics of all relevant displays (such as displays under the SERVICES tab).
The CMDB is a database containing the master hierarchical map of associations between all component IDs (CIs), Services, Groups, Areas and Owners in your system. A CI is an item in your system that is being monitored by RTView Enterprise. The item could be an application, a cache, a server, a router, a NIC card, a server partition, a connection and so forth.
The CMDB contains four hierarchical levels that should suit the monitoring needs of most organizations. The four levels are, from the highest level (Owner) to the lowest level (Service):
Owner
Area
Group
Service
The names of the CMDB levels cannot be modified.
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 RTViewCentral displays. There is no limit on the number of associations a level can have. A Service can be associated with multiple Groups and Environments.
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 RTViewCentral displays are updated.
By default, the CMDB contains a single Owner named Infrastructure which organizes the CI’s by Solution Package. Infrastructure cannot be modified, but it can be disabled in the Service Model Page of the RTView Configuration Application.
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:
Determine the Owners: Note the person or persons responsible for alerts in your organization. You might have only one Owner.
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).
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).
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 Enterprise. 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 Service Model Page/ Default Environment Filter field.
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 use as an example in Configuration Steps .
To prepare for configuration we list our hierarchical associations as follows:
|
Owner |
Area |
Group |
Service |
|
jPeters |
|
|
|
|
|
Development |
|
|
|
|
|
Middleware |
WebLogic |
|
|
|
|
GlassFish |
We 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.